Closed Elmojomo closed 3 years ago
Sadly I don't have a solution, but I also have an RTX2070, and I am having the same issue.
Hopefully Nicehash will take this seriously and get it addressed. In the meantime, I've switched to a different pool, so my card isn't stressed too much.
This issue is explained here: https://github.com/nicehash/NiceHashQuickMiner/wiki/Troubleshooting#when-trying-to-apply-optimize-i-get-error-not-initialized-yet
You can enable full logging and see where it gets stuck. It must be related to your ability to obtain data from GitHub.
That's interesting, since no Google searches return that page. In my case, the miner was hashing and reporting results, so I think it must have been the 2nd situation. I opened an issue (right here), but since it's now been marked "resolved" (it isn't), I'll just let it lie and continue with the other software and pool. They seem to be more interested in helping me get up and productive anyway. Thanks for the response.
This issue is explained here: https://github.com/nicehash/NiceHashQuickMiner/wiki/Troubleshooting#when-trying-to-apply-optimize-i-get-error-not-initialized-yet
You can enable full logging and see where it gets stuck. It must be related to your ability to obtain data from GitHub.
What is full logging and how do I enable it?
Right click NiceHash icon in your taskbar (right side) and then go to Help -> Full detailed logging. After you record the issue, you can do same steps and go Help -> Export logs. This will make a .zip package of log files with removed personal data out of them, ready to be attached here.
No response, closing.
@nicehashdev
Maybe I should open a new issue, but I'll see what happens piggybacking this one. I am getting this on both of my only 2 Windows NHQM rigs, both rebtech 8gpu mobos, "rebtech1" running 6 3090 GPUs (2 Founders, 1 EVGA FTW3, 1 ASUS ROG Strix, 2 Zotac Trinity), and "rebtech2" running 4 3090 Founders.
Here is my full story, in case in helps. Some of the below detail may be irrelevant, but I am including the "renaming" detail because I feel like it may be related, but can accept that it may not be at all.
The rigs were working fine for days or over a week with NHQM Optimize set to Lite or Medium. I set the optimization level to the max I can get to keep the VRAM temp below 105C. Some GPUs require Lite, some can handle Medium, none can handle High.
I jump back and forth between using the web dashboard Rig Manager and the Android app.
One day I got my wires crossed and I thought that the "rebtech1" miner needed to be renamed to "rebtech3", so I renamed it "rebtech3"; I forget if I did this on the web or Android app.
So far no problem.
Sometimes my rigs just stop mining and I start them back up.
The Android app had recently updated and I had not yet noticed the new "Rig Manager" lower control in the Android app, so to restart the rigs in the new app I toggled them Disabled and then Enabled, which appears to reset the Optimize to undefined...so, I re-set Optimize as appropriate and all is working fine again for awhile.
I then notice that it wasn't actually the NiceHash miner name that was wrong, it was the Windows machine name that was wrong.
I renamed the PC from "rebtech1" to "rebtech3" to match the NH miner name, which required a reboot.
After the reboot is when things stopped to work and I could no longer set Optimize.
I would always get "Optimize Unsuccessful" in the Android app or "Not Initialized Yet" in the web Rig Manager.
I renamed the PC back to "rebtech1" and the problem persisted.
I deleted the rig on NiceHash and had NHQM re-create a new one, and the problem persisted.
I read some of your troubleshooting guides and decided to DDU uninstall the GPU drivers and reinstall them.
After several hours of downtime of this ~700MH/s rig I gave up and physically swapped this "rebtech1" rig with an identical "rebtech2" rig beside it that was mining 4 3090s (all Founders) for days.
I attached the known working "rebtech2" to the 6 GPUs that had been previously connected to "rebtech1" and then booted the rebtech2.
It had to detect the new [to it] GPUs and after a few minutes the mining started but on this previously working rig I could now no longer set Optimize when the only thing that had changed was a GPU swap.
I again tried the DDU uninstall/reinstall and after a day of down time I was finally able to get them both to Optimize to Lite or Medium as appropriate...how I don't really know.
A few days later the 6 GPU rig stopped mining, so I started the mining back up, which reset the Optimize, and I was once again back to getting error messages when I tried to set Optimize.
I said "F it" a few times and decided to reinstall Windows from scratch.
I pulled "rebtech2" off the shelf and installed it from scratch with drivers and NHQM, deleted the rig in the dashboard, put it back on the shelf connected the 6 GPUs powered it up and...it continued to get error messages when setting Optimize.
A few more "F"s were said.
The other rig, "rebtech3" (swapped from the 6 GPUs to the 4 lame GPUs), continues to mine just fine and set Optimize on demand successfully. It is not a general network/router problem.
I then tried to run NH non-Quick Miner and after being unable to set Power Level (fixed by disabling the enabled by default "Disable Power Level") I noticed a warning that I had the DCH drivers installed and had been using them this whole time on both rigs.
Again, rebtech3 seems to be working fine, but on rebtech2 I went ahead and DDU uninstalled the DCH drivers and installed the standard non-DCH standard Game Ready drivers.
rebtech2 non-Quick Miner can set the Power Levels fine, but Quick Miner continues to be unable to set Optimize.
I don't like running non-Quick Miner, because I want to see the VRAM temps in the NH console.
Attached is a log of the still problematic rebtech2 launching and starting to mine and web console set Optimize to Lite for all GPUs and then stop mining. I glanced through the log and see some errors or warnings, but the URLs are all reachable so I don't know what requests are really failing or how https://github.com/nicehash/NiceHashQuickMiner/wiki/Troubleshooting#when-trying-to-apply-optimize-i-get-error-not-initialized-yet helps me.
{"success":false,"successType":"NOT_SUCCESSFUL","message":"com.nike.backstopper.exception.ApiException: (1): Not initialized yet"}
@nicehashdev Do you have analytics/telemetry on this "Not initialized yet" error message, and if so, how many of these are you getting?
See also #162
I never got a resolution, or really any suggestions at all, so I gave up on NHQM and switched to Ethermine. I haven't had a single issue since. Since this issue has been marked closed, you may want to start a new one so it'll be active again.
Getting data for optimization is now done from two servers, if you cannot reach one, another one is contacted. If both cannot be contacted, then it must be issue on your side - AV policy, network policy etc, so check that out. On unrestricted network with no hidden AV policies, this error never occurs.
Respectfully disagree @nicehashdev
The attached logs [above] show that it is getting the optimization data.
I have two rigs that experienced this; one currently still is and I cannot find a way to fix it. The two rigs are identical; "rebtech 8gpu" mobo; the only difference is one ("rebtech3") has 16GB of RAM and 256GB msata SSD and 6 GPUs attached, the other ("rebtech2") has 8GB RAM and 128GB msata SSD and 4 GPUs attached. (Note below that I swapped them, so now rebtech2 has 6 GPUs attached and rebtech3 has 4 GPUs attached). Both had Windows installed identically. Both have identical Windows Defender setup and no other AV. Both have identical wired network setup and policy. Both worked fine for days side by side. The first one to see the problem was "rebtech3", and only after I renamed the PC in Windows and rebooted. I swapped their physical locations (2 feet away from each other) and temporarily had both exhibiting this problem (the immediately previously working rebtech2 probably stopped working because of having to recognize the GPUs). Somehow I got both of them to work fine again, mostly through either DDU cleaning and/or a complete Windows re-install.
Then spontaneously after ~24 hours "rebtech2" stopped mining and when restarted started to see the problem again. DDU cleaning has not fixed its problem; I have not yet paved and re-installed Windows on it.
I am still unable to successfully set Optimize, so instead of giving up on NHQM I learned how to better use OCTune and am tuning them manually (which now that I know how to easily do it I almost prefer better over the presets).
Shall I open a new Issue, or can this one be re-opened and suffice?
Again, do you have analytics/telemetry on this "Not initialized yet" error message, and if so, how many of these are you getting?
From your log file:
[2021-05-04 13:54:40:360] [DEBUG] [watchdog] HTTP API GET failed: The request was aborted: The operation has timed out. [2021-05-04 13:54:40:791] [ERROR] [watchdog] Failed to establish communication channel with Excavator! [2021-05-04 13:54:41:930] [TRACE] [watchdog] No devices, cannot establish opt profiles [2021-05-04 13:54:41:932] [INFO] [watchdog] Starting/stopping with: /quickstop [2021-05-04 13:54:41:940] [TRACE] [watchdog] HTTP API GET: /quickstop [2021-05-04 13:54:41:946] [TRACE] [watchdog] HTTP API GET: /disablecpu [2021-05-04 13:54:42:955] [TRACE] [watchdog] No devices, cannot establish opt profiles [2021-05-04 13:54:43:980] [TRACE] [watchdog] No devices, cannot establish opt profiles [2021-05-04 13:54:45:011] [TRACE] [watchdog] No devices, cannot establish opt profiles [2021-05-04 13:54:45:643] [TRACE] [nhmws] Getting status data
This happens when there is another service running on port 18000 (you can simply test this by changing port to another one in config file - eg. using 18001) or some AV blocking excavator.exe. Usually it is AV blocking. You need to make sure no AV is blocking excavator.exe.
Thank you for looking at the logs! I do get that error showing up as a popup windows as shown in my images in my post a few messages back. Will look at ports next chance I get!
Maybe it is not so much an AV policy as it is a firewall policy? In my experience AVs don't usually block random ports...unless they are well known vector ports.
netstat output
C:\Windows\system32>netstat -abn
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TermService
[svchost.exe]
TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING
CDPSvc
[svchost.exe]
TCP 0.0.0.0:7680 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING
[lsass.exe]
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING
Schedule
[svchost.exe]
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING
EventLog
[svchost.exe]
TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING
SessionEnv
[svchost.exe]
TCP 0.0.0.0:49674 0.0.0.0:0 LISTENING
[spoolsv.exe]
TCP 0.0.0.0:49675 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 10.0.0.45:139 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 10.0.0.45:3389 10.0.0.3:52773 ESTABLISHED
TermService
[svchost.exe]
TCP 10.0.0.45:55354 35.186.224.25:443 TIME_WAIT
TCP 10.0.0.45:55355 104.92.255.222:80 TIME_WAIT
TCP 10.0.0.45:55382 13.107.21.200:443 TIME_WAIT
TCP 10.0.0.45:55383 13.107.21.200:443 TIME_WAIT
TCP 10.0.0.45:55388 204.79.197.222:443 TIME_WAIT
TCP 10.0.0.45:55391 13.107.42.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:55395 13.107.3.254:443 TIME_WAIT
TCP 10.0.0.45:55457 205.185.216.10:80 TIME_WAIT
TCP 10.0.0.45:55480 13.107.21.200:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:55491 13.107.3.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:55493 23.209.116.26:443 CLOSE_WAIT
[SearchApp.exe]
TCP 10.0.0.45:55494 104.73.0.57:443 CLOSE_WAIT
[SearchApp.exe]
TCP 10.0.0.45:55495 204.79.197.222:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:55503 52.137.103.96:443 ESTABLISHED
Can not obtain ownership information
TCP 10.0.0.45:56110 172.65.247.93:443 ESTABLISHED
[excavator.exe]
TCP 10.0.0.45:58690 104.17.254.46:443 ESTABLISHED
[NiceHashQuickMiner.exe]
TCP 10.0.0.45:63241 52.230.222.68:443 ESTABLISHED
WpnService
[svchost.exe]
TCP [::]:135 [::]:0 LISTENING
RpcSs
[svchost.exe]
TCP [::]:445 [::]:0 LISTENING
Can not obtain ownership information
TCP [::]:3389 [::]:0 LISTENING
TermService
[svchost.exe]
TCP [::]:7680 [::]:0 LISTENING
Can not obtain ownership information
TCP [::]:49664 [::]:0 LISTENING
[lsass.exe]
TCP [::]:49665 [::]:0 LISTENING
Can not obtain ownership information
TCP [::]:49666 [::]:0 LISTENING
Schedule
[svchost.exe]
TCP [::]:49667 [::]:0 LISTENING
EventLog
[svchost.exe]
TCP [::]:49668 [::]:0 LISTENING
SessionEnv
[svchost.exe]
TCP [::]:49674 [::]:0 LISTENING
[spoolsv.exe]
TCP [::]:49675 [::]:0 LISTENING
Can not obtain ownership information
TCP [::1]:18000 [::]:0 LISTENING
[excavator.exe]
TCP [::1]:18000 [::1]:55401 TIME_WAIT
TCP [::1]:18000 [::1]:55402 TIME_WAIT
TCP [::1]:18000 [::1]:55403 TIME_WAIT
TCP [::1]:18000 [::1]:55404 TIME_WAIT
TCP [::1]:18000 [::1]:55405 TIME_WAIT
TCP [::1]:18000 [::1]:55406 TIME_WAIT
TCP [::1]:18000 [::1]:55407 TIME_WAIT
TCP [::1]:18000 [::1]:55408 TIME_WAIT
TCP [::1]:18000 [::1]:55409 TIME_WAIT
TCP [::1]:18000 [::1]:55410 TIME_WAIT
TCP [::1]:18000 [::1]:55411 TIME_WAIT
TCP [::1]:18000 [::1]:55412 TIME_WAIT
TCP [::1]:18000 [::1]:55413 TIME_WAIT
TCP [::1]:18000 [::1]:55414 TIME_WAIT
TCP [::1]:18000 [::1]:55415 TIME_WAIT
TCP [::1]:18000 [::1]:55416 TIME_WAIT
TCP [::1]:18000 [::1]:55418 TIME_WAIT
TCP [::1]:18000 [::1]:55419 TIME_WAIT
TCP [::1]:18000 [::1]:55420 TIME_WAIT
TCP [::1]:18000 [::1]:55421 TIME_WAIT
TCP [::1]:18000 [::1]:55422 TIME_WAIT
TCP [::1]:18000 [::1]:55425 TIME_WAIT
TCP [::1]:18000 [::1]:55426 TIME_WAIT
TCP [::1]:18000 [::1]:55427 TIME_WAIT
TCP [::1]:18000 [::1]:55428 TIME_WAIT
TCP [::1]:18000 [::1]:55429 TIME_WAIT
TCP [::1]:18000 [::1]:55430 TIME_WAIT
TCP [::1]:18000 [::1]:55431 TIME_WAIT
TCP [::1]:18000 [::1]:55432 TIME_WAIT
TCP [::1]:18000 [::1]:55433 TIME_WAIT
TCP [::1]:18000 [::1]:55434 TIME_WAIT
TCP [::1]:18000 [::1]:55435 TIME_WAIT
TCP [::1]:18000 [::1]:55436 TIME_WAIT
TCP [::1]:18000 [::1]:55437 TIME_WAIT
TCP [::1]:18000 [::1]:55438 TIME_WAIT
TCP [::1]:18000 [::1]:55439 TIME_WAIT
TCP [::1]:18000 [::1]:55440 TIME_WAIT
TCP [::1]:18000 [::1]:55441 TIME_WAIT
TCP [::1]:18000 [::1]:55442 TIME_WAIT
TCP [::1]:18000 [::1]:55443 TIME_WAIT
TCP [::1]:18000 [::1]:55444 TIME_WAIT
TCP [::1]:18000 [::1]:55445 TIME_WAIT
TCP [::1]:18000 [::1]:55446 TIME_WAIT
TCP [::1]:18000 [::1]:55447 TIME_WAIT
TCP [::1]:18000 [::1]:55448 TIME_WAIT
TCP [::1]:18000 [::1]:55449 TIME_WAIT
TCP [::1]:18000 [::1]:55450 TIME_WAIT
TCP [::1]:18000 [::1]:55451 TIME_WAIT
TCP [::1]:18000 [::1]:55452 TIME_WAIT
TCP [::1]:18000 [::1]:55453 TIME_WAIT
TCP [::1]:18000 [::1]:55454 TIME_WAIT
TCP [::1]:18000 [::1]:55455 TIME_WAIT
TCP [::1]:18000 [::1]:55456 TIME_WAIT
TCP [::1]:18000 [::1]:55458 TIME_WAIT
TCP [::1]:18000 [::1]:55459 TIME_WAIT
TCP [::1]:18000 [::1]:55460 TIME_WAIT
TCP [::1]:18000 [::1]:55461 TIME_WAIT
TCP [::1]:18000 [::1]:55462 TIME_WAIT
TCP [::1]:18000 [::1]:55463 TIME_WAIT
TCP [::1]:18000 [::1]:55465 TIME_WAIT
TCP [::1]:18000 [::1]:55466 TIME_WAIT
TCP [::1]:18000 [::1]:55467 TIME_WAIT
TCP [::1]:18000 [::1]:55468 TIME_WAIT
TCP [::1]:18000 [::1]:55469 TIME_WAIT
TCP [::1]:18000 [::1]:55472 TIME_WAIT
TCP [::1]:18000 [::1]:55473 TIME_WAIT
TCP [::1]:18000 [::1]:55474 TIME_WAIT
TCP [::1]:18000 [::1]:55475 TIME_WAIT
TCP [::1]:18000 [::1]:55476 TIME_WAIT
TCP [::1]:18000 [::1]:55477 TIME_WAIT
TCP [::1]:18000 [::1]:55478 TIME_WAIT
TCP [::1]:18000 [::1]:55479 TIME_WAIT
TCP [::1]:18000 [::1]:55481 TIME_WAIT
TCP [::1]:18000 [::1]:55482 TIME_WAIT
TCP [::1]:18000 [::1]:55483 TIME_WAIT
TCP [::1]:18000 [::1]:55484 TIME_WAIT
TCP [::1]:18000 [::1]:55485 TIME_WAIT
TCP [::1]:18000 [::1]:55486 TIME_WAIT
TCP [::1]:18000 [::1]:55487 TIME_WAIT
TCP [::1]:18000 [::1]:55488 TIME_WAIT
TCP [::1]:18000 [::1]:55489 TIME_WAIT
TCP [::1]:18000 [::1]:55490 TIME_WAIT
TCP [::1]:18000 [::1]:55492 TIME_WAIT
TCP [::1]:18000 [::1]:55496 TIME_WAIT
TCP [::1]:18000 [::1]:55497 TIME_WAIT
TCP [::1]:18000 [::1]:55498 TIME_WAIT
TCP [::1]:18000 [::1]:55499 TIME_WAIT
TCP [::1]:18000 [::1]:55500 TIME_WAIT
TCP [::1]:18000 [::1]:55501 TIME_WAIT
TCP [::1]:18000 [::1]:55502 TIME_WAIT
TCP [::1]:18000 [::1]:55504 TIME_WAIT
TCP [::1]:18000 [::1]:55505 TIME_WAIT
TCP [::1]:18000 [::1]:55506 TIME_WAIT
TCP [::1]:18000 [::1]:55507 TIME_WAIT
TCP [::1]:18000 [::1]:55508 TIME_WAIT
TCP [::1]:18000 [::1]:55509 TIME_WAIT
TCP [::1]:18000 [::1]:55510 TIME_WAIT
TCP [::1]:18000 [::1]:55511 TIME_WAIT
TCP [::1]:18000 [::1]:55512 TIME_WAIT
TCP [::1]:18000 [::1]:55513 TIME_WAIT
TCP [::1]:18000 [::1]:55514 TIME_WAIT
TCP [::1]:18000 [::1]:55516 TIME_WAIT
TCP [::1]:18000 [::1]:55517 TIME_WAIT
TCP [::1]:18000 [::1]:55518 TIME_WAIT
TCP [::1]:18000 [::1]:55519 TIME_WAIT
TCP [::1]:18000 [::1]:55520 TIME_WAIT
TCP [::1]:18000 [::1]:55523 TIME_WAIT
TCP [::1]:18000 [::1]:55524 TIME_WAIT
TCP [::1]:18000 [::1]:55525 TIME_WAIT
TCP [::1]:18000 [::1]:55526 TIME_WAIT
TCP [::1]:18000 [::1]:55527 TIME_WAIT
TCP [::1]:18000 [::1]:55528 TIME_WAIT
TCP [::1]:18000 [::1]:55529 TIME_WAIT
TCP [::1]:18000 [::1]:55530 TIME_WAIT
TCP [::1]:18000 [::1]:55531 TIME_WAIT
TCP [::1]:18000 [::1]:55532 TIME_WAIT
TCP [::1]:18000 [::1]:55533 TIME_WAIT
TCP [::1]:18000 [::1]:55534 TIME_WAIT
TCP [::1]:18000 [::1]:55535 TIME_WAIT
TCP [::1]:18000 [::1]:55536 TIME_WAIT
TCP [::1]:18000 [::1]:55537 TIME_WAIT
TCP [::1]:18000 [::1]:55538 TIME_WAIT
TCP [::1]:18000 [::1]:55539 TIME_WAIT
TCP [::1]:18000 [::1]:55540 TIME_WAIT
TCP [::1]:18000 [::1]:55541 TIME_WAIT
UDP 0.0.0.0:3389 *:*
TermService
[svchost.exe]
UDP 0.0.0.0:5050 *:*
CDPSvc
[svchost.exe]
UDP 0.0.0.0:5353 *:*
Dnscache
[svchost.exe]
UDP 0.0.0.0:5355 *:*
Dnscache
[svchost.exe]
UDP 10.0.0.45:137 *:*
Can not obtain ownership information
UDP 10.0.0.45:138 *:*
Can not obtain ownership information
UDP 10.0.0.45:1900 *:*
SSDPSRV
[svchost.exe]
UDP 10.0.0.45:61298 *:*
SSDPSRV
[svchost.exe]
UDP 127.0.0.1:1900 *:*
SSDPSRV
[svchost.exe]
UDP 127.0.0.1:54545 *:*
iphlpsvc
[svchost.exe]
UDP 127.0.0.1:61299 *:*
SSDPSRV
[svchost.exe]
UDP [::]:3389 *:*
TermService
[svchost.exe]
UDP [::]:5353 *:*
Dnscache
[svchost.exe]
UDP [::]:5355 *:*
Dnscache
[svchost.exe]
UDP [::1]:1900 *:*
SSDPSRV
[svchost.exe]
UDP [::1]:61297 *:*
SSDPSRV
[svchost.exe]
UDP [fe80::8b7:7c23:2c1b:8c74%14]:1900 *:*
SSDPSRV
[svchost.exe]
UDP [fe80::8b7:7c23:2c1b:8c74%14]:61296 *:*
SSDPSRV
[svchost.exe]
That looks like a lot of ports...as in a possible leak This rig has 6 GPUs attached, so maybe that many are needed. I can reboot with only 1 GPU attached and see how it behaves.
FYI, my The attached logs [above] show that it is getting the optimization data.
comment was that the [optimizeprofiles]
debug tag showed it was getting the info from github fine.
I was seeing other unexpected behavior, but it did not appear to be with reaching external sources.
Below is on a freshly booted rig with only one GPU attached. Notably...I CAN SET OPTIMIZE!!!! 🎉
C:\Windows\system32>netstat -abn
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TermService
[svchost.exe]
TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING
CDPSvc
[svchost.exe]
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING
[lsass.exe]
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING
EventLog
[svchost.exe]
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING
Schedule
[svchost.exe]
TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING
SessionEnv
[svchost.exe]
TCP 0.0.0.0:49671 0.0.0.0:0 LISTENING
[spoolsv.exe]
TCP 0.0.0.0:49672 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 10.0.0.45:139 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 10.0.0.45:3389 10.0.0.3:52852 ESTABLISHED
TermService
[svchost.exe]
TCP 10.0.0.45:49669 152.199.24.108:443 TIME_WAIT
TCP 10.0.0.45:49670 152.199.24.108:443 TIME_WAIT
TCP 10.0.0.45:49673 104.92.255.222:80 TIME_WAIT
TCP 10.0.0.45:49674 35.186.224.25:443 TIME_WAIT
TCP 10.0.0.45:49675 40.76.203.101:443 ESTABLISHED
Can not obtain ownership information
TCP 10.0.0.45:49679 152.199.24.108:443 TIME_WAIT
TCP 10.0.0.45:49680 152.199.24.108:443 TIME_WAIT
TCP 10.0.0.45:49681 13.107.21.200:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49682 13.107.42.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49684 13.107.3.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49688 40.126.29.8:443 ESTABLISHED
[OneDrive.exe]
TCP 10.0.0.45:49690 13.107.246.70:443 ESTABLISHED
[OneDrive.exe]
TCP 10.0.0.45:49691 185.199.108.133:443 ESTABLISHED
[NiceHashQuickMiner.exe]
TCP 10.0.0.45:49692 138.91.136.108:443 TIME_WAIT
TCP 10.0.0.45:49693 104.214.150.122:443 TIME_WAIT
TCP 10.0.0.45:49699 104.92.255.222:80 ESTABLISHED
BITS
[svchost.exe]
TCP 10.0.0.45:49700 1.0.0.1:443 ESTABLISHED
[NiceHashQuickMiner.exe]
TCP 10.0.0.45:49701 104.17.254.46:443 ESTABLISHED
[NiceHashQuickMiner.exe]
TCP 10.0.0.45:49704 1.1.1.1:443 SYN_SENT
[NiceHashQuickMiner.exe]
TCP 10.0.0.45:49705 13.107.6.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49706 204.79.197.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49707 13.107.53.254:443 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49708 72.21.91.29:80 ESTABLISHED
[SearchApp.exe]
TCP 10.0.0.45:49709 204.79.197.222:443 ESTABLISHED
[SearchApp.exe]
TCP [::]:135 [::]:0 LISTENING
RpcSs
[svchost.exe]
TCP [::]:445 [::]:0 LISTENING
Can not obtain ownership information
TCP [::]:3389 [::]:0 LISTENING
TermService
[svchost.exe]
TCP [::]:49664 [::]:0 LISTENING
[lsass.exe]
TCP [::]:49665 [::]:0 LISTENING
Can not obtain ownership information
TCP [::]:49666 [::]:0 LISTENING
EventLog
[svchost.exe]
TCP [::]:49667 [::]:0 LISTENING
Schedule
[svchost.exe]
TCP [::]:49668 [::]:0 LISTENING
SessionEnv
[svchost.exe]
TCP [::]:49671 [::]:0 LISTENING
[spoolsv.exe]
TCP [::]:49672 [::]:0 LISTENING
Can not obtain ownership information
TCP [::1]:18000 [::]:0 LISTENING
[excavator.exe]
TCP [::1]:18000 [::1]:49702 TIME_WAIT
TCP [::1]:18000 [::1]:49703 TIME_WAIT
UDP 0.0.0.0:3389 *:*
TermService
[svchost.exe]
UDP 0.0.0.0:5050 *:*
CDPSvc
[svchost.exe]
UDP 0.0.0.0:5353 *:*
Dnscache
[svchost.exe]
UDP 0.0.0.0:5355 *:*
Dnscache
[svchost.exe]
UDP 10.0.0.45:137 *:*
Can not obtain ownership information
UDP 10.0.0.45:138 *:*
Can not obtain ownership information
UDP 10.0.0.45:1900 *:*
SSDPSRV
[svchost.exe]
UDP 10.0.0.45:56198 *:*
SSDPSRV
[svchost.exe]
UDP 127.0.0.1:1900 *:*
SSDPSRV
[svchost.exe]
UDP 127.0.0.1:56199 *:*
SSDPSRV
[svchost.exe]
UDP 127.0.0.1:61650 *:*
iphlpsvc
[svchost.exe]
UDP [::]:3389 *:*
TermService
[svchost.exe]
UDP [::]:5353 *:*
Dnscache
[svchost.exe]
UDP [::]:5355 *:*
Dnscache
[svchost.exe]
UDP [::1]:1900 *:*
SSDPSRV
[svchost.exe]
UDP [::1]:56197 *:*
SSDPSRV
[svchost.exe]
UDP [fe80::8b7:7c23:2c1b:8c74%14]:546 *:*
Dhcp
[svchost.exe]
UDP [fe80::8b7:7c23:2c1b:8c74%14]:1900 *:*
SSDPSRV
[svchost.exe]
UDP [fe80::8b7:7c23:2c1b:8c74%14]:56196 *:*
SSDPSRV
[svchost.exe]
Note that I did NOT confirm before I rebooted with only 1 GPU that setting Optimize was still not succeeding. I have seen it before where it is always possible that something started to work by letting it sit for awhile. I will now test with reconnecting all 6 GPUs...
All 6 GPUs are now able to set Optimize. Again note that I unfortunately did not confirm immediately prior to this test that set was still NOT able to successfully set Optimize.
All I did was: 1) power off and unplug 5 of 6 GPUs and power back on and start mining and was able to set Optimize on the one attached GPU 2) power off and plug all 6 GPUs back in and power back on and start mining and was able to set Optimize on all 6 GPUs.
Video: https://youtu.be/wQ6BLO6IvSY
As mentioned in the video, if/when I see this happen again I will better video/document the issue and update this Issue #256 and maybe we can nail it down for good.
I highly recommend you have analytics/telemetry on the error messages going through any server in the path to see how many other users may be getting this (admittedly probably not a ton, but I am skeptical that it would be less than a few).
If unplugging/plugging GPUs solved your issue, then this is a NVIDIA driver/hardware/PCIe link issue. Set your PCIe gen in BIOS to 2 for max stability and apply MSI.
@nicehashdev Respectfully, the rig that was unable to set an Optimize level had no problem otherwise mining or setting OC levels using OCTune. I am skeptical that it was only a NVIDIA driver/hardware/PCIe link issue and not at all an issue with any NiceHash SaaS.
The only thing that appeared to not be working was setting the Optimize level and whatever communication (request/response) transpires when a NiceHash client (web or Android) requests to do so.
You said in https://github.com/nicehash/NiceHashQuickMiner/issues/256#issuecomment-832477716
On unrestricted network with no hidden AV policies, this error never occurs.
Then when it started working you said it must be the "NVIDIA driver/hardware/PCIe link", contradicting your above statement.
The problem either fixed itself by just letting it sit for awhile (admittedly I did not check if it was still giving an error immediately prior to my latest troubleshooting), or I got it working by powering off the rig and unplugging 5 of 6 GPU PCIE USB cables and powering back on with only 1 GPU. That 1 GPU was untouched, and there is little reason Windows would reinitialize drivers for a GPU that it does not see has changed between reboots. Things continued to work after adding back the 5 other GPUs.
Just three days earlier I created the issue by doing [almost] the exact same thing that I did to fix the problem: powering off a known working rig, unplugging [4] GPUs connected to it, plugging in [6 new to it] GPUs, and powering it back on.
Changing a rig's connected GPUs can cause the problem. Changing a rig's connected GPUs can fix the problem.
Understood that Windows needs to initialize any "new to it" GPUs, but once initialized and showing no problems with drivers and being rebooted several times I would expect set Optimize to succeed; it was not.
AV, network, NVIDIA driver/hardware/PCIe link etc may all contribute, but considering mining and manual OC were working fine on the rig that could only just not set Optimize, the evidence does not eliminate the NiceHash [web/mobile] Client->Excavator path from being part of the problem.
My rigs are all working again, so I am moving on from this issue for now. If I see the problem again I will better log/document/video it.
Thank you for your time and help.
@nicehashdev As I mentioned on Discord earlier today, https://discord.com/channels/384819546642710553/802081909681291284/879449250465976400, I seem to have worked around my problem by increasing watchDogAPITimeout
; I changed it from the original of 2000 to 5000 and seem to no longer be running in to this issue.
As a workaround for this and #326 I am now using Windows Task Scheduler to run the following command as administrator every 3 hours:
powershell -Command Stop-Process -PassThru -Name excavator
I have a single RTX2070 up an running, but when I try to apply the [optimize] button, either Lite or Medium, I get the error shown in the attached screenshot.