[ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 232.

KiloWatts

member

Activity: 119

Merit: 10

Quote from: guzzzi on June 13, 2014, 07:32:47 AM

Quote from: Adz on June 13, 2014, 06:49:51 AM

Quote from: DarkAGeS on June 13, 2014, 02:46:22 AM

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

I use sgminer-5.0-pre-release-2014-06-11
That looks like my situation, but my 270x not stoped but started mine with very slow speed (20k instead of 230k). In the same time other rig with 280x switched without problems.
Distinctions in configs are:
270x config:

Code:

"pool-gpu-threads" : "2",
"pool-rawintensity": "5120",
"pool-thread-concurrency" : "6336"

280x config just define:

Code:

"pool-intensity" : "13"

this options defined in general part of 280x config (not pool part):

Code:

"gpu-threads" : "2",
"thread-concurrency" : "8192",

I think there is a problem with pool-gpu-threads and pool-thread-concurrency options - they dont work right according to my observations. On windows miner just crash if I even define same pool-gpu-threads for all pools. On linux (bamt) it works but with bugs

I had the same problem with 2x of my rigs dropping out when autoswitching,. On one of the rigs the GPU reported dead and the other rig wasn't hashing. Only thing is I don't have either pool-gpu-threads or pool-thread-concurrency in my pool section.
I have since changed the "failover-switch-delay" from 30 to 60 to see if that makes a difference during the autoswitch

i tryed the "failover-switch-delay" with the same result. As soon he switch to nscrypt all my gpus go off. terrible so many times today. think i will go back to mine one algo till this is fixed or solution is ready. cant babysit all the day.

Failover-switch-delay doesn't appear to do anything here. (there is no delay)

DiCE1904

legendary

Activity: 1118

Merit: 1002

Has anyone got this working with PiMP? If so howd you do it please

mannyg

full member

Activity: 142

Merit: 101

Quote from: CounterStrike on June 13, 2014, 07:48:42 AM

Is this miner as stable as the other miner for r9 280x and r9 290?

Stable for both my 280x and 290's, but the switching kills my 290s,.. not my 280x's. I have my 290's mining with auto-switching disabled and switching to the profitable algo when ever i get around to seeing it change

CounterStrike

sr. member

Activity: 294

Merit: 250

Is this miner as stable as the other miner for r9 280x and r9 290?

guzzzi

newbie

Activity: 53

Merit: 0

Quote from: Adz on June 13, 2014, 06:49:51 AM

Quote from: DarkAGeS on June 13, 2014, 02:46:22 AM

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

I use sgminer-5.0-pre-release-2014-06-11
That looks like my situation, but my 270x not stoped but started mine with very slow speed (20k instead of 230k). In the same time other rig with 280x switched without problems.
Distinctions in configs are:
270x config:

Code:

"pool-gpu-threads" : "2",
"pool-rawintensity": "5120",
"pool-thread-concurrency" : "6336"

280x config just define:

Code:

"pool-intensity" : "13"

this options defined in general part of 280x config (not pool part):

Code:

"gpu-threads" : "2",
"thread-concurrency" : "8192",

I think there is a problem with pool-gpu-threads and pool-thread-concurrency options - they dont work right according to my observations. On windows miner just crash if I even define same pool-gpu-threads for all pools. On linux (bamt) it works but with bugs

I had the same problem with 2x of my rigs dropping out when autoswitching,. On one of the rigs the GPU reported dead and the other rig wasn't hashing. Only thing is I don't have either pool-gpu-threads or pool-thread-concurrency in my pool section.
I have since changed the "failover-switch-delay" from 30 to 60 to see if that makes a difference during the autoswitch

i tryed the "failover-switch-delay" with the same result. As soon he switch to nscrypt all my gpus go off. terrible so many times today. think i will go back to mine one algo till this is fixed or solution is ready. cant babysit all the day.

Adz

newbie

Activity: 24

Merit: 0

Quote from: DarkAGeS on June 13, 2014, 02:46:22 AM

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

I use sgminer-5.0-pre-release-2014-06-11
That looks like my situation, but my 270x not stoped but started mine with very slow speed (20k instead of 230k). In the same time other rig with 280x switched without problems.
Distinctions in configs are:
270x config:

Code:

"pool-gpu-threads" : "2",
"pool-rawintensity": "5120",
"pool-thread-concurrency" : "6336"

280x config just define:

Code:

"pool-intensity" : "13"

this options defined in general part of 280x config (not pool part):

Code:

"gpu-threads" : "2",
"thread-concurrency" : "8192",

I think there is a problem with pool-gpu-threads and pool-thread-concurrency options - they dont work right according to my observations. On windows miner just crash if I even define same pool-gpu-threads for all pools. On linux (bamt) it works but with bugs

I had the same problem with 2x of my rigs dropping out when autoswitching,. On one of the rigs the GPU reported dead and the other rig wasn't hashing. Only thing is I don't have either pool-gpu-threads or pool-thread-concurrency in my pool section.
I have since changed the "failover-switch-delay" from 30 to 60 to see if that makes a difference during the autoswitch

DarkAGeS

full member

Activity: 219

Merit: 100

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

I use sgminer-5.0-pre-release-2014-06-11
That looks like my situation, but my 270x not stoped but started mine with very slow speed (20k instead of 230k). In the same time other rig with 280x switched without problems.
Distinctions in configs are:
270x config:

Code:

"pool-gpu-threads" : "2",
"pool-rawintensity": "5120",
"pool-thread-concurrency" : "6336"

280x config just define:

Code:

"pool-intensity" : "13"

this options defined in general part of 280x config (not pool part):

Code:

"gpu-threads" : "2",
"thread-concurrency" : "8192",

I think there is a problem with pool-gpu-threads and pool-thread-concurrency options - they dont work right according to my observations. On windows miner just crash if I even define same pool-gpu-threads for all pools. On linux (bamt) it works but with bugs

KiloWatts

member

Activity: 119

Merit: 10

Grumble... well, I just got this when it switched to Scrypt:

Code:

[02:34:21] Accepted 01d0895f Diff 141/64 GPU 1 at NiceHash_Scrypt-N 
[02:34:21] Stratum connection to NiceHash_Scrypt-N interrupted
[02:34:31] Waiting for work to be available from pools.
[02:34:34] NiceHash_Scrypt-N not responding!
[02:34:34] Switching to NiceHash_Scrypt
[02:34:34] NiceHash_Scrypt difficulty changed to 256
[02:34:41] Work available from pools, resuming.
[02:34:41] Building binary zuikkisHawaiigw256l4lg2tc32765nf10.bin
[02:34:57] Initialising kernel zuikkis.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[02:34:57] Initialising kernel zuikkis.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[02:34:57] Error -4: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[02:34:57] Error -4: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[02:34:57] GPU 0 failure, disabling!
[02:34:57] GPU 1 failure, disabling!
[02:35:37] Shutdown signal received.

Turned both GPUs off immediately. I agree, I think a 60-second buffer would be a good idea.

platinum4

sr. member

Activity: 547

Merit: 250

Quote from: guzzzi on June 13, 2014, 12:26:57 AM

Quote from: KiloWatts on June 13, 2014, 12:17:59 AM

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

Have you tested X13 on its own first to see if it's stable? (non-multiswitch port 3337)

I think it's wise with this multiswitching to be a little more conservative with how hard you push the GPUs, since you add the variable of switching. Keep your engine, clock, intensity, slightly lower than you would if you're mining only 1 algorithm. After you find settings that allow smooth switching, slowly tweak from there.

Yes working 100%. Switching between Scrypt/X11/X13 working perfect everythink runs stable. But NScrypt kills my GPU as soon there was a switch back to NScrypt.
Ok will try to set the Settings a little bit lower. But isnt it possible for SGMiner to start Algos slower? So reduce the Speed for the first minute to a minimum of speed, after that start to raise to the final configuration in full speed?

Yep I think we need a full 60 seconds at least for a memory flush to avoid those -4 Errors but I am not a chip designer.

guzzzi

newbie

Activity: 53

Merit: 0

Quote from: KiloWatts on June 13, 2014, 12:17:59 AM

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

Have you tested X13 on its own first to see if it's stable? (non-multiswitch port 3337)

I think it's wise with this multiswitching to be a little more conservative with how hard you push the GPUs, since you add the variable of switching. Keep your engine, clock, intensity, slightly lower than you would if you're mining only 1 algorithm. After you find settings that allow smooth switching, slowly tweak from there.

Yes working 100%. Switching between Scrypt/X11/X13 working perfect everythink runs stable. But NScrypt kills my GPU as soon there was a switch back to NScrypt.
Ok will try to set the Settings a little bit lower. But isnt it possible for SGMiner to start Algos slower? So reduce the Speed for the first minute to a minimum of speed, after that start to raise to the final configuration in full speed?

Elun

member

Activity: 117

Merit: 10

For everyone who have issues with sgminer_5 and "device" option, you can use this option in configure file, until it is not fixed:
"remove-disabled" : true

KiloWatts

member

Activity: 119

Merit: 10

Quote from: guzzzi on June 13, 2014, 12:02:14 AM

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

Have you tested X13 on its own first to see if it's stable? (non-multiswitch port 3337)

I think it's wise with this multiswitching to be a little more conservative with how hard you push the GPUs, since you add the variable of switching. Keep your engine, clock, intensity, slightly lower than you would if you're mining only 1 algorithm. After you find settings that allow smooth switching, slowly tweak from there.

guzzzi

newbie

Activity: 53

Merit: 0

Again ... about 6 Hours ago. N-Scrypt running well the last 15 Hours, then in the Night it switched to X13 and again back to N-Scrypt. 5 of my GPUs go off and 1 got the turn and was running well in the right speed Sad

Any solution for this? Missing 6 Hours every Day hurts.

W0rkH0rse

member

Activity: 80

Merit: 10

Quote from: Elun on June 12, 2014, 12:01:27 AM

Quote from: mannyg on June 11, 2014, 10:11:34 PM

Quote from: cryptofunk on June 11, 2014, 08:12:47 PM

Quote from: mannyg on June 11, 2014, 07:20:46 PM

Quote from: KiloWatts on June 11, 2014, 07:16:20 PM

Quote from: mannyg on June 11, 2014, 07:00:08 PM

Quote from: KiloWatts on June 11, 2014, 06:45:48 PM

Quote from: mannyg on June 11, 2014, 06:43:29 PM

I really would rather see the switching happen on the server end rather than the client...

That would be impossible... the miners are on the client side. The server just rents the hash speed out.

It might be possible with a whole new algorithm dedicated to giving hashrate to the server on the backend. It would need to be designed from the ground up just for this sole purpose.

Hmm... That still seems insanely impossible... For instance, you're essentially talking about trying to 'convert' Scrypt hashes to X11 hashes, or vice versa... Trying to match a hash with 1 algorithm is already difficult enough, yeah?

mmmm yeahh something like that. If it is possible, it opens up the door to a whole new world of possibilities... ESPECIALLY if you can do it with sha-256 to x11 or scrypt ... hell or whatever actually works. My ASIC miners for SHA run like clockwork for weeks straight, .. the GPU rigs are quickly taking up all of my time again now with the multi-algo switching.

*edit*
Think of a mining algo in which a GPU rig connects to, mines, and its work gets automatically converted to the X11, X13, etc. etc. hell, name the kernel nicehash.cl ... it would need to be a proprietary design

Guys, think about it, it's just impossible. SHA256, X11, X13, nFactor, Scrypt are all algorithms, what we submit to the pool is the result of that algorithm (mathematical operation). What you are asking is basically for the server to do the job for you (hence mine for you).

You can't take a SHA256 (or whatever else) hash and convert it to X11, X13, etc. The reason why they come up with those algos is in part to make them asic resistant (for a while at least), so that GPUs remain somewhat profitable.

For a server to "convert" a hash into another algo's hash would literally imply that the server would have to do the work for you which defeats the purpose of mining (you're supposed to be doing the work yourself, not the server).

So the data contained in the share that your GPU hashed and submitted cant be translated and converted into a different share? Maybe in a scenario of miner to miner on both ends? In the end, isnt it just data of 1's and 0's?

Suggest that you can convert hash from one algo to another: fuck cryptography in this case. For example "blablabla" without quotes in sha256:

Code:

892cd4be79b2bea361b51a472ef8a587730ca3c95816e1a2a8761a82a787bbdf

and same in sha-3 256:

Code:

0744ea4be0f20ad77cace16010f20019a126a4fd1e07cc5f9d2e59c316cbcf02

No link between them, except encrypted word inside. Hashing algorithms are one-way i.e. They cannot be reversed unlike Encryption-Decryption algorithms. You can use with same probability random number generator for mining.

What if you attached some sort of trigger to the pool share difficulty change command received which would force the program to switch to a different config/kernel?
Also, you are a rockstar and I've nominated you and benmagro for the nobel prize in the (requested but not yet existent) bitcoin category. So far no response from the Queen/committee.

mannyg

full member

Activity: 142

Merit: 101

Quote from: mannyg on June 12, 2014, 06:31:53 PM

I've come across a new problem with my 290 rig.

When an algo switch happens like the recent one from scrypt-n to X13, sgminer stops hashing and quits. If I restart it, one of my 290's loses control of its temp and it sky rockets way higher than the other 290's. If I restart the rig and start sgminer, same thing keeps happening. I've even tried to remove the 290's from device manager and have them redetect the drivers, same problem. The temp problem only happens with algos like scrypt and scrypt-n that are very GPU intensive

Until now, the only solution around it is to power off the rig, unplug the PSU, wait a few minutes, then fire it all back up. Only then is everything mining at the same temp across all 3 GPUs.

I've never had this issue until i started using the newer sgminer v5's. Any thoughts?

Figured out my own problem... GPU had a lazy fan... had to set gpu-fan to 100 to keep it going

KiloWatts

member

Activity: 119

Merit: 10

Quote from: phzi on June 12, 2014, 07:08:28 PM

Quote from: comeonalready on June 12, 2014, 11:30:22 AM

Quote from: mrbrdo on June 11, 2014, 03:16:42 PM

Quote from: comeonalready on June 11, 2014, 02:53:31 PM

You guys really mucked up the implementation of the extranonce subscription extension. Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default. You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.

Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do. But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there. Or was sabotaging your competitors part of the original plan?

I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out).

I posted that message to the nicehash forum over a month ago (not yesterday!), and your having removed that surrounding context does indeed make that last sentence sound kinda stupid. Nicehash devised that stratum protocol extension, with this glaring flaw, and it was so easy to get right too. All they needed to do to make it fully compatible with other pools without having to worry whether it was enabled or disabled by default in the client was to initiate the transaction from the server side -- by sending a "mining.subscribe_extranonce" message (or something like it) to the client and have it handled in within the parse_method function of a compatible cgminer/sgminer and ignored by all the rest -- instead of sending a subscribe.extranonce message before a mining.authorize message to all other unexpecting pools.

And no, it is never too late to change something that is clearly broken. The problem is a custom stratum protocol extension implemented by nicehash, for nicehash, and negatively effecting so many miners on other pools, including many who have no idea what is happening or how to disable it, thereby causing them to assume that there is something wrong with many other pools, when it is in fact their mining software at fault. At the very least, it should be disabled by default!

comeonalready speaks the truth.

Yeah... just change:

"no-extranonce-subscribe" : true

to

"extranonce-subscribe" : true

and set default to false.

Problem solved.

KiloWatts

member

Activity: 119

Merit: 10

Yes! Flawless!

Scrypt-N to X13:

Code:

[18:51:16] Accepted aef2d217 Diff 374/256 GPU 1 at NiceHash_Scrypt-N 
[18:52:44] Accepted 1124f706 Diff 3.82K/256 GPU 0 at NiceHash_Scrypt-N 
[18:53:33] Accepted 97e9d35c Diff 431/256 GPU 0 at NiceHash_Scrypt-N 
[18:54:04] Accepted 7fd25f61 Diff 512/256 GPU 1 at NiceHash_Scrypt-N 
[18:54:26] Stratum connection to NiceHash_Scrypt-N interrupted
[18:54:36] Waiting for work to be available from pools.
[18:54:40] NiceHash_Scrypt-N not responding!
[18:54:40] Switching to NiceHash_X13
[18:54:40] NiceHash_X13 difficulty changed to 0.040
[18:54:46] Work available from pools, resuming.
[18:54:46] Building binary marucoin-modHawaiigw256l4big4.bin
[18:55:13] Initialising kernel marucoin-mod.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[18:55:13] NiceHash_Scrypt_Regular_Backup extranonce change requested
[18:55:13] Initialising kernel marucoin-mod.cl with bitalign, unpatched BFI, nfactor 10, n 1024
[18:55:45] Accepted 0bfc38c3 Diff 0.083/0.040 GPU 1 at NiceHash_X13 
[18:57:30] Accepted 0234fd59 Diff 0.453/0.040 GPU 1 at NiceHash_X13 
[18:58:19] Accepted 1533d1b6 Diff 0.047/0.040 GPU 1 at NiceHash_X13 
[18:58:35] Accepted 05732ed5 Diff 0.183/0.040 GPU 1 at NiceHash_X13

X13 to Scrypt-N

Code:

[19:13:21] Accepted 0f733c31 Diff 0.065/0.040 GPU 0 at NiceHash_X13 
[19:13:36] Accepted 064edf7b Diff 0.159/0.040 GPU 0 at NiceHash_X13 
[19:13:37] NiceHash_Scrypt-N alive, testing stability
[19:13:40] Accepted 0e8566c8 Diff 0.069/0.040 GPU 1 at NiceHash_X13 
[19:13:52] Accepted 15fd453d Diff 0.045/0.040 GPU 0 at NiceHash_X13 
[19:14:11] NiceHash_Scrypt-N stable for 30 seconds
[19:14:11] Switching to NiceHash_Scrypt-N
[19:14:12] Initialising kernel zuikkis.cl with bitalign, unpatched BFI, nfactor 11, n 2048
[19:14:12] Initialising kernel zuikkis.cl with bitalign, unpatched BFI, nfactor 11, n 2048
[19:14:26] Stratum connection to NiceHash_X13 interrupted
[19:15:18] Accepted fd2487d2 Diff 258/256 GPU 1 at NiceHash_Scrypt-N 
[19:15:23] NiceHash_Scrypt-N stale share detected, discarding
[19:15:51] Accepted 7d121b05 Diff 523/256 GPU 1 at NiceHash_Scrypt-N 
[19:16:18] Accepted 08c921f6 Diff 7.46K/256 GPU 0 at NiceHash_Scrypt-N

phzi

hero member

Activity: 700

Merit: 500

Quote from: comeonalready on June 12, 2014, 11:30:22 AM

Quote from: mrbrdo on June 11, 2014, 03:16:42 PM

Quote from: comeonalready on June 11, 2014, 02:53:31 PM

You guys really mucked up the implementation of the extranonce subscription extension. Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default. You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.

Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do. But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there. Or was sabotaging your competitors part of the original plan?

I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out).

I posted that message to the nicehash forum over a month ago (not yesterday!), and your having removed that surrounding context does indeed make that last sentence sound kinda stupid. Nicehash devised that stratum protocol extension, with this glaring flaw, and it was so easy to get right too. All they needed to do to make it fully compatible with other pools without having to worry whether it was enabled or disabled by default in the client was to initiate the transaction from the server side -- by sending a "mining.subscribe_extranonce" message (or something like it) to the client and have it handled in within the parse_method function of a compatible cgminer/sgminer and ignored by all the rest -- instead of sending a subscribe.extranonce message before a mining.authorize message to all other unexpecting pools.

And no, it is never too late to change something that is clearly broken. The problem is a custom stratum protocol extension implemented by nicehash, for nicehash, and negatively effecting so many miners on other pools, including many who have no idea what is happening or how to disable it, thereby causing them to assume that there is something wrong with many other pools, when it is in fact their mining software at fault. At the very least, it should be disabled by default!

comeonalready speaks the truth.

mannyg

full member

Activity: 142

Merit: 101

I've come across a new problem with my 290 rig.

When an algo switch happens like the recent one from scrypt-n to X13, sgminer stops hashing and quits. If I restart it, one of my 290's loses control of its temp and it sky rockets way higher than the other 290's. If I restart the rig and start sgminer, same thing keeps happening. I've even tried to remove the 290's from device manager and have them redetect the drivers, same problem. The temp problem only happens with algos like scrypt and scrypt-n that are very GPU intensive

Until now, the only solution around it is to power off the rig, unplug the PSU, wait a few minutes, then fire it all back up. Only then is everything mining at the same temp across all 3 GPUs.

I've never had this issue until i started using the newer sgminer v5's. Any thoughts?

platinum4

sr. member

Activity: 547

Merit: 250

Quote from: Adz on June 12, 2014, 04:40:05 PM

Quote from: mannyg on June 11, 2014, 04:33:50 PM

Quote from: KiloWatts on June 11, 2014, 02:37:09 PM

Yep, this version doesn't work right with NScrypt and 14.1 drivers.

Here's the same config with 13.12 drivers. Still not ideal, but better.

Yeah I'm on 13.12 drivers and I refuse to upgrade. You might need to start looking at different TC's to tweak the speed. I've seen a number of 290 configs using TC 32765

I used to have 24550 on my 290's, but the 2% rejects started to bother me regardless of how great the hashrate was. I changed it to 25600 and now my reject % is below .5%.

Hey guys are you talking about the AMD Catalyst Drivers? i'm a late scrypt-n adopter, haven't mined it outside of this multipool setup on nicehash
Thanks

Yep 14's will drop your performance on nscrypt

Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 232. (Read 877859 times)