SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching

[livada]

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

{
"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

[lebuawu2]

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

{
"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.

[lebuawu2]

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

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.

[Elder III]

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.

[UnclWish]

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?

[UnclWish]

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?

[Sgsg666]

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

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.

This happened to me as well(vega miner got disconnected from pool 1-2 minutes) 5 mins hashrate watchdog got triggered , then continue mining for less 20h/s ave. 2nd trigger continue mining again less 30 h/s ave. I have logs: https://mega.nz/#!OaYRVJTI!Z5dsgQTfMxlVrn9fNdqdNvG36eIAx4smfpagUxMiM2U
I'll try your trick UnclWish. Tnx!

[Elder III]

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.

[doktor83]

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?

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.

[UnclWish]

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?

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.

I suggested that 1.5.9 also doing that... But 1.5.8 automatically creates new without needs to delete existing ))))
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?".

[UnclWish]

Is anyone uses old 270X cards? Wich settings best for V7 and heavy? What speed you're have?

[ragecage]

dok did you receive the heavy algo changes from devs?

[glowbg]

noticed that "max difficulty": made only 1 reload and the second reaching the maximum difficulty Miner freezes 

[knittycatkitty]

much appreciated, gotta try this out. just updated to 1.5.8 recently but i noticed after a few days the miner would just suddenly stop, hopefully its fixed! will update tonight

Do you have these kind of problems ?

https://i.imgur.com/OWzw7Or.png

no i did not, i would just check my monitoring app and see the miner not hashing after a few days of hashing just fine. remote desktop and i see that the miner app has closed and i have to start back up again,  

not a big deal however. the miner works great.

i haven't updated yet to 1.5.9 to see if it fixed it but i will update sometime tomorrow. will update with my findings.

[henri2018]

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?

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.

I suggested that 1.5.9 also doing that... But 1.5.8 automatically creates new without needs to delete existing ))))
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?".

UnclWish, I have this issue as well. And just like you, not too often but sometimes.

[vmozara]

Guys, can somebody explain what is the story with GPU-Z? What is the advantage of starting GPUZ while the miner is running? I tried and nothing really happened

[abg00]

Is anyone uses old 270X cards? Wich settings best for V7 and heavy? What speed you're have?

v7 530 h\s at 1150\1450 with undervolting and pathched bios
int 30

heavy 230 h\s

[m.vina]

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

Thank you for the continued updates, doc. These little incremental updates really add up and turn something simple into a masterful piece of software.
The dev fee is well deserved. Hopefully you can continue to add these updates as we go along. Again, thank you very much!

[trifo]

https://vg9uag.db.files.1drv.com/y4ml7N-y4suxdZZcuAVj14emkARJydoNDGsp0fSOw5KXwlYpTFJihY7jC9ykcrNdyTrV5ikt1G0IwbXEw5MgnnXrUtiJjBf16gvln4Ajm1R4uxW4XSJhTeT7wi_1vRzQRahkkXHIkUj1JQQbR5axcU0XvKWvbXoBjpAU0sD9gMjB47jwaRBx9hcPJKZqogV_J1gQBubIY1_GiW6tqeyPSYogw?width=1024&height=555&cropmode=none
Auto restart miner going wrong...
SRBMiner also have problem when lost connection to pool and only one pool in the list, dont accept command reload pools...
Posto mi engleski ocigledno ne ide Na slici je situacija od sinoc, miner je po nekom mom shvatanju probao da se restartuje ali je prethodni proces ostao aktivan... A ono sto sam primetio od ranije, samo dvaput mi se desilo sa starijim verzijama, izgubi konekciju sa poolom a ne registruje da je nema nego samo stane. I jos jedno zapazanje, kad izgubi konekciju i pokusava da se konektuje ne prihvata komandu reload pools, pokusavao sam da editujem pools.txt i da promenim pool ali nece, mozda cak nece nijednu komandu da prihvati ali to sad vec nisam siguran zaboravio sam...
Odlican posao Doktore samo tako nastavi... Sve najbolje

[dragonmike]

Another one problem - it's happens not too often but sometimes miner gives error - "Invalid nonce; is miner not compatible with NiceHash?".

I can confirm I'm getting this every now and then as well. Not too often, fortunately. I haven't tried to add the manual nicehash option. This might fix that, dunno.