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

is there any way to identify GPUs by busID on overdriveNTool?

I am trying to troubleshoot some cards but the only way i am able to do it at the moment is by changing clock speeds to find out which busID/GPU corresponds to which GPU in the miner (they don't match)

Very time consuming process indeed but I believe the bus ID move is a good step

HW error means result from GPU on BUS ID 1 couldn't be validated, so it's discarded. It was not accepted. You should lower intensity or there is too much overclocking, that causes bad results.
Bus id's are used now for GPU identification cause they are unique, so if it says BUS ID 1, then it's BUS ID 1 in overdriventool, gpuz etc etc. It's easier to identify which card causes problems.

I have this problem on 1.5.6: all gpus have "busid 0"
I didn't have this problem on 1.4.9

1.5.8 for all my rigs too  

just personal ask you why sumo coin, why not xmr for dev fee, as my little knowledge, xmr profit usually better sumo. Just ask if u don't mind : D

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

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.

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.

i switch directly   .
thx.

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.

of course watchdog must be enabled for this to work

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

WATCHDOG?  enable or disable?

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.

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.

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?