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

[smeads]

When will the new version w/ the fixes for MKT be released? You should have mentioned this in the current release, I would not have released an update of my software with your newest mining software. Please push out the fix soon.

I plan on releasing the new version today, i couldn't mention that MKT isn't working because i did not know until i saw your screenshot

LOL.... fair enough... please ping me when you have it up. I own and wrote www.profitbotpro.com ... I want to make sure I get your updated files out as quickly as you release them. All my rigs cannot currently mine MKT....I was eager to switch to the new version which stopped my rigs from crashing daily on the new algo's. They were running solid for many many months without reboots, previously. I leave your dev fee in there, btw... so you guys get some $$ from the people using my software.

Randy/smeads/bearlyhealz

[doktor83]

In the top post, it is suggested to use Driver 19.3.2 for Cryptonight V4. I'm running a Vega 56 on 1.8.1, but since I updated my drivers from 18.6.1 to 19.3.2, I get low difficulty shares that get rejected by the pool every now and then. Any suggestions on how to solve this? And is anyone else running 56s in a similar manner? Is CC 1400/950, MC 950/900 optimal? Thanks in advance!

The 19.3.2 are recommended if you have miner crashes, but if everything works OK for you on 18.6.1 then stay with it.

[doktor83]

V1.8.2
- Upx and litev7 algos on auto settings now have more hashrate or lower power consumption, or both
- Reworked networking code, so probably get rid of a bug or two
- Another try to fix V4 algo crashing
- Maxnosharesent parameter default value is now 45 minutes
- Fixed MarketCash , it was broken in 1.8.1

+ Got some speedup on litev7 and upx algos if you use auto setup, mainly on Vegas and weak Rx550 - 560 cards, also power consumption dropped.

+ Another try to fix/postpone the crash that is happening on V4 algos. I would suggest to create/compile the kernel on 18.6.1 driver, then move to Adrenaline 2019 driver (19.3.2 for example).
Some users reported none/less crashes on newer drivers.

+ Fully rewrote the networking code so now :
- You will get 'Block expired' errors from some pools
- Lot's of rejects on Webchain algo

To explain : Some pools like Nicehash or Nanopool, do not accept stale shares (shares sent after a new job was dispatched). In earlier versions of SRB miner did not send these shares to the pool when it detected that a new job arrived in the mean time. Now these are sent too. I made this decision because i saw some discussions where people say that SRB displays higher hashrates than they really are, or steals hashrate ( ). This way user can see all shares - accepted and rejected, and can have a clearer picture of his real speed.

Webchain is a similar story, it rejects stale shares. And oh, there are a lot of those, because it has a short blocktime so new jobs just bam bam bam keep coming.
That's why you have 30% lower hashrate poolside than in miner. Yes i know Loud miner does not have this 'problem' so please use it instead if you have better results.

[smeads]

V1.8.2
- Upx and litev7 algos on auto settings now have more hashrate or lower power consumption, or both
- Reworked networking code, so probably get rid of a bug or two
- Another try to fix V4 algo crashing
- Maxnosharesent parameter default value is now 45 minutes
- Fixed MarketCash , it was broken in 1.8.1

+ Got some speedup on litev7 and upx algos if you use auto setup, mainly on Vegas and weak Rx550 - 560 cards, also power consumption dropped.

+ Another try to fix/postpone the crash that is happening on V4 algos. I would suggest to create/compile the kernel on 18.6.1 driver, then move to Adrenaline 2019 driver (19.3.2 for example).
Some users reported none/less crashes on newer drivers.

+ Fully rewrote the networking code so now :
- You will get 'Block expired' errors from some pools
- Lot's of rejects on Webchain algo

To explain : Some pools like Nicehash or Nanopool, do not accept stale shares (shares sent after a new job was dispatched). In earlier versions of SRB miner did not send these shares to the pool when it detected that a new job arrived in the mean time. Now these are sent too. I made this decision because i saw some discussions where people say that SRB displays higher hashrates than they really are, or steals hashrate ( ). This way user can see all shares - accepted and rejected, and can have a clearer picture of his real speed.

Webchain is a similar story, it rejects stale shares. And oh, there are a lot of those, because it has a short blocktime so new jobs just bam bam bam keep coming.
That's why you have 30% lower hashrate poolside than in miner. Yes i know Loud miner does not have this 'problem' so please use it instead if you have better results.

Awesome!! Thank you. I can confirm MKT works perfectly on all my rigs.

[GKumaran]

Hey doc, it's only nicehash and nanopool that are so Hard on rejects, the miner still will send the stales right?? Cause major pools like supportxmr still use the shares for last job unless a new block is found.

This does give better hashrate for the miner. I know most people say fake hashrate, but those who understand it appreciate it 😃😃

[kissmarx]

I prefer using SRBminer over the one I;m using now because SRB gives me higher hashrate. But what I don't understand is why my IP address is banned in hashvault if I use SRB. Yet if I switch to another mining software, it is not banned.  

[GKumaran]

New Version tests:
Driver - 18.6.1
Card - Vege 64s reference models
All algos run on same PPT/ODT configs.
All algos run in default AUTO config, with no additional tweaks.
Kernal have been compiled afresh.

Algorithm	HR	Power	HR/watt	HR	Power	HR/watt	Change%
CN lite v7	4400	177.5	24.789	4500	169.25	26.588	7.26%
CN UPX	8572	187.25	45.778	8763	179.5	48.819	6.643%
CN Mox	4165	205	20.317	4167	204.85	20.342	0.123%
CN Turtle	16740	205	81.659	16760	204	82.157	0.610%

Massive efficiency improvements in the v7 based 1mb algorithms. Would be great if these advantage could be reached in v8 based 1mb(256kb) algos.
Thanks for the update doc.

[doktor83]

Hey doc, it's only nicehash and nanopool that are so Hard on rejects, the miner still will send the stales right?? Cause major pools like supportxmr still use the shares for last job unless a new block is found.

This does give better hashrate for the miner. I know most people say fake hashrate, but those who understand it appreciate it 😃😃

Only Nanopool had the 'stale protection', of course they were sent already

[doktor83]

I prefer using SRBminer over the one I;m using now because SRB gives me higher hashrate. But what I don't understand is why my IP address is banned in hashvault if I use SRB. Yet if I switch to another mining software, it is not banned.  

I don't understand this either. Which algo and how long it takes until it gets you banned? Maybe you have a long log for me ?

[chimaeraa]

doc is perfect. thank you.
just use one loop in bat file.

[eduardooaz]

Guys, for monero algo what is the best intensity for 4gb cards (RX570/RX580) and should we use double or single tread in the 4gb?
And trying to do manualy the program simpyl closes itself, in ID we need to put the BUS number right?

[n3st34]

V1.8.2
- Upx and litev7 algos on auto settings now have more hashrate or lower power consumption, or both
- Reworked networking code, so probably get rid of a bug or two
- Another try to fix V4 algo crashing
- Maxnosharesent parameter default value is now 45 minutes
- Fixed MarketCash , it was broken in 1.8.1

+ Got some speedup on litev7 and upx algos if you use auto setup, mainly on Vegas and weak Rx550 - 560 cards, also power consumption dropped.

+ Another try to fix/postpone the crash that is happening on V4 algos. I would suggest to create/compile the kernel on 18.6.1 driver, then move to Adrenaline 2019 driver (19.3.2 for example).
Some users reported none/less crashes on newer drivers.

+ Fully rewrote the networking code so now :
- You will get 'Block expired' errors from some pools
- Lot's of rejects on Webchain algo

To explain : Some pools like Nicehash or Nanopool, do not accept stale shares (shares sent after a new job was dispatched). In earlier versions of SRB miner did not send these shares to the pool when it detected that a new job arrived in the mean time. Now these are sent too. I made this decision because i saw some discussions where people say that SRB displays higher hashrates than they really are, or steals hashrate ( ). This way user can see all shares - accepted and rejected, and can have a clearer picture of his real speed.

Webchain is a similar story, it rejects stale shares. And oh, there are a lot of those, because it has a short blocktime so new jobs just bam bam bam keep coming.
That's why you have 30% lower hashrate poolside than in miner. Yes i know Loud miner does not have this 'problem' so please use it instead if you have better results.

new version is great
6xvega64 GPU@1447/memory@1100 (-+1300w)
drivers 18.5.1
hashrate ~12,4KH/s (2.5% rejected shares on nanopool)

looks rock solid after 12 hours of running (last version run hardly 4 hours)

great work doc!!!

[kissmarx]

I prefer using SRBminer over the one I;m using now because SRB gives me higher hashrate. But what I don't understand is why my IP address is banned in hashvault if I use SRB. Yet if I switch to another mining software, it is not banned.  

I don't understand this either. Which algo and how long it takes until it gets you banned? Maybe you have a long log for me ?

I get banned in just minutes of mining. So far I only used this SRB version to mine Cryptonight Conceal and Cryptonight R algos. But I found out today that when I restart the miner a couple of minutes later, it works out fine.

[turtleminor13]

Hello doktor83
I found a minor bug with setting intensity on the turtle algo.  Auto settings are very good (thanks to you), and I get well over 8k hashrate with my rx480 8gb cards auto set at 104 intensity.  But I do want to tweak intensity a bit for each of my cards to get the last bit of hashrate and long-running stability.  However when I manually set intensity, even to the same 104 value picked by auto, hashrate drops to below 6k.  Here are my settings:

--ccryptonighttype turtle --cpool pool --cwallet wallet --cpassword workername --logfile srbmineTRTL.log --ckeepalive true --cnicehash false --showstales --gpureorder --cgpuid 0,1,2,3,4 --cgputhreads 2,2,2,2,2 --cgpuintensity 0,0,0,0,0 --minrigspeed 41000

When I change only intensity setting to --cgpuintensity 0,104,0,0,0 then that one card set manually has large hashrate drop.  I've tried all 5 of my cards with same results.  I discovered this on v1.8.1, and it still happens with latest v.1.8.2.  Didn't try it on previous versions.

I also mine haven algo, and manual intensity setting is working fine there and I can get max hashrate/stability dialed in.  Thanks for taking a look at this when you get a chance.

[doktor83]

Hello doktor83
I found a minor bug with setting intensity on the turtle algo.  Auto settings are very good (thanks to you), and I get well over 8k hashrate with my rx480 8gb cards auto set at 104 intensity.  But I do want to tweak intensity a bit for each of my cards to get the last bit of hashrate and long-running stability.  However when I manually set intensity, even to the same 104 value picked by auto, hashrate drops to below 6k.  Here are my settings:

--ccryptonighttype turtle --cpool pool --cwallet wallet --cpassword workername --logfile srbmineTRTL.log --ckeepalive true --cnicehash false --showstales --gpureorder --cgpuid 0,1,2,3,4 --cgputhreads 2,2,2,2,2 --cgpuintensity 0,0,0,0,0 --minrigspeed 41000

When I change only intensity setting to --cgpuintensity 0,104,0,0,0 then that one card set manually has large hashrate drop.  I've tried all 5 of my cards with same results.  I discovered this on v1.8.1, and it still happens with latest v.1.8.2.  Didn't try it on previous versions.

I also mine haven algo, and manual intensity setting is working fine there and I can get max hashrate/stability dialed in.  Thanks for taking a look at this when you get a chance.

yep a bug, i can reproduce on 480 cards.
On vegas its ok.

Going to fix

edit:

looking at it, it's not a bug afterall.
Auto sets you everything : intensity, threads, worksize, fragments.
On manual you should set everything.

You did not set worksize, and it is using a default worksize of 16 which is not good for 480 cards.
Insert --cgpuworksize 8,8,8,8,8 and you should get the same results as on auto.

[MinermanNC]

Can 1.8.2 handle more than 4 cards on a single rig? Windows 10. Have issues when i connect a 5th and 6th card. With 4 it does fine. Seems it can find the device/bus . Only finds 2 cards, shows the rest in red and not hashing, eventually DEAD, after i connect 5th card. Ok, didn't know if its another issue. I am aware that with W10 and cards more than 4 there is other things to consider. only having this problems with SBR 1.8.2

[doktor83]

Can 1.8.2 handle more than 4 cards on a single rig? Windows 10. Have issues when i connect a 5th and 6th card. With 4 it does fine. Seems it can find the device/bus . Only finds 2 cards, shows the rest in red and not hashing, eventually DEAD, after i connect 5th card. Ok, didn't know if its another issue. I am aware that with W10 and cards more than 4 there is other things to consider. only having this problems with SBR 1.8.2

People use it with 10+ cards so yes, it can handle more than 4

[thenextdinosaur]

Hi doktor, I have a question.
I'm mining using the start-algo-switching.bat to mine on MoneroOcean and I have one specific card that sometimes has some strange behavior. I use OverdriveNTool to set the fan speed at 3000 RPM for each card. I reset the vegas and apply the clock+fan speed once while starting the miner. Sometimes during mining (I don't know if it's during the algo switch or not) I have one card that the fan goes to 700 RPM, making it a lot hotter than the other cards. If I manually close the miner and start it up again, the reset vegas + overdriventool makes the fan run at 3000 RPM again. So I don't want to be so quick to judge that this is a hardware problem.

This happens very randomly. it might be twice a day or once every 4-5 days.

So now the question: how would be the proper way to identify a high temperature for this specific card (or drop in the hashrate, since the Vega throttles and the hashrate gets lower) and to trigger a custom batch file (that in this case would simply restart the computer)? how can I use reboot_script_gpu_watchdog or reboot_script_min_rig_speed but to trigger for one specific card? I don't have one single config.txt file because I'm using algo switch.

Thanks a lot

[MinermanNC]

Can 1.8.2 handle more than 4 cards on a single rig? Windows 10. Have issues when i connect a 5th and 6th card. With 4 it does fine. Seems it can find the device/bus . Only finds 2 cards, shows the rest in red and not hashing, eventually DEAD, after i connect 5th card. Ok, didn't know if its another issue. I am aware that with W10 and cards more than 4 there is other things to consider. only having this problems with SBR 1.8.2

People use it with 10+ cards so yes, it can handle more than 4

ok, Just wanted to be sure its confirmed it works with 4 plus cards

Thanks for the quick reply 

Will keep investigating the system.

[patmontes]

Hi Dok
Thanks for 1.8.2 as it runs stable for me for already 24hours and counting....

By the way would you be able to explain how the miner makes this parameter work? --cgputargettemperature

I mean I know what it does but how does it manage the temp?