Potentially related issue:
#313
I attempted to allocate additional threads for OpenCL mining XMR, crashed my GPU driver by running out of VRAM.
After the driver recovered however, Task Manager expectedly showed 0% on compute, but XMRig kept on going as if nothing happened, and started reporting completely incorrect junk hashrate values in the 220+KH/s range, another time it showed hashrates that would've had me dominating ~20% of Hashvaults entire pool with just one GPU running RandomX!
The junk hashrates seem inconsistent, likely influenced by whatever was using VRAM at the same time the driver panicked.
Hashvault didn't actually register these junk values, and only showed my expected CPU hashrate, a single RX6800 running RandomX definitely can't out-mine an antminer X5...
When attempting to update config.json after this happened, XMRig correctly spewed OOM errors for the OpenCL threads, and I needed to restart it with the correct thread count to start mining again.
My uneducated guess is OOB access/some integer overflow/something that XMRig doesn't catch when the AMD driver panics, and only catches it when a config update is hot-loaded to throw the OOM error.
Left it running overnight with the bogus hashrates and it does seem like a visual bug, but I'm not sure if Hashvault simply has some mechanism to ignore this and something nastier could come from it.
Potentially related issue:
#313
I attempted to allocate additional threads for OpenCL mining XMR, crashed my GPU driver by running out of VRAM.
After the driver recovered however, Task Manager expectedly showed 0% on compute, but XMRig kept on going as if nothing happened, and started reporting completely incorrect junk hashrate values in the 220+KH/s range, another time it showed hashrates that would've had me dominating ~20% of Hashvaults entire pool with just one GPU running RandomX!
The junk hashrates seem inconsistent, likely influenced by whatever was using VRAM at the same time the driver panicked.
Hashvault didn't actually register these junk values, and only showed my expected CPU hashrate, a single RX6800 running RandomX definitely can't out-mine an antminer X5...
When attempting to update config.json after this happened, XMRig correctly spewed OOM errors for the OpenCL threads, and I needed to restart it with the correct thread count to start mining again.
My uneducated guess is OOB access/some integer overflow/something that XMRig doesn't catch when the AMD driver panics, and only catches it when a config update is hot-loaded to throw the OOM error.
Left it running overnight with the bogus hashrates and it does seem like a visual bug, but I'm not sure if Hashvault simply has some mechanism to ignore this and something nastier could come from it.