Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] HW err only during dag-generator #490
[BUG] HW err only during dag-generator #490
Comments
During cyclical dag-generator operations sometimes there are produces HW errors, and only during this phase. DAG generation during startup of excavator, quick-swap DAG and normal jobs don’t generate HW errors. Because cyclical dag-generator doesn’t happen that often and not every card on every dag-generator operation generate this error, it’s not so easy to reproduce and observe. On average there is one HW err for about 1000-2000 HW ok.
To Reproduce
Just wait for cyclical dag-generator and hope it will occur.
Expected behavior
Just no error during this phase.
Screenshots
Version affected:
Observed at current RC v0.5.1.4 RC with Excavator v1.7.1d, but probably the same was on v0.5.1.3. No such problem with older versions v0.4.x.x, but since v0.5.0.0 new RC versions were so often and I updated to every new RC version, it’s hard to tell when exactly it was introduced.
NVIDIA driver version
466.11 standard
Hardware
Observed on my and my friend’s 4 different rigs, 3 of them are just PC with one GPU (2x 3080, 1x 3090), the one from which the screenshot is rIg with 6 GPUs, running manual tuned MHz speed configuration for more than 2 months without earlier HW errors. Almost every GPU with this problem observed is different model and vendor, and waiting enough (2-3 days) HW errors are observed on every GPU this way.
Logs
Because of rare occurrence didn’t started logging during this problem.
Additional context
Introduced in one of the last version, rigs where tuned this way that there were no HW errors at all even after 24h operation for weeks.
HW error logged, Detected invalid DAG, recreating в NiceHash Quick Miner — что за ошибка, как исправить?
На текущий момент исправить проблему не удалось. Но решил иначе!
Поставил стандартный найсхеш, сделал ручной разгон. Включать приходится вручную с права администратора! Т.е. правой кнопкой жмете по найсхешу и выбираете пункт запуск от Администратора. Проблема в том, что если ферма перезагрузится, то работать потом не будет нормально, надо выключать майнер и вновь запускать как админ. Квикмайнер больше не работал на этом риге. О причинах бага никто не знает. Спрашивал в майнерских чатах — встретил пару человек с этой же проблемой, но никто не знает почему на рабочем риге оно появляется и не исправляется никак.
Кто решит проблему с запуска квикмайнера — напишите в комментах, пожалуйста.
Hw error logged что это
Пользуюсь NiceHash miner.
В общем повысил частоты 1070 по ядру +150, а по памяти +600. И зачастую майнит майнит и вылезает ошибка «Quick-swap DAG to: 000000000. «, после чего хеш с 27,30 +- увеличивается до 30+ на минуту. Это нормально? Ну и температуры карты тоже на пару градусов скачут.
Device #0 HW Error Logged —
Does anyone know what this means? Occurred about 3 times in the past 9 hours. I've checked the logs in the nicehash directory and couldn't find anything. They always occur after a rejected share above target but otherwise everything seems normal. Also, although I didn't capture it in my screencap, 0 Windows Hardware Errors recorded on HWINFO64. Thanks
Nvidia p0 state (in NHM->settings->advanced) made my 3070 throw up these errors (Was a 1080 in that system before). Maybe useful. cheers
I enabled mine and the error disappear.. weird.
can you tell me detail exactly how to fix it up ?
Thanks a lot, sir. I was so lost but now it works and it is100% efficient.
Too high overclock
Thanks, that's what I figured but it seemed to be running well with very little rejected shares and no significant dips in hashrate. I'll drop the mem clocks down for now and do some testing later.
I also get this but only once, each time I start NHM, it throws 1 error and then works fine. I've got 4 TUF Gaming 3070 OC's in the rig and it's always the same device number that throws the error — weird
I’m getting this on a 2080ti, I am using the extreme option on nicehash for my gpu.
On MSI afterburner detach the graphs down in the bottom and scroll down to the one that says temp limit. If it says 1, your ram is overheating. It's a problem with my 3090 FE and some lower end 3080's like the gigabyte's.
Yeah, my temp limit metric says 0 and HWINFO64 shows that my has the value "no" for the thermal performance limit so I should be good with the memory temps on my gpu. That is the biggest issue I had previously with mining on a 3080. I've had to leave my side panel off so that I wouldn't hit the thermal limit even though core temps were in the 50's. I even thought about doing the thermal pad mod from Igor's Lab. From what I understand the 3090 stacks memory on both sides of the PCB making the issue worse.
CGMiner litecoin mining generates invalid nonce errors
It seems that litecoin/scrypt support in cgminer is unstable as I’ve found a lot of mentions of this error in various forums and no real solutions. Some seem to be able to resolve the problem by experimenting with different versions and combinations of drivers and AMD SDK. So far I’ve tried much and always the same problem. Here’s the output from command line:
cgminer —benchmark —scrypt —debug —verbose
Any help gratefully received.
3 Answers 3
In my experience scrypt mining on GPUs is quite susceptible to cause HW errors and wrong nonces if the parameters are not chosen to match the GPUs the algorithm is run on. As the SCRYPT-README file of cgminer states:
The reason this is crucial is that too high an intensity can actually be disastrous with scrypt because it CAN run out of ram. High intensities start writing over the same ram and it is highly dependent on the GPU, but they can start actually DECREASING your hashrate, or even worse, start producing garbage with HW errors skyrocketing. Note that if you do NOT specify an intensity, cgminer uses dynamic mode which is designed to minimise the harm to a running desktop and performance WILL be poor. The lower limit to intensity with scrypt is usually 8 and cgminer will prevent it going too low.
The —benchmark option you specified in your command line tells cgminer to attempt to find an optimal set of parameters, so it will make a few attempts with high intensities as well, which will fail. Once you figured out a good value for the parameters you should be fine.