Author

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

newbie
Activity: 417
Merit: 0
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  Grin Grin

So you getting about 2200h now or more?
yeah dok im sticking to 1.5.8 my vegas got higher output compared to 1.5.9. https://www.reddit.com/r/havenprotocol/comments/8ohw6t/haven_v3_hardfork_coming_in_2_weeks/ - haven is also forking.
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  Grin

al nije tako. 1.5.9. ti je  potpunao ista kao i 15.7 odnosno sporija od 1.5.8 pricamo o 200 HR manje po rigu kod vege kod heavy
hero member
Activity: 2548
Merit: 626
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 Smiley

+ 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  Grin.

Maxithanks for the support  Cool
hero member
Activity: 2548
Merit: 626
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  Grin Grin

So you getting about 2200h now or more?
yeah dok im sticking to 1.5.8 my vegas got higher output compared to 1.5.9. https://www.reddit.com/r/havenprotocol/comments/8ohw6t/haven_v3_hardfork_coming_in_2_weeks/ - haven is also forking.
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  Grin
newbie
Activity: 46
Merit: 0
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 Smiley

+ 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  Grin.

EDIT:
All 8 rigs now running with 1.5.9, and looking good.

Thanks, dok!
newbie
Activity: 417
Merit: 0
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  Grin Grin

So you getting about 2200h now or more?

he say 200 per RIG not per CARD
hero member
Activity: 2548
Merit: 626
thanks for forking infos guys, srb is prepared for stellitev4, the other two ill have to check them out.
jr. member
Activity: 113
Merit: 1
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  Grin Grin

So you getting about 2200h now or more?
yeah dok im sticking to 1.5.8 my vegas got higher output compared to 1.5.9. https://www.reddit.com/r/havenprotocol/comments/8ohw6t/haven_v3_hardfork_coming_in_2_weeks/ - haven is also forking.
https://www.reddit.com/r/stellite/comments/8p1tss/v4_mandatory_update_for_all_node_maintainers_of/ - stellite too
newbie
Activity: 18
Merit: 0
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  Grin Grin

So you getting about 2200h now or more?
newbie
Activity: 35
Merit: 0
Hey Doktor - any plans to support the new Masari algorithm (CN-Fast)?

See https://medium.com/@officialmasari/masari-launches-cn-fast-8d6a535a263f for details.
jr. member
Activity: 113
Merit: 1
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  Grin Grin

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 Smiley

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 Smiley
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. Wink
https://www.reddit.com/r/MoneroMining/comments/80vns0/announcement_moneroocean_pool_switches_to_multi/ - currently the only pool that multiswitch would be nice to have a miner like that. Thanks in advance!

Note: My vega hashdrop only happen because of 1-2 minutes disconnect from pool(this is normal since im using wireless/shared network).
I'll try lowering/disabling the Hashrate watchdog and report back.
newbie
Activity: 9
Merit: 0
Doktor,

i also have issue to report

goes like this
have 4 rigs, all 4 of them go from xmr stak to srbminer1.5.8
each rig 6x Vega 18.5.2
all 4 rigs run super stable with srbminer
one of the rigs i restart for some reason after like 2000 minutes of uptime
other 3 rigs run for like 3000-3500 minutes of uptime and then all crash at approximate the same time
the miner stopped saying  GPU hashrate 0, restarting miner, but miner could not restart, even by process kill or try to reset PC, it hangs in reset process. Only hard reset help

Why would all miners stop at same uptime? Shocked

Anyway, I reset all so can´t really say what happened or give any more details, but i will monitor this time and see if it happen again

Otherwise, i fell in love with your miner.

i have the same Problem, It got better with windows 1803 and amd driver 18.5.1
jr. member
Activity: 176
Merit: 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 Smiley

+ 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 Smiley
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
hero member
Activity: 2548
Merit: 626
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 Smiley

+ 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 Smiley
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}
jr. member
Activity: 176
Merit: 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 Smiley

+ 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.
hero member
Activity: 2548
Merit: 626
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  Grin Grin

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 Smiley

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 Smiley
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. Wink
jr. member
Activity: 158
Merit: 5
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  Grin Grin

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 Smiley

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.
member
Activity: 168
Merit: 15
doktor83, Claymore's miner used to crash like this sometimes, so I coped with it using Windows Scheduler - there should be an error in Application Log, I just got error code and triggered miner restart. I'm sure this is not correct, but it works )
hero member
Activity: 2548
Merit: 626
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 ?

newbie
Activity: 19
Merit: 0
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 Smiley

+ 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

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
hero member
Activity: 2548
Merit: 626
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  Grin Grin

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 Smiley
Jump to: