Helium Mining

Milesight UG65 Helium Miner DHCPDISCOVER dhclient errors high load average

If you have a Milesight UG65 that is getting the following error messages:

Mon Feb 28 11:17:17 2022 daemon.info dhclient: No working leases in persistent database - sleeping.
Mon Feb 28 11:21:38 2022 daemon.info dhclient: DHCPDISCOVER on eth0 to port 67 interval 3

Or if you type the ‘uptime’ command (or you can use the ‘top’ command if you wish) and see your load average approaching 2 or higher – I have found that anything above 2 may have performance impacts to your miner.

11:23:36 up 20:10, 0 users, load average: 1.77, 1.22, 1.18

The way to interpret the load average is this: the first value is the load average over the last 1 minute, the second value is the load average over the last 5 minutes, and the last value is the load average over the last 15 minutes. What does that really mean?

The load is a measurement or indication of how much work your miner is doing, displayed as a number. If your miner was doing no work at all, it would be 0. That’s not going to happen. But as the various processes inside your miner run, each process waiting for CPU to become available adds to your load average. The higher the load average, the more processes are waiting for the CPU which means internal delays might occur and the expected output another process is waiting for might be delayed too long or missed entirely. And the ‘uptime’ output will show you what’s happening right now, what happened over the past 5 minutes, and the past 15 minutes. Are you trending up? Is the spike you’re seeing right now just a bunch of information occurring all at once (not a cause for concern) or is it a problem over a more extended period of time. Let’s take my example above.

1.77 load average over a one minute period. That means that .77 processes on average were waiting for the processor (CPU) to become available – so my miner is 77% overloaded. (not great, but not awful)

1.22 load average over a five minute period. Again, .22 processes on average were waiting, so 22% overloaded. This is normal.

and 1.18 load average over a fifteen minute period, 18% overloaded which is perfectly fine and normal.

But what concerned me was 77% overloaded and as I looked into the logs, it wasn’t doing anything out of the ordinary. What I did find however, was looking at the system log was the DHCPDISCOVER errors that were happening very regularly. ” daemon.info dhclient: No working leases in persistent database – sleeping ” and then 5 minutes later ” daemon.info dhclient: DHCPDISCOVER on eth0 to port 67 interval 3 ” and eventually ” daemon.info dhclient: No DHCPOFFERS received. ” but then the process repeated itself. Over and over. This is what I did to solve the issue.

I am using the WiFi connection to connect as this miner is at a hosted site and I did not want to worry about opening ports on the host’s router. I have it configured to directly connect to a shared VPS that I purchased and configured OpenVPN Server on. The miner connects via OpenVPN Client automatically and the miner is not relayed and is completely accessible from anywhere via VPN.

What I noticed was that the eth0 ethernet interface was set for DHCP. And despite it not being connected to any cable, it still tried repeatedly to get an IP address. Personally, I think this is a flaw/bug but I could be wrong. Either way, the fact that the ethernet interface was continuing to try to get a DHCP address – I think – was causing some of the CPU load on the machine. I set the interface to static, just to stop it from the DHCP loop as follows:

In case I ever need to go back into it, I can use the default ethernet IP address of but more importantly – stop the DHCP loop from happening. 6 minutes later, my load average became:

11:29:11 up 20:16, 0 users, load average: 0.81, 1.15, 1.16

Was it a coincidence? Who knows. But I do know that these miners have small CPU’s and anything you can do to prevent excess processes from happening helps the miner better perform. So if you’re seeing DHCPDISCOVER or dhclient: No working leases in persistent database – sleeping or No DHCPOFFERS received messages – I would recommend doing the static IP on the interface you aren’t currently using or disabling your WIFI if you’re using ETH just to prevent this loop.

This guide for the Milesight UG65 Helium Miner is brought to you by Dennis Crawford. To help pay for server hosting costs, if you are looking for outdoor helium deployment equipment, please consider using the Amazon Storefront which has various products to use in an outside HNT environment. Or, if you’d like here is the HNT donation wallet:

13kPLKyXAVwHwTTKy7GDS5pAgM3X2A8BoeEezhSs7ZTb6cLnfwN – never expected, but always appreciated!!