Bitcoin Forum
May 21, 2022, 02:52:22 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 [121] 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 ... 365 »
  Print  
Author Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching  (Read 235834 times)
doktor83
Hero Member
*****
Offline Offline

Activity: 1974
Merit: 621


View Profile WWW
June 02, 2018, 05:41:28 PM
 #2401

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.

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
1653101542
Hero Member
*
Offline Offline

Posts: 1653101542

View Profile Personal Message (Offline)

Ignore
1653101542
Reply with quote  #2

1653101542
Report to moderator
1653101542
Hero Member
*
Offline Offline

Posts: 1653101542

View Profile Personal Message (Offline)

Ignore
1653101542
Reply with quote  #2

1653101542
Report to moderator
1653101542
Hero Member
*
Offline Offline

Posts: 1653101542

View Profile Personal Message (Offline)

Ignore
1653101542
Reply with quote  #2

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

Posts: 1653101542

View Profile Personal Message (Offline)

Ignore
1653101542
Reply with quote  #2

1653101542
Report to moderator
1653101542
Hero Member
*
Offline Offline

Posts: 1653101542

View Profile Personal Message (Offline)

Ignore
1653101542
Reply with quote  #2

1653101542
Report to moderator
heavyarms1912
Full Member
***
Offline Offline

Activity: 771
Merit: 114



View Profile
June 02, 2018, 05:47:05 PM
 #2402

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.

Switching now.  Can i just replace the .exe file in the miner directory?
doktor83
Hero Member
*****
Offline Offline

Activity: 1974
Merit: 621


View Profile WWW
June 02, 2018, 06:02:47 PM
 #2403

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.

Switching now.  Can i just replace the .exe file in the miner directory?

thank you, yes its enough if you were using one of the newer versions > 1.4.0

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
MaxMidnite
Newbie
*
Offline Offline

Activity: 137
Merit: 0


View Profile
June 02, 2018, 06:10:58 PM
 #2404

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.

The results did not change between kernels maybe little hash change 1-5hash.
Another question if I set,

/* Intensity 0-> auto intensity, or value from 1-300  */
"intensity" : 0,

The confusion is does it take the intensity auto or the gpu_conf values??
doktor83
Hero Member
*****
Offline Offline

Activity: 1974
Merit: 621


View Profile WWW
June 02, 2018, 06:19:20 PM
 #2405

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.

The results did not change between kernels maybe little hash change 1-5hash.
Another question if I set,

/* Intensity 0-> auto intensity, or value from 1-300  */
"intensity" : 0,

The confusion is does it take the intensity auto or the gpu_conf values??

If you set intensity in gpu_conf, the setting on top of the config will get disabled, so the one from gpu_conf will be used.

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
heavyarms1912
Full Member
***
Offline Offline

Activity: 771
Merit: 114



View Profile
June 02, 2018, 07:06:08 PM
 #2406

thank you, yes its enough if you were using one of the newer versions > 1.4.0
Yup I was on 1.5.x earlier.
Iamtutut
Full Member
***
Offline Offline

Activity: 1106
Merit: 130


View Profile
June 02, 2018, 07:30:13 PM
 #2407



+ I would like to politely ask everyone if they appreciate my work, to switch their miners to this new version.



Done.
PIOUPIOU99
Copper Member
Member
**
Offline Offline

Activity: 293
Merit: 11


View Profile
June 02, 2018, 07:39:59 PM
 #2408

i switch directly   .
thx.
UnclWish
Sr. Member
****
Offline Offline

Activity: 1470
Merit: 253


View Profile
June 02, 2018, 07:43:02 PM
 #2409

Version 1.5.6. Windows 1803 with 18.5.2 (18.5.1 same thing). Miner didn't release all video memory on closing miner. I use GPU-Z to see vmemory usage. On each RX 580 card after closing miner still exists used vmemory. And with every launch free amount of vmemory decreases. I don't know how, but after many-many launches, during mining GPU-Z shows 15-16Gb of used video memory on each card. But they have only 8Gb of it...
Pagefile usage grows with that too...

Thats definitely something wrong with SRB miner on last Windows version with last AMD drivers...
And still miner detects RX 580 cards as R9 200 series. I have 3rd connected card - R9 270X. Maybe thats the cause of wrong detection of 580?
livada
Newbie
*
Offline Offline

Activity: 416
Merit: 0


View Profile WWW
June 02, 2018, 08:13:48 PM
 #2410

V1.5.8
- Fixed a bug in pool switching process
- Fixed a bug in watchdog's "reboot_script"

ADD  biger  HR Smiley

i test this: and this versio¸n  give 1,7% more HR for identical  setup adn identical power use.

1.53 vs 1.5.8 SRBminer
Vega 56/64bios -samsung mem

https://image.prntscr.com/image/LZ9-vXiESPiEgd4O9THbDg.jpg
https://image.prntscr.com/image/i4P8BLN5Sc_0va2jRPU06g.jpg

Vega 56 nitro+ /64bios -hynix mem
https://image.prntscr.com/image/xQUEF6YFTPmYWDEiQVQTkQ.jpg
https://image.prntscr.com/image/0_aGo4CGSdewHMGUlvRvnQ.jpg

GOOD JOB DOC
ALEX_RAA
Newbie
*
Offline Offline

Activity: 78
Merit: 0


View Profile
June 02, 2018, 08:15:05 PM
 #2411

v. 1.5.6 still have problem - if some gpus stop hashing the miner not hangs but just stoped and not showing any information further. So if i see that and press  some key (space or h for example) it will show that gpu's hash speed is 0 and make reconnect to pool and after it will work good for some time.

sorry but i dont understand,can you turn on logging and share that?

https://thumb.ibb.co/gwXGTJ/Screenshot_at_02_17_06_45.png

so marked area is when i see that one of rigs do no sending shares more than 2 minutes. Miner just not doing anything after returning to
 user mining and than i have to press H or S and see hash speed is 0
it's v 1.5.6

p.s. i have to admit that in v 1.5.6 this situations happens not often

how is that time is jumping :

16:56:39
17:03:33
16:57:40
16:57:17

after that is all good.

Have you turned on logging as i asked?

i forgot... now i turned it on
doktor83
Hero Member
*****
Offline Offline

Activity: 1974
Merit: 621


View Profile WWW
June 02, 2018, 08:35:46 PM
 #2412

V1.5.8
- Fixed a bug in pool switching process
- Fixed a bug in watchdog's "reboot_script"

ADD  biger  HR Smiley

i test this: and this versio¸n  give 1,7% more HR for identical  setup adn identical power use.

1.53 vs 1.5.8 SRBminer
Vega 56/64bios -samsung mem




Vega 56 nitro+ /64bios -hynix mem



GOOD JOB DOC


That is nice, i only changed a few unrolls in cl in previous version that boosted my 580 8g only about 0.2-0.3%, looks like vegas like that even more  Smiley

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
rambetiko
Member
**
Offline Offline

Activity: 184
Merit: 10


View Profile
June 02, 2018, 09:18:44 PM
Last edit: June 02, 2018, 09:46:58 PM by rambetiko
 #2413

V1.5.8
- Fixed a bug in pool switching process
- Fixed a bug in watchdog's "reboot_script"

ADD  biger  HR Smiley

i test this: and this versio¸n  give 1,7% more HR for identical  setup adn identical power use.

1.53 vs 1.5.8 SRBminer
Vega 56/64bios -samsung mem




Vega 56 nitro+ /64bios -hynix mem



GOOD JOB DOC


hello. what is your vega setup? i have 2 x vega 64 with samsung mem but my hash low- (1360-1410 h/s)
i use hellm register mod. 200w power down.
http://www.overclock.net/forum/67-amd-ati/1633446-preliminary-view-amd-vega-bios-26.html#post_26297003

vega 64 setup
p7 1430 - 1000mv
mem p3 1080 - 950mv

{ "id" : 3, "intensity" : 58, "worksize" : 8, "threads" : 2},
RuMiner
Member
**
Offline Offline

Activity: 168
Merit: 15


View Profile
June 02, 2018, 11:09:20 PM
Last edit: June 02, 2018, 11:33:36 PM by RuMiner
 #2414

@doktor83 you could program devfee like Claymore did in his miners: he uses the same pool and coin as user set in config file, just changes a wallet for a while. At first user cannot cheat with devfee just banning your pool. Also there's no need to reload data to GPUs while changing pool and/or coin for devfee, so it should switch faster.

PS CNv7 became several hashes faster on Vegas with 1.5.8. Thanks for that Smiley
sidaliroy
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
June 03, 2018, 12:40:07 AM
 #2415

Can you make the miner's API compatible with Claymore Remote Manager (Ethman)?
ALEX_RAA
Newbie
*
Offline Offline

Activity: 78
Merit: 0


View Profile
June 03, 2018, 12:42:57 AM
 #2416

v. 1.5.6 still have problem - if some gpus stop hashing the miner not hangs but just stoped and not showing any information further. So if i see that and press  some key (space or h for example) it will show that gpu's hash speed is 0 and make reconnect to pool and after it will work good for some time.

sorry but i dont understand,can you turn on logging and share that?

https://thumb.ibb.co/gwXGTJ/Screenshot_at_02_17_06_45.png

so marked area is when i see that one of rigs do no sending shares more than 2 minutes. Miner just not doing anything after returning to
 user mining and than i have to press H or S and see hash speed is 0
it's v 1.5.6

p.s. i have to admit that in v 1.5.6 this situations happens not often

how is that time is jumping :

16:56:39
17:03:33
16:57:40
16:57:17

after that is all good.

Have you turned on logging as i asked?

finally i have got logs:

https://thumb.ibb.co/eTtANd/Screenshot_at_03_03_31_24.png
https://thumb.ibb.co/mu0qNd/Screenshot_at_03_03_32_40.png

LOGS - http://www.filedropper.com/log_9
 
hesido
Jr. Member
*
Offline Offline

Activity: 157
Merit: 5


View Profile
June 03, 2018, 01:12:10 AM
Last edit: June 03, 2018, 01:27:48 AM by hesido
 #2417

@doktor83 you could program devfee like Claymore did in his miners: he uses the same pool and coin as user set in config file, just changes a wallet for a while. At first user cannot cheat with devfee just banning your pool. Also there's no need to reload data to GPUs while changing pool and/or coin for devfee, so it should switch faster.

PS CNv7 became several hashes faster on Vegas with 1.5.8. Thanks for that Smiley

Your proposal seems good. This is immune to any changes as the user will select the correct algo, however, for any given algo, the program must detect type of mined coin so it can provide the correct wallet address.

Btw, I lost stability. it crashed while I was firing up GPU-Z. I really don't have the time to dig this one up. Will see if the crash is related to GPU-Z fire up. Or maybe the faster setting began to push a GPU over the edge but the logs are not good enough to see what GPU stalled. Claymore logs revealed the GPU that hung pretty well even before a violent crash.

Edit: Brief look, system seems to work ok if I don't fire up GPU-Z, (working for 10 mins) but I lose a total of 800-1000 mH/s unfortunately, on 13 cards. Some run full speed and some run 100 mh/s slower.
livada
Newbie
*
Offline Offline

Activity: 416
Merit: 0


View Profile WWW
June 03, 2018, 07:03:50 AM
Last edit: June 03, 2018, 08:58:22 AM by livada
 #2418

@doktor83 you could program devfee like Claymore did in his miners: he uses the same pool and coin as user set in config file, just changes a wallet for a while. At first user cannot cheat with devfee just banning your pool. Also there's no need to reload data to GPUs while changing pool and/or coin for devfee, so it should switch faster.

PS CNv7 became several hashes faster on Vegas with 1.5.8. Thanks for that Smiley
good solution.

Tonight miner block after devfee.. Computer work  but miner not. This is SS in 9:00 AM

https://image.prntscr.com/image/PLv-MTFATcK75lt_0_1E3g.jpg

ovo gore je super ideja jer eto nakon dizanja gpu-a je miner zapeo na toj prvoj kartici i to je bilo to. sat i pol nije radio samo je trosio struju. Sad

i neznam sto je ovo jer toga prije niakd nije bilo i samo mi puni smecem komp:

https://image.prntscr.com/image/JaPFaoMLRkKfAi7L0_uWrw.jpg
doktor83
Hero Member
*****
Offline Offline

Activity: 1974
Merit: 621


View Profile WWW
June 03, 2018, 08:58:41 AM
 #2419

v. 1.5.6 still have problem - if some gpus stop hashing the miner not hangs but just stoped and not showing any information further. So if i see that and press  some key (space or h for example) it will show that gpu's hash speed is 0 and make reconnect to pool and after it will work good for some time.

sorry but i dont understand,can you turn on logging and share that?



so marked area is when i see that one of rigs do no sending shares more than 2 minutes. Miner just not doing anything after returning to
 user mining and than i have to press H or S and see hash speed is 0
it's v 1.5.6

p.s. i have to admit that in v 1.5.6 this situations happens not often

how is that time is jumping :

16:56:39
17:03:33
16:57:40
16:57:17

after that is all good.

Have you turned on logging as i asked?

finally i have got logs:




LOGS - http://www.filedropper.com/log_9
 

From the logs i can see that this isn't probably related to devfee-user pool switching, because after the devfee finished, you got jobs and accepted results from your pool, so the switchback was successful.

[2018-06-03 03:09:20] switch_pool: Disconnected from devfee pool, now mining for user
[2018-06-03 03:10:26] hashrate: GPU0: 964 H/S [BUS:5]
[2018-06-03 03:10:26] hashrate: GPU1: 1013 H/S [BUS:6]
[2018-06-03 03:10:26] hashrate: GPU2: 1017 H/S [BUS:2]
[2018-06-03 03:10:26] hashrate: GPU3: 964 H/S [BUS:4]
[2018-06-03 03:10:26] hashrate: GPU4: 952 H/S [BUS:1]
[2018-06-03 03:10:26] hashrate: Total: 4910 H/S
[2018-06-03 03:10:59] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"010193e4ccd805375fd1190a992e2b57929b47ae079a998a31bc7e1c11111a5a43e932b87519c20 0000000e510944a66dda1a13a8c31101b4cd678c25c109320e76a7936b82ff0fc10938201","job_id":"436392239714041","target":"d96f0000"}}
[2018-06-03 03:10:59] pool_have_job: Pool sent a new job (ID: 436392239714041)
[2018-06-03 03:11:09] miner_result: Sending user result to pool
[2018-06-03 03:11:09] json_send: {"method":"submit","params":{"id":"316536043444648","job_id":"436392239714041","nonce":"964033b3","result":"23e46068b4c15131a3d638b862f4988b4f810f82aa7b46a2d4cf0a91360b0000"},"id":1}
[2018-06-03 03:11:09] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[2018-06-03 03:11:09] miner_result: Pool accepted result 0x00000B36


also there are new jobs/accepted shares after this before the fun begins :

[2018-06-03 03:31:29] json_receive: {"id":1,"jsonrpc":"2.0","error":{"code":-1,"message":"Unauthenticated"}}
[2018-06-03 03:31:29] miner_result: You are not authenticated to the pool
[2018-06-03 03:31:29] miner_result: Pool rejected result 0x00003690 (unauthenticated)
[2018-06-03 03:31:29] miner_result: Network error
[2018-06-03 03:31:29] miner_result: Network error

The 0 hashing speed in this case is normal, because the GPU's are not working on any job.
This looks like some kind of pool problem to me.

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

Activity: 1974
Merit: 621


View Profile WWW
June 03, 2018, 09:18:23 AM
 #2420

@doktor83 you could program devfee like Claymore did in his miners: he uses the same pool and coin as user set in config file, just changes a wallet for a while. At first user cannot cheat with devfee just banning your pool. Also there's no need to reload data to GPUs while changing pool and/or coin for devfee, so it should switch faster.

PS CNv7 became several hashes faster on Vegas with 1.5.8. Thanks for that Smiley
good solution.

Tonight miner block after devfee.. Computer work  but miner not. This is SS in 9:00 AM



ovo gore je super ideja jer eto nakon dizanja gpu-a je miner zapeo na toj prvoj kartici i to je bilo to. sat i pol nije radio samo je trosio struju. Sad

i neznam sto je ovo jer toga prije niakd nije bilo i samo mi puni smecem komp:



Version of miner?

From 1.5.5.1 there is a job_timeout parameter set to default of 15 minutes.
When no new job is received for 15 minutes it reconnects to your pool.

On your screenshot miner is not stuck AFTER the devfee, but BEFORE, there was a big pause before the devfee, which to admit looks interesting because miner did not freeze.
Logs of this would be interesting to see.

Also those file are not garbage, they are cached files, meant to speed up the compile process.

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
Pages: « 1 ... 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 [121] 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 ... 365 »
  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!