Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 235. (Read 237247 times)
June 07, 2018, 02:12:36 AM
Is anyone uses old 270X cards? Wich settings best for V7 and heavy? What speed you're have?
June 07, 2018, 02:10:37 AM
I found interesting thing...
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
I have a theory of what could be the cause of this, great experiment by the way
On which card/cards is this happening?
edit: damn, 1.5.9 is also doing it, so you were unlucky. I started/deleted cached files 5x times and the 6x time it really hashed a little bit faster. This will be interesting to find the cause of it.
You must find why it's happening and how to create best kernel!
Cards is RX 580 8Gb hynix memory.
Another one problem - it's happens not too often but sometimes miner gives error - "Invalid nonce; is miner not compatible with NiceHash?".
June 07, 2018, 01:04:10 AM
I found interesting thing...
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
I have a theory of what could be the cause of this, great experiment by the way
On which card/cards is this happening?
edit: damn, 1.5.9 is also doing it, so you were unlucky. I started/deleted cached files 5x times and the 6x time it really hashed a little bit faster. This will be interesting to find the cause of it.
June 07, 2018, 12:55:07 AM
Well, I tried opening GPUZ while the miner was running just now and I can confirm that I did get a boost of ~50-60 Mhz per GPU. That's with 6 x Rx 580 8GB, 5 Micron Memory, 1 Hynix Memory - all stock Bios - 1250 Core, 2150 Memory, 925 mv Core, 950 mv Memory 18.5.1 drivers.
GPU-Z what version?I just doublechecked and it's GPU-Z version 2.8.0 that we are using on that rig. It's been running stable for several hours so far at the same hashrate... the easiest boost I've had so far with tweaking GPUs etc.
June 07, 2018, 12:14:36 AM
V1.5.9
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
wow many thanks dok, will try now mining on nicehash with max_difficulty.
ok, and report is it working like it should
You can define max_difficulty for every pool like :
{"pool" : "lotsofcoinspool1", "wallet" : "", "password" : "x", "max_difficulty" : 150000},
{"pool" : "lotsofcoinspool2", "wallet" : "", "password" : "x", "max_difficulty" : 400000}
yes I already define max_difficulty, will monitoring for a while.
just to let you know I can confirm hash rate drop after reconnecting to pool for RX Vega.
SRBMiner 1.5.9 AMD Driver 18.5.2.
First running.
https://imgur.com/a/pVgDVlp
After reconnect because of network error.
https://imgur.com/a/g4GC6xz
Edit :
Reconnecting due to high diff work perfectly.
https://imgur.com/a/8icbdsL
Bro, in my case, after reconnecting, the hashrate was drop. But after waiting a few minutes, it's back normal.
May be you were too quick to observe?
I checked now, after more than 7 hours my hash rate still drop from initial running.
I'll try your trick UnclWish. Tnx!
June 06, 2018, 10:15:41 PM
I found interesting thing...
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
June 06, 2018, 10:04:51 PM
Well, I tried opening GPUZ while the miner was running just now and I can confirm that I did get a boost of ~50-60 Mhz per GPU. That's with 6 x Rx 580 8GB, 5 Micron Memory, 1 Hynix Memory - all stock Bios - 1250 Core, 2150 Memory, 925 mv Core, 950 mv Memory 18.5.1 drivers.
GPU-Z what version? June 06, 2018, 09:22:54 PM
Well, I tried opening GPUZ while the miner was running just now and I can confirm that I did get a boost of ~50-60 Mhz per GPU. That's with 6 x Rx 580 8GB, 5 Micron Memory, 1 Hynix Memory - all stock Bios - 1250 Core, 2150 Memory, 925 mv Core, 950 mv Memory 18.5.1 drivers.
June 06, 2018, 06:49:55 PM
V1.5.9
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
wow many thanks dok, will try now mining on nicehash with max_difficulty.
ok, and report is it working like it should
You can define max_difficulty for every pool like :
{"pool" : "lotsofcoinspool1", "wallet" : "", "password" : "x", "max_difficulty" : 150000},
{"pool" : "lotsofcoinspool2", "wallet" : "", "password" : "x", "max_difficulty" : 400000}
yes I already define max_difficulty, will monitoring for a while.
just to let you know I can confirm hash rate drop after reconnecting to pool for RX Vega.
SRBMiner 1.5.9 AMD Driver 18.5.2.
First running.
https://imgur.com/a/pVgDVlp
After reconnect because of network error.
https://imgur.com/a/g4GC6xz
Edit :
Reconnecting due to high diff work perfectly.
https://imgur.com/a/8icbdsL
Bro, in my case, after reconnecting, the hashrate was drop. But after waiting a few minutes, it's back normal.
May be you were too quick to observe?
I checked now, after more than 7 hours my hash rate still drop from initial running.
June 06, 2018, 06:46:58 PM
pls give me comand to start NH i try but alvay error.
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
{
"pools" :
[
{"pool" : "cryptonightheavy.eu.nicehash.com:3364", "wallet" : "btcwallet", "password" : "x", "nicehash" : true}
]
}
ok . and max dif to end?
{"pool" : "cryptonightheavy.eu.nicehash.com:3364", "wallet" : "btcwallet", "password" : "x", "nicehash" : true, "max_difficulty" : 1100000}
this is it?
HR * 40 is normal dif? 12000*40 = 480000 and limit 1100000 is to high or
??and your port NH is 3364? my nH work on 3363 ...
PS: na v7 je skor oidentican HR na 15.8 i 1.5.9 al na heavy je HR dosta veci na 1.5.8
pool setting should be correct, the order doesn't matter.
port 3364 for cn-heavy and port 3363 for cn-v7.
mine 9500 h/s and I put max diff 800000 base on my observation.
June 06, 2018, 06:28:40 PM
pls give me comand to start NH i try but alvay error.
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
{
"pools" :
[
{"pool" : "cryptonightheavy.eu.nicehash.com:3364", "wallet" : "btcwallet", "password" : "x", "nicehash" : true}
]
}
ok . and max dif to end?
{"pool" : "cryptonightheavy.eu.nicehash.com:3364", "wallet" : "btcwallet", "password" : "x", "nicehash" : true, "max_difficulty" : 1100000}
this is it?
HR * 40 is normal dif? 12000*40 = 480000 and limit 1100000 is to high or
??and your port NH is 3364? my nH work on 3363 ...
PS: na v7 je skor oidentican HR na 15.8 i 1.5.9 al na heavy je HR dosta veci na 1.5.8
June 06, 2018, 05:38:12 PM
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo 
I thought there were my personal suspects, but checked again after reading this and yes, 1.5.8 is a little bit faster.1.5.9: "hashrate_total_30min": 7738
I've terminated it and run 1.5.8 with same configs: "hashrate_total_30min": 7746,
maybe new nicehash features add a tiny lag to a mining process?
June 06, 2018, 05:27:48 PM
pls give me comand to start NH i try but alvay error.
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
{
"pools" :
[
{"pool" : "cryptonightheavy.eu.nicehash.com:3364", "wallet" : "btcwallet", "password" : "x", "nicehash" : true}
]
}
June 06, 2018, 04:57:49 PM
V1.5.9
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
wow many thanks dok, will try now mining on nicehash with max_difficulty.
ok, and report is it working like it should
You can define max_difficulty for every pool like :
{"pool" : "lotsofcoinspool1", "wallet" : "", "password" : "x", "max_difficulty" : 150000},
{"pool" : "lotsofcoinspool2", "wallet" : "", "password" : "x", "max_difficulty" : 400000}
yes I already define max_difficulty, will monitoring for a while.
just to let you know I can confirm hash rate drop after reconnecting to pool for RX Vega.
SRBMiner 1.5.9 AMD Driver 18.5.2.
First running.
https://imgur.com/a/pVgDVlp
After reconnect because of network error.
https://imgur.com/a/g4GC6xz
Edit :
Reconnecting due to high diff work perfectly.
https://imgur.com/a/8icbdsL
pls give me comand to start NH i try but alvay error.
Where i write this?
"nicehash" : true, - i write this in config but error.
I write this in pool and agan error .
{"pool_use_tls" : false, "pool" : "cryptonightv7.eu.nicehash.com:3363", "wallet" : "address", "password" : "x", "max_difficulty" : 1500000}, for 6 vega
June 06, 2018, 04:55:27 PM
V1.5.9
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
wow many thanks dok, will try now mining on nicehash with max_difficulty.
ok, and report is it working like it should
You can define max_difficulty for every pool like :
{"pool" : "lotsofcoinspool1", "wallet" : "", "password" : "x", "max_difficulty" : 150000},
{"pool" : "lotsofcoinspool2", "wallet" : "", "password" : "x", "max_difficulty" : 400000}
yes I already define max_difficulty, will monitoring for a while.
just to let you know I can confirm hash rate drop after reconnecting to pool for RX Vega.
SRBMiner 1.5.9 AMD Driver 18.5.2.
First running.
https://imgur.com/a/pVgDVlp
After reconnect because of network error.
https://imgur.com/a/g4GC6xz
Edit :
Reconnecting due to high diff work perfectly.
https://imgur.com/a/8icbdsL
Bro, in my case, after reconnecting, the hashrate was drop. But after waiting a few minutes, it's back normal.
May be you were too quick to observe?
Hashrate drop after pool change (disconnect/connect) is normal, but the hash should stabilize back. The problem is if it won't go back at all.
But i am curious is this somethings specific to 18.5.2 drivers ?
June 06, 2018, 04:44:41 PM
Any hashrate increase? Like for 1.5.8. when you didn´t say anything and my vegas hashed like 200 more per rig, what a nice surprise
So you getting about 2200h now or more?
he say 200 per RIG not per CARD
Apologies, I misread..I got really excited but it's still better I suppose. Will try it out this weekend
June 06, 2018, 04:41:07 PM
V1.5.9
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
- Added "max_difficulty" parameter in pools, if reached miner will reconnect to pool
- Better logging on miner crash
- Kernels are now built in Cache directory
- Probably fixed situation when miner crashes on pool switch
- Fixed .srb file creation on every miner run
- Hopefully reduced nicehash duplicate share errors
- Changed the way devfee pools are used
+ Now you can define a "max_difficulty" for every pool you have in pools config. Sometimes it happens that pool sends abnormally high difficulty, and miner can't find a share for a long time. In this case, by setting "max_difficulty", when ever pool difficulty is higher than the value you set, miner disconnects and reconnects to the pool.
+ There is now a Cache directory where the miner creates cached versions of OpenCL kernels
+ Some reported miner crash after multiple pool disconnect/reconnects , not able to log in etc.. I hope i found the cause of it and fixed it
+ Learned from the previous big mistake with devfee pools hardcoded in the miner, now miner gets the list of devfee pools from http://srbminer.com, so please allow/don't block it on your firewall
wow many thanks dok, will try now mining on nicehash with max_difficulty.
ok, and report is it working like it should
You can define max_difficulty for every pool like :
{"pool" : "lotsofcoinspool1", "wallet" : "", "password" : "x", "max_difficulty" : 150000},
{"pool" : "lotsofcoinspool2", "wallet" : "", "password" : "x", "max_difficulty" : 400000}
yes I already define max_difficulty, will monitoring for a while.
just to let you know I can confirm hash rate drop after reconnecting to pool for RX Vega.
SRBMiner 1.5.9 AMD Driver 18.5.2.
First running.
https://imgur.com/a/pVgDVlp
After reconnect because of network error.
https://imgur.com/a/g4GC6xz
Edit :
Reconnecting due to high diff work perfectly.
https://imgur.com/a/8icbdsL
Bro, in my case, after reconnecting, the hashrate was drop. But after waiting a few minutes, it's back normal.
May be you were too quick to observe?
June 06, 2018, 04:18:30 PM
Any hashrate increase? Like for 1.5.8. when you didn´t say anything and my vegas hashed like 200 more per rig, what a nice surprise
So you getting about 2200h now or more?
https://www.reddit.com/r/stellite/comments/8p1tss/v4_mandatory_update_for_all_node_maintainers_of/ - stellite too
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo
unbelievable but true. my RX 550 2gb at 1.5.8 gave out stably 6590 hashes at setting 26/8/2, and on 1.5.9 neither as more than 6510 hashes
what happens on 27/8/2?
in this case, everything is not stable, or the cards do not start all at once, but only after a couple of reboots and after that in a couple of hours all the same 0 the hashes are shown and the reboot is going on. But on the other hand, the speed on version 1.5.8 strongly diverged by the indications on the pool, and 1.5.9 shows approximately equal values with the pool. So we stay on 1.5.9
I think 6500 with 13 RX 550 cards is a good result, the main thing is that there would be stability.Thank you for the miner.
June 06, 2018, 04:04:58 PM
Any hashrate increase? Like for 1.5.8. when you didn´t say anything and my vegas hashed like 200 more per rig, what a nice surprise
So you getting about 2200h now or more?
https://www.reddit.com/r/stellite/comments/8p1tss/v4_mandatory_update_for_all_node_maintainers_of/ - stellite too
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo
unbelievable but true. my RX 550 2gb at 1.5.8 gave out stably 6590 hashes at setting 26/8/2, and on 1.5.9 neither as more than 6510 hashes
what happens on 27/8/2?
June 06, 2018, 04:03:00 PM
Any hashrate increase? Like for 1.5.8. when you didn´t say anything and my vegas hashed like 200 more per rig, what a nice surprise
So you getting about 2200h now or more?
https://www.reddit.com/r/stellite/comments/8p1tss/v4_mandatory_update_for_all_node_maintainers_of/ - stellite too
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo
unbelievable but true. my RX 550 2gb at 1.5.8 gave out stably 6590 hashes at setting 26/8/2, and on 1.5.9 neither as more than 6510 hashes
Jump to: