Thanks 
Interresting, so it may come from my netcode. A possible explaination could be the devfee session that may get a different diff as the user pool. But the devfee sessions are Claymore-style: small randomized sessions that don't disconnect your own pool, so you may encounter a few shares with a different diff from time to time (0.9% of time average) but not a permanent change.
Also strange is that i got this problem reported on CN-Heavy coins, while of course my netcode is the same whatever the coin is (only Nicehash has dedicated netcode).
This is not a big threat since all diff are equivalent in term of efficiency, but that's still a bug. Also check pool side the shares you get are the same as the effective hashrate reported by the yellow report, within a ~2% tolerance, and after a few hours of mining. If you observe a huge result difference, so it could be a critical bug.
The monitoring is to circumvent the lack of Watchdog in Stak, and the reset/restart is the pupose of a watchdog too.
So my answer is that once JCE watchdog is released, this script won't be needed, a simple .bat would do the job:
(pseudo-bat and dummy values)
Quote
Weird part is that when using fixed diff like 25k with jce-miner, diff changes after some time but same 25k with xmr-stak, diff stays fixed...
Interresting, so it may come from my netcode. A possible explaination could be the devfee session that may get a different diff as the user pool. But the devfee sessions are Claymore-style: small randomized sessions that don't disconnect your own pool, so you may encounter a few shares with a different diff from time to time (0.9% of time average) but not a permanent change.
Also strange is that i got this problem reported on CN-Heavy coins, while of course my netcode is the same whatever the coin is (only Nicehash has dedicated netcode).
This is not a big threat since all diff are equivalent in term of efficiency, but that's still a bug. Also check pool side the shares you get are the same as the effective hashrate reported by the yellow report, within a ~2% tolerance, and after a few hours of mining. If you observe a huge result difference, so it could be a critical bug.
Quote
Can you make jce gpu miner compatible for this
I quick read the code, and the purpose is to monitor the hashrate and restart the vega drivers and the miner when they drop.The monitoring is to circumvent the lack of Watchdog in Stak, and the reset/restart is the pupose of a watchdog too.
So my answer is that once JCE watchdog is released, this script won't be needed, a simple .bat would do the job:
(pseudo-bat and dummy values)
Code:
:Reset
# reset GPU
OverdriveNTool.exe ....
# Run JCE with watchdog with minimum hashrate of 500 h/s
jce_cn_gpu_miner64.exe .... --watchdog=500
if ERRORLEVEL 1 goto Reset # if quit with error reset whole procedure, otherwise, just end
# reset GPU
OverdriveNTool.exe ....
# Run JCE with watchdog with minimum hashrate of 500 h/s
jce_cn_gpu_miner64.exe .... --watchdog=500
if ERRORLEVEL 1 goto Reset # if quit with error reset whole procedure, otherwise, just end
Quote
What is vega bug? Never had issues with vegas and jce miner
My wording was bad, that was a OpenCL generation bug caused by the Vega detection routine. It appeared in 0.32i and was immediately fixed thanks to the report of samvicky. 0.32i has been removed and replaced by 0.32j