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

[sidaliroy]

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

[ALEX_RAA]

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]

@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

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]

@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

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.

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]

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.

[doktor83]

@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

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.

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.

[doktor83]

@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

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.

Other miners have their own pools, where they do the devfee mining, but it would be too much to maintain those pools + work on the miner + work my 8-16h time job.
I have an idea how will i manage this without making own pools.

Regarding the stability thing, are you sure its related only to 1.5.8 ? There really isn't anything 'new' in that version that could cause GPU-Z crashing.

If some of you have older versions working better than the latest, i willl re-compile them all with the new devfee pool for heavy, and re-upload to mega.

Thanks for your support guys 

[livada]

@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

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.

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.

version is last SRBMiner-CN-V1-5-8

watchdog disabled.

mine rwork 10 hour before this
work in 06:13:26
and not see any work 1 hour ? hmmm
no bad shaer not any stats 1 hour
and in 07:25 miner go conect on devpool. hmmmmm
work and go back to mine and dont again any stats 1,5 hour.

if pool not work miner must say  any?

FILE .srb. I have -srb 30 file in srbminer directori and this is not good. i dotn wont see this in my work directory. last version have 1 file now i see 30 .srb file.  in this folder i have 30.bat file. 50 .config filer . 50 pool file. and all .srb file is GARBAGE for me in this folder

[RuMiner]

@livada please don't overquote too much, it's hard to read...
I have two rigs: 8xVega64 and 4xVega56, both dig CNv7 with weeks of stable uptime. I interrupt it only for miner updates. I guess running GPU-Z makes problems, not the miner itself.

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

I've made it recently
https://bitcointalk.org/index.php?topic=4324950
Somebody please report if you like it. It will not format your drive, I promise )

[livada]

@livada please don't overquote too much, it's hard to read...
I have two rigs: 8xVega64 and 4xVega56, both dig CNv7 with weeks of stable uptime. I interrupt it only for miner updates. I guess running GPU-Z makes problems, not the miner itself.

np.

my 6*vega56 nitro+ GPUz not work with any version srbminer(i not try with cast or xmrstack). i try HWinfo but not work with srbminer. when i start  gpuz+miner = BLOCK.

gpuz and hwinfo work fine solo.

3*vega56 powercolor gpuz work finwe with all version srbminer

[doktor83]

@livada please don't overquote too much, it's hard to read...
I have two rigs: 8xVega64 and 4xVega56, both dig CNv7 with weeks of stable uptime. I interrupt it only for miner updates. I guess running GPU-Z makes problems, not the miner itself.

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

I've made it recently
https://bitcointalk.org/index.php?topic=4324950
Somebody please report if you like it. It will not format your drive, I promise )

Added a link in TIPS section on first page

Thanks for the tool 

[livada]

disable watcdog not good for me.

now i wont use reset computer if gpu hash down to 0 but i not understud this
"reboot_script" : FILENAME, TURN OFF BUILT IN WATCHDOG AND INSTEAD RUN A USER DEFINED .BAT FILE ON GPU FAILURE (included windows restart .bat)

how log whatcdog wait for restart? 1sec? if gpu have 0HR  1 sec script activated and reset comp?. i wont this. if GPU have 0HR  3min comp go restart.

this is posible?

"reboot_script" : "reboot-windows.bat", - this is yours reboot.bat - but how log GPU must have 0HR before restart?

with this reboot.bat i must disable or enable wachdog?

[doktor83]

disable watcdog not good for me.

now i wont use reset computer if gpu hash down to 0 but i not understud this
"reboot_script" : FILENAME, TURN OFF BUILT IN WATCHDOG AND INSTEAD RUN A USER DEFINED .BAT FILE ON GPU FAILURE (included windows restart .bat)

how log whatcdog wait for restart? 1sec? if gpu have 0HR  1 sec script activated and reset comp?. i wont this. if GPU have 0HR  3min comp go restart.

this is posible?

yup, this is how it works.

Watchdog instead of trying to restart your miner after 3x45 sec of 0 hashing, runs the script you define, where you can kill the process, reboot windows, practically do anything you want in your script.

config.txt :

"reboot_script" : "reboot-windows.bat"

PS: pisem na engleskom sve zbog ostalih da bi i oni znali o cemu se radi i da ako neko naidje sa istim problemom da zna kako da resi.

[livada]

disable watcdog not good for me.

now i wont use reset computer if gpu hash down to 0 but i not understud this
"reboot_script" : FILENAME, TURN OFF BUILT IN WATCHDOG AND INSTEAD RUN A USER DEFINED .BAT FILE ON GPU FAILURE (included windows restart .bat)

how log whatcdog wait for restart? 1sec? if gpu have 0HR  1 sec script activated and reset comp?. i wont this. if GPU have 0HR  3min comp go restart.

this is posible?

yup, this is how it works.

Watchdog instead of trying to restart your miner after 3x45 sec of 0 hashing, runs the script you define, where you can kill the process, reboot windows, practically do anything you want in your script.

config.txt :

"reboot_script" : "reboot-windows.bat"

PS: pisem na engleskom sve zbog ostalih da bi i oni znali o cemu se radi i da ako neko naidje sa istim problemom da zna kako da resi.

ok.
"reboot_script" : "reboot-windows.bat" only this and computer go restart  if GPU have 0HR 135sec?

WATCHDOG?  enable or disable?

[MaxMidnite]

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.

I understand this I set Intensity to 0 but changing the kernal will it work or need to mnaually set intensity on gpu_conf for the kernal results to work..

[doktor83]

disable watcdog not good for me.

now i wont use reset computer if gpu hash down to 0 but i not understud this
"reboot_script" : FILENAME, TURN OFF BUILT IN WATCHDOG AND INSTEAD RUN A USER DEFINED .BAT FILE ON GPU FAILURE (included windows restart .bat)

how log whatcdog wait for restart? 1sec? if gpu have 0HR  1 sec script activated and reset comp?. i wont this. if GPU have 0HR  3min comp go restart.

this is posible?

yup, this is how it works.

Watchdog instead of trying to restart your miner after 3x45 sec of 0 hashing, runs the script you define, where you can kill the process, reboot windows, practically do anything you want in your script.

config.txt :

"reboot_script" : "reboot-windows.bat"

PS: pisem na engleskom sve zbog ostalih da bi i oni znali o cemu se radi i da ako neko naidje sa istim problemom da zna kako da resi.

ok.
"reboot_script" : "reboot-windows.bat" only this and computer go restart  if GPU have 0HR 135sec?

WATCHDOG?  enable or disable?

of course watchdog must be enabled for this to work

[livada]

of course watchdog must be enabled for this to work

Ok. This is it.

Now try chg .srb file. Every start miner open 1.srb file. This is not good. i open srbminer -50* in day. and after 30 day i have 1500 .srb file?

last version have only 1 file for work and not opet new.

[trifo]

Suggestion for future if it does not require hard work... What do you think about the idea to move all files dll and exe to separated dir or make one just for .srb files, just live start, pools and config out. Will be less mess in dir... Maybe dir just for .srb files would be enough.

[bulgar73]

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.

all of my 14 rigs updated to 1.5.8

big thanks @doctor83 for your work

----
BTC

[Wargika]

i switch directly   .
thx.

I also switched.