 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Next version in a day or two
have a litle trouble algo heavy cards rx470-570 4gb double treads work fine in config "intensity" : 29, "double_threads" : true single treads dont work with error Error CL_INVALID_BUFFER_SIZE when creating scratchpad buffer for DeviceID 0 (Thread 0) in config "intensity" : 57, "double_threads" : false if set intensity 0 setting 44 and slow rate same rig work fine with config "intensity" : 58, "double_threads" : false same drivers version 18.2.1 same swap size 60gb for 12 card same windows version 1709 CL_INVALID_BUFFER_SIZE errors means you're running out of GPU mem. Reduce your intensity. |
|
|
|
This used to be a good thread...all about collaboration and sharing ideas. BUT then it became all about pushing product and trying to make money in a questionable way. This thread is RIGGED and OVER AND OUT. Not really yelling just mocking.  |
|
|
|
Not using any monitoring script for now. Just trying to make it work reliably, basically.
Failing mobo is like the thing you don't want to happen because it's the one variable you tend to always rule out when you have issues. On my two rigs of RX570's I've got some GPUs chugging at 1950MHz mem speed, while other keep crashing at 1850 and lower -h values (in Claymore). I can't think there's anything wrong with the GPUs, so it's gotta be risers... or the damn mobo.
Let's see how the Vega rig behaves...
No issues so far with version 0.7 and it has been 4 hours. @dragonmike I've been stable since yesterday and the only thing i changed was running Cast XMR v0.7 vs v0.8 How are things on your end? Very stable since I applied a soft power play table and realised I could finally increase mem voltage that way. Currently running the flashed 56's at 1966h/s avg, mem clock = 1125, 1.025V. That's a bit on the high side, powerwise (approx 200W per card) but I'll tweak a bit more when I have more time. At least now I'm happy I've found a stable setting that hasn't crashed for 3 days!  That's great news! I'm back to square one though, at least now i know which GPU is failing...GPU0. |
|
|
|
Not using any monitoring script for now. Just trying to make it work reliably, basically.
Failing mobo is like the thing you don't want to happen because it's the one variable you tend to always rule out when you have issues. On my two rigs of RX570's I've got some GPUs chugging at 1950MHz mem speed, while other keep crashing at 1850 and lower -h values (in Claymore). I can't think there's anything wrong with the GPUs, so it's gotta be risers... or the damn mobo.
Let's see how the Vega rig behaves...
No issues so far with version 0.7 and it has been 4 hours. @dragonmike I've been stable since yesterday and the only thing i changed was running Cast XMR v0.7 vs v0.8 How are things on your end? |
|
|
|
|
Hardware wallets and paper wallets. I use a combination since the hardware wallets don't support all coins. I have a Trezor and Ledger Nano plus paper wallets because I'm paranoid.
|
|
|
|
I'm using devcon to disable and enable my Vegas after a reboot, but no matter what I still have to manually go in and toggle the HBCC Memory Segment switch to get the maximum performance. Anyone have a better workaround or is this still the only way to get it to work to its full potential?
You have to run it every time before you execute the mining executable just to be safe. I recommend either writing your own bat file or leveraging some of the suggestions on this forum. There is also a mining hash monitoring script that I use that can be found here http://vega.miningguides.com/. |
|
|
|
Not using any monitoring script for now. Just trying to make it work reliably, basically.
Failing mobo is like the thing you don't want to happen because it's the one variable you tend to always rule out when you have issues. On my two rigs of RX570's I've got some GPUs chugging at 1950MHz mem speed, while other keep crashing at 1850 and lower -h values (in Claymore). I can't think there's anything wrong with the GPUs, so it's gotta be risers... or the damn mobo.
Let's see how the Vega rig behaves...
No issues so far with version 0.7 and it has been 4 hours. |
|
|
|
weird... I'm getting only 1.2KH/s with a Vega 64. All drivers are set.
Could it be due to different mining pool?
I'm using dark-mine.su
What are you're settings? Are you using OverdriveNtool? Sounds like a HBM issue. Did you disable and enable the devices with devcon.exe? check this page http://vega.miningguides.com/ |
|
|
|
Well, stopped again after a few hours. So core clock now back up to 1408 and lowered mem clocks to 1040. Let's see how that goes. Annoying. I really thought I'd be able to run these cards closer to 1100... Now it seems I'm tweaking the other way  EDIT: I suppose playing with power limit wouldn't do anything for the memory clocks anyway... so pointless playing with that. Dude, are you sure it is memclock related? I think it is a bug in cast_xmr. Well, when I was mining on unmodded 56 bios @ 925MHz memory freq the rig was mining several days without a single hickup. So I can only assume stability is memclock related. I'd be very happy to be proven wrong! Fair enough. I just switched back to version 0.7 and will let you know how it goes. What version are you on? I'm on the latest, aka v0.8. Not sure if it makes any difference in stability... How does the intensity affect hashrate? I've set it to the max (I think that's 9), but no idea if lowering it would allow clocking mem higher (or prevent the miner from stopping)? I've used -I 9 on version 0.6 and up and never had an issue until recently. Only that changed on my end was upgrading to v0.8 and swapping out my mobo. "only thing" = swapping out mobo...big change I know but I have the exact same mobo before and no issues till v0.8. I'm not pressing the cards hard either, running 920MHz memclock. Are you using JJs modified monitoring script? If you are, then next time it hangs, browse to 127.0.0.1:7777 and try to refresh the page...only after you do that will JJs pick up that the process is hung and restart it. |
|
|
|
Well, stopped again after a few hours. So core clock now back up to 1408 and lowered mem clocks to 1040. Let's see how that goes. Annoying. I really thought I'd be able to run these cards closer to 1100... Now it seems I'm tweaking the other way EDIT: I suppose playing with power limit wouldn't do anything for the memory clocks anyway... so pointless playing with that. Dude, are you sure it is memclock related? I think it is a bug in cast_xmr. Well, when I was mining on unmodded 56 bios @ 925MHz memory freq the rig was mining several days without a single hickup. So I can only assume stability is memclock related. I'd be very happy to be proven wrong! Fair enough. I just switched back to version 0.7 and will let you know how it goes. What version are you on? |
|
|
|
Well, stopped again after a few hours. So core clock now back up to 1408 and lowered mem clocks to 1040. Let's see how that goes. Annoying. I really thought I'd be able to run these cards closer to 1100... Now it seems I'm tweaking the other way EDIT: I suppose playing with power limit wouldn't do anything for the memory clocks anyway... so pointless playing with that. Dude, are you sure it is memclock related? I think it is a bug in cast_xmr. |
|
|
|
RMA it.  |
|
|
|
So I've just flashed my 56's to 64 vbios and applied Hellae's "safe" reg file.
I've set some new frequencies in OverdriveNtool but CastXMR just keeps stopping on me after a few minutes. Does that mean I'm not giving the memory enough juice? Too much clock? Is it core related? Can anyone who's been through this help me troubleshoot the behaviour of the miner please?
...
Getting approx 1900h/s/card, total 1050w from the wall (6 GPUs).
Any suggestions welcome!
Can you elaborate on "stops" a little? Does the app crash/close, does it just stop output in the cmd shell....that kind of thing. Reason I ask is I have similar behavior where it just stops sending out put to the Window (nope it is not the Quick Edit setting). When I try to connect to the 7777 port my moniotoring script will pick up that it is hung and then it restarts the process. Basically yes, it hangs. Stops sending output and doesn't mine anymore. It's most certainly overclock/undervolt related, just trying to figure out which, and troubleshoot efficiently. Gotcha. I have same behavior with stock bios, stock reg. Started when I upgraded to 0.8.1. You seem confident that it is OC/uV. Thanks for clarifying and let me know what you find. I'm going to downgrade to 0.7 and see if it fixes the issue on my end. Oh yes, and ofcourse I swapped out mobos. |
|
|
|
Odd...how much did you overclock?
Paste OverdriveNtool.ini or your settings for memclock etc.
nothing extreme  as I said 16 others works just fine ! Hate to ask this, but I'm assuming you already did DDU, reinstalled drivers, tried a different PCI slot. My guess is the card is suspect. Can you isolate this card on another system by itself to see if the issue carries over? |
|
|
|
So I've just flashed my 56's to 64 vbios and applied Hellae's "safe" reg file.
I've set some new frequencies in OverdriveNtool but CastXMR just keeps stopping on me after a few minutes. Does that mean I'm not giving the memory enough juice? Too much clock? Is it core related? Can anyone who's been through this help me troubleshoot the behaviour of the miner please?
...
Getting approx 1900h/s/card, total 1050w from the wall (6 GPUs).
Any suggestions welcome!
Can you elaborate on "stops" a little? Does the app crash/close, does it just stop output in the cmd shell....that kind of thing. Reason I ask is I have similar behavior where it just stops sending out put to the Window (nope it is not the Quick Edit setting). When I try to connect to the 7777 port my moniotoring script will pick up that it is hung and then it restarts the process. |
|
|
|
|
Odd...how much did you overclock?
Paste OverdriveNtool.ini or your settings for memclock etc.
|
|
|
|
|
Paste your overdrinentool.ini here.
|
|
|
|
|
Press "s" in the CMD window and paste the output here.
|
|
|
|
|
