Bug in 1.5.9
I tested the max_difficulty:
When reached the value set, program restarted OK but from "CryptonightV7 mode enabled" to "Heating up system" took more than 1 minute.
After that, even restarting Windows, every time I start 1.5.9 it takes more than 1 minute to start, about 1:20
Had to go back to 1.5.8 to have a normal start.
max_difficulty isn't restarting the miner, it's only reconnecting to the pool. |
|
|
|
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. this error can not be avoided, this is something specific to stupid nicehash and their custom protocol. |
|
|
|
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.
Logs would be awesome for me to debug the problem, as always  |
|
|
|
noticed that "max difficulty": made only 1 reload and the second reaching the maximum difficulty Miner freezes  i need more data, logs maybe if available, cause i tested this option for half day *that was ~ 80 reconnects because of max_diff* and it never froze,always reconnected to the pool. |
|
|
|
dok did you receive the heavy algo changes from devs?
Haven ? yes, i got everything i need |
|
|
|
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. |
|
|
|
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} ] } |
|
|
|
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/pVgDVlpAfter reconnect because of network error. https://imgur.com/a/g4GC6xzEdit : Reconnecting due to high diff work perfectly. https://imgur.com/a/8icbdsLBro, 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 ? |
|
|
|
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? |
|
|
|
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 Cool stuff, dok. Starting to move to 1.5.9 now, 5 left remaining . Maxithanks for the support |
|
|
|
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo |
|
|
|
|
thanks for forking infos guys, srb is prepared for stellitev4, the other two ill have to check them out.
|
|
|
|
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} |
|
|
|
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 lol,no not this time. I am surprised too because i had a 0.2-0.3% hash increase on my 580 8g test card, so thats so low i did not want to mention it, but looks like its more than 0.2% on Vegas Great update, good thinking on devfee pool settings, although a hardcoded fallback in code would still be beneficial. Doktor, how costly is algo change? I'm working on a simple coin switching proxy (forked from a sebseb7's repository of cryptonote-proxy) which works well for same algo coins. The upside is there's no hasrate drop between changes as SRBMiner (or any other miner connected to it) just sees it as a new job. That said, just as GPU's can run several different shaders, how hard would it be to change algo without a restart? Memory would be reserved for the one with the most mem requirements. It would be awesomely dandy if SRB could do this, it would support an extra json property to change algos in the job request. There are hardcoded fallbacks, in case the site isn't reachable, those are used. I hope they will never be used I know about that proxy, i like the idea , it can be very useful for coin switching on the fly. Algo switching could be a problem, but a very easy and elegant way would be just to restart miner with the new config. It shouldn't take more than 15-20 sec if the user has cached files. It's interesting that you ask this now, because i am in a phase of planning and working on a built-in coin switching (for same algo) in SRBminer based on profitability.  |
|
|
|
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 ?  |
|
|
|
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 lol,no not this time. I am surprised too because i had a 0.2-0.3% hash increase on my 580 8g test card, so thats so low i did not want to mention it, but looks like its more than 0.2% on Vegas |
|
|
|
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
|
|
|
|
V1.5.8
- Fixed a bug in pool switching process
- Fixed a bug in watchdog's "reboot_script"
- Changed default devfee pool for Heavy algo
+ I would like to politely ask everyone if they appreciate my work, to switch their miners to this new version.
The default devfee pool for heavy algo was pool.sumokoin.com, which is under the control of the origin Sumo team.
They self-decided, without any community voting or anything to switch their algo back to now ASIC friendly Cryptonight from block 137500.
That will happen in about two days.
What this means to users of SRBMiner/Me ? On previous versions if you mine any coin on 'heavy' algo from monday, the devfee will connect to pool.sumokoin.com using 'heavy' algo,
but the pool will be using classic CN, so shares will be ALL rejected, and i won't be getting the 0.85% fee.
Thank you in advance, if you are going to support me and going to switch to this version.
Done, buddy. Thanks for your awesome work. All my AMD rigs (and my friends') are sporting your miner. thank you very much! Kisses to all of you |
|
|
|
I confirm a strange hashrate drop on 18.5.2 with CN7, although it starts from a better result. E.g. 8 x Vega64 gave ~14000 on 18.4.1, now it runs at ~14200, but sevaral hours later it can drop to 13700. Miner restart helps. And it is definitely not throttling or overheating, because they are liquid cooled edition and don't raise above 50C. Rolled one rig back to 18.4.1.
this is where the "min_rig_speed" parameter comes handy |
|
|
|
guys, do you know how to set the fan speed and GPU temperature detection? I'm using Rx 580 Nitro + 8Gb Micron memory. It currently does not show me this data. I attach photos. Thank you  driver version? reinstall driver with cleanup yes, install newer drivers that will allow BUS ID's to be detected correctly, and then you can set fan speed. |
|
|
|
|
Show Posts
