Bitcoin Forum
August 01, 2021, 08:48:46 AM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 [341] 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 »
  Print  
Author Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching  (Read 235663 times)
doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 02, 2019, 08:21:46 AM
 #6801

The latest version 1.8.7 works perfectly for upx2. CPU is not overloaded. On the contrary on the same rig running at the same time srbminer and xmrig.

Will try it out, i used the 1.8.6 version yesterday. Otherwise i will use the "old_mode" solution.

Thanks a lot:)

I tested the 1.8.7 version and the "old_mode" method and in my case none of them helped. Still the cpu is at 99% and it's throttling my gpu's. With "old_mode" : true the hashrate drops even further, around 22kh/s per card. Is there anything else i can do?

Doctor, did you found out what's causing the cpu overload?

Nah, not really possible that with old mode enabled still 99%. Yes, hashrate is little lower on some algos with it enabled because more work is done on the GPU, and almost none on the CPU.

I exactly know why it's giving more load on the cpu, because upx job round is done in less than 100ms, and a 1,2,4mb scratchpaded job is done in ~2s.
Rewriting some stuff to use intrinsics, so cpu load will be lower. But still old mode enabled should decrease your cpu load a lot.

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
1627807726
Hero Member
*
Offline Offline

Posts: 1627807726

View Profile Personal Message (Offline)

Ignore
1627807726
Reply with quote  #2

1627807726
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1627807726
Hero Member
*
Offline Offline

Posts: 1627807726

View Profile Personal Message (Offline)

Ignore
1627807726
Reply with quote  #2

1627807726
Report to moderator
1627807726
Hero Member
*
Offline Offline

Posts: 1627807726

View Profile Personal Message (Offline)

Ignore
1627807726
Reply with quote  #2

1627807726
Report to moderator
amorphis22
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
May 02, 2019, 10:34:12 AM
Last edit: May 02, 2019, 01:26:44 PM by amorphis22
 #6802

Hi Doktor!

Noriced when using gpureorder hashrate table and found share list are not equal.
Hashrate table is correct.

2019-05-02 13:33:42] GPU1[BUS:18] result 0x2AC35BCD accepted for job[7] [195ms]
[2019-05-02 13:33:42] GPU0 :    56304 H/s [T: 64c, RPM: 3302, CC: 1408 MHz, MC: 970 MHz][BUS:3]
[2019-05-02 13:33:42] GPU1 :    61957 H/s [T: 65c, RPM: 3499, CC: 1408 MHz, MC: 1100 MHz][BUS:8]
[2019-05-02 13:33:42] GPU2 :    61483 H/s [T: 63c, RPM: 3313, CC: 1408 MHz, MC: 1095 MHz][BUS:11]
[2019-05-02 13:33:42] GPU3 :    56613 H/s [T: 57c, RPM: 3635, CC: 1408 MHz, MC: 990 MHz][BUS:18]
[2019-05-02 13:33:42] GPU4 :    59985 H/s [T: 64c, RPM: 3724, CC: 1408 MHz, MC: 1075 MHz][BUS:22]
[2019-05-02 13:33:42] GPU5 :    67075 H/s [T: 60c, RPM: 3295, CC: 1408 MHz, MC: 1075 MHz][BUS:25]
[2019-05-02 13:33:42] Total:    363417 H/s
[2019-05-02 13:33:46] GPU0[BUS:3] result 0x156FBE0E accepted for job[7] [201ms]
[2019-05-02 13:33:47] GPU5[BUS:11] result 0xD5726E9D accepted for job[7] [195ms]
[2019-05-02 13:33:47] GPU3[BUS:8] result 0x801D62F8 accepted for job[7] [194ms]
[2019-05-02 13:33:54] GPU3[BUS:8] result 0x9575D679 accepted for job[7] [200ms]
[2019-05-02 13:33:56] GPU4[BUS:25] result 0xAACF5A44 accepted for job[7] [201ms]
[2019-05-02 13:33:58] GPU1[BUS:18] result 0x401FDA9E accepted for job[7] [201ms]
[2019-05-02 13:34:08] GPU3[BUS:8] result 0x80274AAD accepted for job[7] [195ms]
[2019-05-02 13:34:10] GPU2[BUS:22] result 0x557C5F8A accepted for job[7] [194ms]
[2019-05-02 13:34:12] GPU2[BUS:22] result 0x6AD29592 accepted for job[7] [195ms]
[2019-05-02 13:34:15] GPU2[BUS:22] result 0x557EBD5A accepted for job[7] [195ms]
[2019-05-02 13:34:17] GPU5[BUS:11] result 0xD5802A03 accepted for job[7] [194ms]
[2019-05-02 13:34:17] GPU3[BUS:8] result 0x95807C9D accepted for job[7] [201ms]
[2019-05-02 13:34:34] GPU2[BUS:22] result 0x6ADC6630 accepted for job[7] [194ms]
[2019-05-02 13:34:35] GPU1[BUS:18] result 0x2AD9FDCB accepted for job[7] [194ms]

Also, parameters configured in gpu config applies to unexpected GPUs.

ver. 1.8.7
optii
Newbie
*
Offline Offline

Activity: 23
Merit: 3


View Profile
May 02, 2019, 02:52:24 PM
Last edit: May 02, 2019, 07:25:00 PM by optii
 #6803

hi Dok,

if i have ElioVP tool open in windows, SRB miner starts without tweak_profiles and i cant enable them. Vice versa if i start SRB miner i cant open ElioVP GUI tool, gives error and it crashes. Is that intended as tweak profiles are basically those suggested timings on the elioVP topic on bitcointalk?
doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 03, 2019, 05:41:23 AM
 #6804

hi Dok,

if i have ElioVP tool open in windows, SRB miner starts without tweak_profiles and i cant enable them. Vice versa if i start SRB miner i cant open ElioVP GUI tool, gives error and it crashes. Is that intended as tweak profiles are basically those suggested timings on the elioVP topic on bitcointalk?

Intended - you even get a message about it in the log, and no, the timings are not predefined, the values are calculated based on your values found at the moment of miner start.

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 03, 2019, 05:41:58 AM
 #6805

Hi Doktor!

Noriced when using gpureorder hashrate table and found share list are not equal.
Hashrate table is correct.

2019-05-02 13:33:42] GPU1[BUS:18] result 0x2AC35BCD accepted for job[7] [195ms]
[2019-05-02 13:33:42] GPU0 :    56304 H/s [T: 64c, RPM: 3302, CC: 1408 MHz, MC: 970 MHz][BUS:3]
[2019-05-02 13:33:42] GPU1 :    61957 H/s [T: 65c, RPM: 3499, CC: 1408 MHz, MC: 1100 MHz][BUS:8]
[2019-05-02 13:33:42] GPU2 :    61483 H/s [T: 63c, RPM: 3313, CC: 1408 MHz, MC: 1095 MHz][BUS:11]
[2019-05-02 13:33:42] GPU3 :    56613 H/s [T: 57c, RPM: 3635, CC: 1408 MHz, MC: 990 MHz][BUS:18]
[2019-05-02 13:33:42] GPU4 :    59985 H/s [T: 64c, RPM: 3724, CC: 1408 MHz, MC: 1075 MHz][BUS:22]
[2019-05-02 13:33:42] GPU5 :    67075 H/s [T: 60c, RPM: 3295, CC: 1408 MHz, MC: 1075 MHz][BUS:25]
[2019-05-02 13:33:42] Total:    363417 H/s
[2019-05-02 13:33:46] GPU0[BUS:3] result 0x156FBE0E accepted for job[7] [201ms]
[2019-05-02 13:33:47] GPU5[BUS:11] result 0xD5726E9D accepted for job[7] [195ms]
[2019-05-02 13:33:47] GPU3[BUS:8] result 0x801D62F8 accepted for job[7] [194ms]
[2019-05-02 13:33:54] GPU3[BUS:8] result 0x9575D679 accepted for job[7] [200ms]
[2019-05-02 13:33:56] GPU4[BUS:25] result 0xAACF5A44 accepted for job[7] [201ms]
[2019-05-02 13:33:58] GPU1[BUS:18] result 0x401FDA9E accepted for job[7] [201ms]
[2019-05-02 13:34:08] GPU3[BUS:8] result 0x80274AAD accepted for job[7] [195ms]
[2019-05-02 13:34:10] GPU2[BUS:22] result 0x557C5F8A accepted for job[7] [194ms]
[2019-05-02 13:34:12] GPU2[BUS:22] result 0x6AD29592 accepted for job[7] [195ms]
[2019-05-02 13:34:15] GPU2[BUS:22] result 0x557EBD5A accepted for job[7] [195ms]
[2019-05-02 13:34:17] GPU5[BUS:11] result 0xD5802A03 accepted for job[7] [194ms]
[2019-05-02 13:34:17] GPU3[BUS:8] result 0x95807C9D accepted for job[7] [201ms]
[2019-05-02 13:34:34] GPU2[BUS:22] result 0x6ADC6630 accepted for job[7] [194ms]
[2019-05-02 13:34:35] GPU1[BUS:18] result 0x2AD9FDCB accepted for job[7] [194ms]

Also, parameters configured in gpu config applies to unexpected GPUs.

ver. 1.8.7

Going to check this out, thanks for reporting.
Bus is always the right one, i adjust the gpu number related to bus id.

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
k08r4
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
May 03, 2019, 11:18:51 AM
 #6806

Greeting,
I have seen this little programmer for restart, but I do not know how to set it up. I tried to start the bat fail from the zip, but nothing happens. Do you need to add one of the desired 3 tracking scenarios at the start of the mining and how?
I'm new to this, I tried to find an instruction but I did not succeed and I can not program it
Markyz23
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
May 03, 2019, 12:27:23 PM
 #6807

The latest version 1.8.7 works perfectly for upx2. CPU is not overloaded. On the contrary on the same rig running at the same time srbminer and xmrig.

Will try it out, i used the 1.8.6 version yesterday. Otherwise i will use the "old_mode" solution.

Thanks a lot:)

I tested the 1.8.7 version and the "old_mode" method and in my case none of them helped. Still the cpu is at 99% and it's throttling my gpu's. With "old_mode" : true the hashrate drops even further, around 22kh/s per card. Is there anything else i can do?

Doctor, did you found out what's causing the cpu overload?

Nah, not really possible that with old mode enabled still 99%. Yes, hashrate is little lower on some algos with it enabled because more work is done on the GPU, and almost none on the CPU.

I exactly know why it's giving more load on the cpu, because upx job round is done in less than 100ms, and a 1,2,4mb scratchpaded job is done in ~2s.
Rewriting some stuff to use intrinsics, so cpu load will be lower. But still old mode enabled should decrease your cpu load a lot.


Fixed the issue, my config was not properly structured and it didn't initialize old_mode. Now the hashrate is great and the cpu workload is around 55%.

Great job doctor.

doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 03, 2019, 12:31:29 PM
 #6808

The latest version 1.8.7 works perfectly for upx2. CPU is not overloaded. On the contrary on the same rig running at the same time srbminer and xmrig.

Will try it out, i used the 1.8.6 version yesterday. Otherwise i will use the "old_mode" solution.

Thanks a lot:)

I tested the 1.8.7 version and the "old_mode" method and in my case none of them helped. Still the cpu is at 99% and it's throttling my gpu's. With "old_mode" : true the hashrate drops even further, around 22kh/s per card. Is there anything else i can do?

Doctor, did you found out what's causing the cpu overload?

Nah, not really possible that with old mode enabled still 99%. Yes, hashrate is little lower on some algos with it enabled because more work is done on the GPU, and almost none on the CPU.

I exactly know why it's giving more load on the cpu, because upx job round is done in less than 100ms, and a 1,2,4mb scratchpaded job is done in ~2s.
Rewriting some stuff to use intrinsics, so cpu load will be lower. But still old mode enabled should decrease your cpu load a lot.


Fixed the issue, my config was not properly structured and it didn't initialize old_mode. Now the hashrate is great and the cpu workload is around 55%.

Great job doctor.



Currently i achieved to lower the cpu usage by around 40% without the old_mode enabled, still working on it, maybe i can lower it more.
Weak CPU + lot of GPU's in rig + low difficulty can really make your CPU sweat.

I am surprised that your cpu usage is 55% with old_mode, that must be some really weak CPU in there Smiley

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
ipe4enko
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
May 04, 2019, 08:48:27 AM
Last edit: May 04, 2019, 09:02:15 AM by ipe4enko
 #6809

Hi doktor83.

After upgrade on version 1.8.7 because i catch error "- Fixed a bug with pool reconnect on job timeout" on version 1.8.6
Now after miner start i always have in log mesage.


[2019-05-04 10:33:56] hashrate: GPU0: 0 H/s [T:48c][BUS:1]
[2019-05-04 10:33:56] hashrate: GPU1: 0 H/s [T:46c][BUS:4]
[2019-05-04 10:33:56] hashrate: GPU2: 0 H/s [T:41c][BUS:6]
[2019-05-04 10:33:56] hashrate: GPU3: 0 H/s [T:49c][BUS:8]
[2019-05-04 10:33:56] hashrate: GPU4: 0 H/s [T:48c][BUS:9]
[2019-05-04 10:33:56] hashrate: GPU5: 0 H/s [T:46c][BUS:10]
[2019-05-04 10:33:56] hashrate: GPU6: 0 H/s [T:43c][BUS:11]
[2019-05-04 10:33:56] hashrate: GPU7: 0 H/s [T:50c][BUS:12]
[2019-05-04 10:33:56] hashrate: GPU8: 0 H/s [T:42c][BUS:13]
[2019-05-04 10:33:56] hashrate: GPU9: 0 H/s [T:40c][BUS:14]
[2019-05-04 10:33:56] hashrate: GPU10: 0 H/s [T:45c][BUS:15]
[2019-05-04 10:33:56] hashrate: GPU11: 0 H/s [T:37c][BUS:16]
[2019-05-04 10:33:56] hashrate: GPU12: 0 H/s [T:39c][BUS:17]
[2019-05-04 10:33:56] hashrate: Total: 0 H/s

After this, the speed is normalized and working several minutes. And then message with all card is 0H/s repeat and computer restart. This behaviour on 2 my rig.
Log here
https://pastebin.com/uyxj7wmq
doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 04, 2019, 09:11:15 AM
Last edit: May 04, 2019, 09:24:43 AM by doktor83
 #6810

Hi doktor83.

After upgrade on version 1.8.7 because i catch error "- Fixed a bug with pool reconnect on job timeout" on version 1.8.6
Now after miner start i always have in log mesage.


[2019-05-04 10:33:56] hashrate: GPU0: 0 H/s [T:48c][BUS:1]
[2019-05-04 10:33:56] hashrate: GPU1: 0 H/s [T:46c][BUS:4]
[2019-05-04 10:33:56] hashrate: GPU2: 0 H/s [T:41c][BUS:6]
[2019-05-04 10:33:56] hashrate: GPU3: 0 H/s [T:49c][BUS:8]
[2019-05-04 10:33:56] hashrate: GPU4: 0 H/s [T:48c][BUS:9]
[2019-05-04 10:33:56] hashrate: GPU5: 0 H/s [T:46c][BUS:10]
[2019-05-04 10:33:56] hashrate: GPU6: 0 H/s [T:43c][BUS:11]
[2019-05-04 10:33:56] hashrate: GPU7: 0 H/s [T:50c][BUS:12]
[2019-05-04 10:33:56] hashrate: GPU8: 0 H/s [T:42c][BUS:13]
[2019-05-04 10:33:56] hashrate: GPU9: 0 H/s [T:40c][BUS:14]
[2019-05-04 10:33:56] hashrate: GPU10: 0 H/s [T:45c][BUS:15]
[2019-05-04 10:33:56] hashrate: GPU11: 0 H/s [T:37c][BUS:16]
[2019-05-04 10:33:56] hashrate: GPU12: 0 H/s [T:39c][BUS:17]
[2019-05-04 10:33:56] hashrate: Total: 0 H/s

After this, the speed is normalized and working several minutes. And then message with all card is 0H/s repeat and computer restart. This behaviour on 2 my rig.
Log here
https://pastebin.com/uyxj7wmq

Happens because kernel precompilation takes a lot of time on those slow cards so watchdog triggers in the mean time. This v4 precompilation It also fu**s up the min_rig_speed.
Disable watchdog or set it to disable mode - temporary fix. I will try to do something with this..

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
sharmanov
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
May 04, 2019, 02:53:04 PM
 #6811

How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled
doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 04, 2019, 02:55:54 PM
 #6812

How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled

Run as admin, its in the readme

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
sharmanov
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
May 04, 2019, 02:58:41 PM
 #6813

How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled

Run as admin, its in the readme

I did. it still shows disabled
doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 04, 2019, 03:52:18 PM
 #6814

How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled

Run as admin, its in the readme

I did. it still shows disabled

Are you running version 1.8.7 ?
If so, look at the log file at the beginning theres more info why is tweaking disabled, if not running 1.8.7 then thats the problem  Smiley

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
clancy182
Newbie
*
Offline Offline

Activity: 21
Merit: 0


View Profile
May 04, 2019, 05:04:58 PM
 #6815

What driver recommend for new version 1.8.5?
Are we need to apply memory timing after that?

I still think that 18.6.1 creates the fastest code, if you are compiling.
If you have Vegas you can use the built in 'tweaking profiles' or use ElioVP's tool but first disable SRB tweaking with --disabletweaking switch
Ok then, ill try tweaking profile, if vega56 samsung can reach 2100+, ill move from teamred,
I like your api remote

My Vega56 hynix reaches 2100+, so you should do much better Smiley

Hey, can you post what driver you are using and what ODN settings? I know you wrote "just pushed mem up to 940mhs and P7 to 925mV."
But can you please elaborate a little bit on how you achieved that?

Cheers

Here's a video for you :
https://youtu.be/QyJzAhdDnPg

hi dok,
in the video, how can u have so low temp with 2300 rmp
i have 4 vega 56 with stock bios and i reach like 65-70°...
what is the light mode with ODT that u mentioned in this video ?
i use 1.8.7 srbminer with 18.6.1 without softpowerplay table

JG
crpt0x
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
May 05, 2019, 11:20:32 AM
 #6816

Hi,

doktor83 is there some parameter to disable a gpu in config or in START.BAT like keyboard shortcuts but will remain after miner restarts? I have a gpu that I'd like to disable for a while.
Markyz23
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
May 05, 2019, 04:59:52 PM
 #6817

The latest version 1.8.7 works perfectly for upx2. CPU is not overloaded. On the contrary on the same rig running at the same time srbminer and xmrig.

Will try it out, i used the 1.8.6 version yesterday. Otherwise i will use the "old_mode" solution.

Thanks a lot:)

I tested the 1.8.7 version and the "old_mode" method and in my case none of them helped. Still the cpu is at 99% and it's throttling my gpu's. With "old_mode" : true the hashrate drops even further, around 22kh/s per card. Is there anything else i can do?

Doctor, did you found out what's causing the cpu overload?

Nah, not really possible that with old mode enabled still 99%. Yes, hashrate is little lower on some algos with it enabled because more work is done on the GPU, and almost none on the CPU.

I exactly know why it's giving more load on the cpu, because upx job round is done in less than 100ms, and a 1,2,4mb scratchpaded job is done in ~2s.
Rewriting some stuff to use intrinsics, so cpu load will be lower. But still old mode enabled should decrease your cpu load a lot.


Fixed the issue, my config was not properly structured and it didn't initialize old_mode. Now the hashrate is great and the cpu workload is around 55%.

Great job doctor.



Currently i achieved to lower the cpu usage by around 40% without the old_mode enabled, still working on it, maybe i can lower it more.
Weak CPU + lot of GPU's in rig + low difficulty can really make your CPU sweat.

I am surprised that your cpu usage is 55% with old_mode, that must be some really weak CPU in there Smiley

Checked again after a while and it's down to 30-35%. It's a Intel Celeron G3900, the most affordable one for mining. Sold my Ryzens.
As far as i read this ann, there's a lot of improvement for Vega cards but almost none for the RX series. Is there any juice left for you to squeeze out of them or should i start considering buying Vega's now when they are cheap?

doktor83
Hero Member
*****
Offline Offline

Activity: 1722
Merit: 611


View Profile WWW
May 06, 2019, 12:12:44 PM
Last edit: May 08, 2019, 11:01:48 AM by doktor83
 #6818

V1.8.8
- Reduced CPU usage up to ~50%, can be noticed on algos with small scratchpad
- User is now informed about tweaking status on the screen too, not just in log
- No more --gpureorder, device ordering by bus id is now the default/only display mode
- Added parameter --watchdogrounds , which controls after how many rounds will watchdog trigger
- min_rig_speed_duration default is 1 minute now, because of the new --watchdogrounds parameter
- Fixed a few cosmetical things on web stats


+ If not using 'old_mode', on weak CPU's the cpu usage could go boom on algos with small scratchpad (UPX2, Turtle). In this version i managed to lower the cpu usage up to ~50%.
This also brings a small hashrate increase for RX cards on UPX2 as a side effect Smiley

+ The default (and only) device ordering mode from now on is ascending by bus id, as it is in OverdriveNTool. Parameter --gpureorder is removed.
NOTE: if you are using gpu_conf or --cgpuid, please run --listdevices to check if you are using the right deviceid!

+ Because of some trouble with gpu/min_rig_speed watchdog and kernel precompilation on CN/R (V4), a new parameter --watchdogrounds was added, so you can control after how many check-rounds will the watchdog trigger.
The GPU crash watchdog has a fixed interval of 30 seconds = 1 round. That means it will trigger miner restart only after --watchdogrounds * 30 sec (default number of rounds is 5).
5 * 30 = 150 sec ~ 2.5 minutes. If gpu crashes and can't recover for 2.5 minutes, the miner will trigger the restart action.

min_rig_speed parameter is also affected by --watchdogrounds from now on. The 'min_rig_speed_duration' parameter default value is now 60 sec, this is the value as the above for the gpu crash watchdog, except that you can change the value of this to anything >= 30 sec.
Taking the default value of 60 seconds and 5 rounds, it is 5 * 60 = 300 sec = 5 minute, that means if for 5 minutes the 'min_rig_speed' < total hashing speed, then it will trigger miner restart.

SRBPolaris thread - HERE   |   SRBMiner-CN thread - HERE    |   SRBMiner-MULTI thread - HERE
http://www.srbminer.com
clousian
Newbie
*
Offline Offline

Activity: 33
Merit: 0


View Profile
May 07, 2019, 12:12:17 AM
Last edit: May 07, 2019, 12:23:58 AM by clousian
 #6819

Anyone have any experience running SRB v1.8.7 as a client in minerstat? Whatever I do in the config file, it doesn't translate when I launch srb in minerstat.

My settings for monero:
{
"cryptonight_type" : “normalv4”,
"intensity" : 0,
"double_threads" : true,
"gpu_conf" :
[
   {
     "id" : 0,
     "intensity" : 106,
     "worksize" : 8,
     "threads" : 2,
     "old_mode" : true
   },
   {
     "id" : 1,
     "intensity" : 59,
     "worksize" : 8,
     "threads" : 2,
     "old_mode" : true
   },
   {
     "id" : 2,
     "intensity" : 106,
     "worksize" : 8,
     "threads" : 2,
     "old_mode" : true
   },
   {
     "id" : 3,
     "intensity" : 105,
     "worksize" : 8,
     "threads" : 2,
     "old_mode" : true
   },
   {
     "id" : 4,
     "intensity" : 105,
     "worksize" : 8,
     "threads" : 2,
     "old_mode" : true
   }
]
}

What srb in minerstat is stuck at:

id 0,2,3,4 at 71 intensity id: 1 at 56 intensity. What am I doing wrong in the normalv4 config?
optii
Newbie
*
Offline Offline

Activity: 23
Merit: 3


View Profile
May 07, 2019, 08:07:58 AM
 #6820

V1.8.8
- Reduced CPU usage up to ~50%, can be noticed on algos with small scratchpad
- User is now informed about tweaking status on the screen too, not just in log
- No more --gpureorder, device ordering by bus id is now the default/only display mode
- Added parameter --watchdogrounds , which controls after how many rounds will watchdog trigger
- min_rig_speed_duration default is 1 minute now, because of the new --watchdogrounds parameter
- Fixed a few cosmetical things on web stats


+ If not using 'old_mode', on weak CPU's the cpu usage could go boom on algos with small scratchpad (UPX2, Turtle). In this version i managed to lower the cpu usage up to ~50%.
This also brings a small hashrate increase for RX cards on UPX2 as a side effect Smiley

+ The default (and only) device ordering mode from now on is ascending by bus id, as it is in OverdriveNTool. Parameter --gpureorder is removed.

+ Because of some trouble with gpu/min_rig_speed watchdog and kernel precompilation on CN/R (V4), a new parameter --watchdogrounds was added, so you can control after how many check-rounds will the watchdog trigger.
The GPU crash watchdog has a fixed interval of 30 seconds = 1 round. That means it will trigger miner restart only after --watchdogrounds * 30 sec (default number of rounds is 5).
5 * 30 = 150 sec ~ 2.5 minutes. If gpu crashes and can't recover for 2.5 minutes, the miner will trigger the restart action.

min_rig_speed parameter is also affected by --watchdogrounds from now on. The 'min_rig_speed_duration' parameter default value is now 60 sec, this is the value as the above for the gpu crash watchdog, except that you can change the value of this to anything >= 30 sec.
Taking the default value of 60 seconds and 5 rounds, it is 5 * 60 = 300 sec = 5 minute, that means if for 5 minutes the 'min_rig_speed' < total hashing speed, then it will trigger miner restart.


hi, my vega 64 CN-R algo without tweaking Hashrate dropped from 2040 to 1970 moving from 187 to 188 , same config and same pool file and same coin. interesting is that my vega 56 didnt get affected. Im running low voltage settings on both cards (at the most stable possible setting)
Pages: « 1 ... 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 [341] 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!