Quote from: patrike on November 06, 2020, 01:23:20 PM

Quote from: danielocdh on November 05, 2020, 03:13:27 PM

Quote from: patrike on November 04, 2020, 03:35:34 PM

Quote from: danielocdh on November 04, 2020, 02:17:01 AM

ethminer API timing out, but only on remote agent connections

I have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection):

Code:

2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}

Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners.

I tried setting the priority of the remote agent process to high, I don't think it made a difference.

This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu.

Any suggestion on what else I could try? thanks

Thanks for the detailed description and for your analysis. So at the same time Remote Agent get a timeout after 13 seconds, your tool connecting to the same EthMiner API is receiving a response without any problems? Do you see a timeout error like this and then it works fine for a while and then another timeout and so on?

I will have to look into this a bit more because I cannot see any obvious reason why Remote Agent would timeout if the API is in fact working.

For the API data processing, I can make a few adjustments to make sure it parses the API response correctly once received.

Correct, my tool never failed to get the API data quickly, I'm using the same command I saw on the logs(miner_getstatdetail)

Update: I installed the latest updates for windows 1909 on windows update(security, servicing stack, cumulative and a .net 3.5 update but not edge), after about 10 hours the timeouts seem to be less common, one machine had 0, other 12 and other 16(6 consecutive timeouts once which triggered the offline detection that is set to 60 seconds now). The API was fully responsive all the time on all miners when requesting information from my computer with my tool (every 5 seconds never taking more than a few milliseconds).
I'll reformat one miner with latest windows to test when I can.

Thanks for the update.

If you look at the Windows Defender advanced settings, where all applications are listed - are there any difference between Awesome Miner and your tool? For example the Profile (Private, Public)?

I did the tests with firewall disabled but I normally have it set to not notify and not block all, so there are no extra rules. I only have the inbound rule for AwesomeMinerService (9630) which is private(as my network type). My tool (made in PHP and run locally via cli) doesn't listen on any port.

The updated 8.1.6 made awesome miner show more info for 0.17.1 but shows nothing for 0.19 (ethminer-0.19.0-7+commit.66186f1b). It seems those 2 versions APIs have different fields in the response. I haven't had any timeouts with 8.1.6 and 0.17.1 in a while so I'll just use that for now, thanks.