Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 227. (Read 237263 times)

ok, now i know its not the new devfee method that is problematic.
But i would suggest to try now a previous version that you know was working good.
Nothing was changed in the new version in the GPU's initialisation process (this is where it hangs), so my guess is something at your side is causing this.

I did not know how this works, I thought it was detected automatically.
About the time, I think it depends on how often the pool sets difficulty too high.
This option could be very useful for pools with badly configured vardiff to avoid loosing shares.
So, for me the shortest the best but every one is different
Maybe a command to choose between 1 & 60 secs.

I also getting this, suddenly all GPU hashing speed 0 h/s.

[2018-06-10 00:41:42] pool_ping: Sent keepalive message to pool
[2018-06-10 00:41:42] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"KEEPALIVED"}}
[2018-06-10 00:41:42] json_receive: Pool responded with KEEPALIVED
[2018-06-10 00:42:07] watchdog: GPU0 [BUS: 1] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU1 [BUS: 2] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU2 [BUS: 3] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU3 [BUS: 4] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU4 [BUS: 5] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU5 [BUS: 6] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU6 [BUS: 9] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU7 [BUS: 10] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU8 [BUS: 11] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU9 [BUS: 12] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU10 [BUS: 13] hashing speed is 0 H/S
[2018-06-10 00:42:07] watchdog: GPU11 [BUS: 15] hashing speed is 0 H/S
[2018-06-10 00:42:33] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"0707d1a3f0d805256279b460556b7c15ee3cd01fcdba90cfdadfbdcc0654c667f5a4ae0a9a78530 00000001ab26cc8554f6b2671add6a9c76cbaaa20eb9f31179f7e0d5c9d969a8fd7194303","job_id":"276673124018431","target":"cf8b0000"}}
[2018-06-10 00:42:38] pool_ping: Sent keepalive message to pool
[2018-06-10 00:42:38] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"KEEPALIVED"}}
[2018-06-10 00:42:38] json_receive: Pool responded with KEEPALIVED
[2018-06-10 00:42:56] shut_down_miner exception: Resource deadlock avoided
[2018-06-10 00:42:56] Stopping miner process

Reproduced
[2018-06-10 02:38:44] Heating up system, please wait...

[2018-06-10 02:38:43] CryptonightV7 mode enabled
[2018-06-10 02:38:44] DevFee pools loaded
[2018-06-10 02:38:44] DevFee pool SET
[2018-06-10 02:38:44] DevFee address SET

V1.6.0
- Added support for Haven new algo after fork (block 89200)
- Added support for Masari new algo (fast) after fork (block 204000)
- Job timeout default is now 20 minutes
- More logging on miner startup
- Added option 'persistent_memory' in gpu_conf

+ 2 new algos added : 'haven' and 'fast'
So after the fork you can use them like :

"cryptonight_type" : "fast"
"cryptonight_type" : "haven"


+ As some have issues with miner 'just waiting some time' on startup, i added more logging option so we can catch where it hangs, and i can possibly fix that
+ 'persistent_memory' parameter added to gpu_conf, basically what it does is tries to allocate some memory that is normally not available to the GPU. It can increase hashrate in some ocassions, by finding the right intensity and threads setup, but also it can make the gpu crash, so it's up to you to experiment

I am still looking for the cause of random miner crashes (mostly on new 'great' win 1803 update), also for the abnormality that causes higher hashrate on after X runs.

From 1.4.9 to 1.5.9 was 10 versions. I don't want to find in wich version what was changed. But you must understand that through 10 versions same settings can used by miner different ways. Just try to lower intensity and increase pagefile size to 8Gb * number of videocards.

1.4.9 works, and 1.5.9 gives the following error
with the same settings

It's a silicone lottery too... 4x Sapphire, 2x Gigabyte, 1x Asus

2 of the 4 Sapphire and the Asus are hit over 510+ H\s I have to get a box fan for it now though no ac or windows in this part of the house, it's about 88-90* in there

You can read? Miner all wrote to you. Not enogh memory on card. Lower intensity.

what caused the error ?

Hey Dok, thanks for the update. I just started playing with persistent_memory. I know that your notes in CAPS after each option shown in the ReadMe are meant to be purely informational, but you may want to change the TRUE OR FALSE to lower case or use it in an example config to limit potential confusion, since the parser will throw an error if true/false is in CAPS when loading.

Keep up the great work!

I keep getting this now on 1.5.9 every now and then.  Nothing changed in settings.
shut_down_miner exception: Resource deadlock avoided