Overview

All eGauge meters use NTP (Network Time Protocol) to obtain the current date and time. The exact process used depends on the meter hardware version (eGauge2, EG30xx, EG4xxx). Access to an NTP server isn't required, but it is highly recommended to ensure the meter keeps the correct date and time. For 99% of installation scenarios, NTP works just fine with the default settings. However, it may be necessary to manually verify NTP synchronization is working, use different NTP settings, or troubleshoot problems with NTP.

This document is intended to provide a general overview of NTP functionality as it pertains to eGauge meters. However, in the interest of brevity many advanced concepts will be simplified or ignored. For more information on general NTP concepts, please refer to this article.

Why do I need NTP?

The eGauge meter features an internal clock which can keep (approximate) time over short a short duration. However, without an active NTP connection the meter's internal clock may drift by as much as a few minutes per month. This may be acceptable for some users, but many monitoring scenarios require time-accurate data (e.g., for billing purposes).

Furthermore, if the meter experiences an extended power outage the internal battery or capacitor which maintains the internal clock will be depleted. This will cause the meter to use the last known date and time when power is restored - meaning data recorded after that point will have the wrong timestamps. If the meter can connect to an NTP server when it's brought back online, it should automatically adjust the date and time before it starts recording.

The amount of time a meter can maintain the correct date and time without power depends on the meter model:

In cases where an NTP server isn't available (e.g., locations without an Internet connection), the user must take care to keep the meter date and time updated manually. It's especially important to check the date and time immediately after any power outages.

To summarize, NTP is a convenience feature and helps ensure the collection of accurate data. Although it's possible to use a meter without NTP, doing so is not recommended.

Configuration

In cases where an NTP server isn't available (e.g., locations without an Internet connection), the user must take care to keep the meter date and time updated manually. It's especially important to check the date and time immediately after any power outages.

To summarize, NTP is a convenience feature and helps ensure the collection of accurate data. Although it's possible to use a meter without NTP, doing so is not recommended.

The NTP server hostname is configured under Setup → Network → Time. In the following example, the meter is set to use the {0..3}.pool.ntp.org option mentioned previously:

The clock Synchronization status is shown on the Network Time Setup page.  Possible status and meanings are:

• Synchronized: The clock is synchronized with the server showing a green check icon as shown in the example above. White checks as shown above indicate a valid time source that is not currently being used.
• synchronizing: The configured NTP server has been found but has not fully synchronized yet. While synchronization is in progress you may see a rotating arrow icon.
• unsynchronized: The NTP server is unreachable.
• unknown: The meter has not yet checked for an available NTP server.

Configuration & Status in the Classic View

When using the Classic view, The NTP server hostname is configured under Settings → Date & Time. In the following example, the meter is set to use the {0..3}.pool.ntp.org option mentioned previously:

Checking Status

Although there is not a hard linked NTP status page built into the  Classic meter UI, it is possible to check the NTP status of a meter by appending /cgi-bin/get?ntp to the end of the meter URL. For example:

DEVNAME.egaug.es/cgi-bin/get?ntp

DEVNAME.egauge.io/cgi-bin/get?ntp

HOSTNAME.local/cgi-bin/get?ntp

LOCAL_IP_ADDR/cgi-bin/get?ntp

Each meter hardware version uses a different method to obtain this data, and has a different output style:

Meter Version	Method Used
EG4xxx	ntpctl -s all (OpenNTPD)
EG30xx	/usr/bin/ntpq -p (ntpq)
eGauge2	N/A (no data returned)

EG4xxx

• At the top of the page, the meter will list the number of valid peers. In this case, 2 of the four peers are valid. As long as one peer is valid, NTP synchronization should work as expected.
• Also at the top of the page, "clock synced" indicates the eGauge's internal clock is synchronized with the NTP server. It is normal for this to show "unsynced" for some time (up to five minutes) after a reboot.
• If the summary area is completely blank, it means the NTP daemon is not running. A reboot may resolve this issue.

 

EG30xx

• Valid peers (technically, peers marked for consideration) are preceded by a "+". The peer currently used for synchronization is preceded with a "*". As long as at least one peer has a *, NTP synchronization should work as expected. In the above example, three peers are valid and the meter is synced with one peer. This status page may be blank or not show any + or * symbols for some time (up to five minutes) after a reboot.
• If the summary area is completely blank, it means the NTP daemon is not running. A reboot may resolve this issue.

eGauge 2

• eGauge2 meters use NTP to sync their internal clocks, but they do not provide a summary of connected peers. This is expected behavior and will not be changed due to meter hardware limitations.

 

 

NTP Functionality and Behavior

NTP timekeeping is a complex subject, and it would go beyond the scope of this article to fully explain. However, there are some basic concepts which are worth discussing here. For a more complete discussion of the subject, refer to this article.

Functionality

Put simply, an NTP server works by obtaining the correct date and time from a reference clock and making that date and time information available to a device. Reference clocks are generally extremely accurate (and as a result, extremely expensive). The internal clocks of most computing devices are generally inexpensive, but also not very accurate. NTP serves as a software-based solution to this problem. NTP servers may be run and hosted by anyone, including home users.

The NTP software running on the eGauge uses several criteria to determine the quality of an NTP server. The criteria for this is too complex to detail here, but the takeaway is that the meter will automatically handle sever selection and use the best (most accurate and accessible) available servers. This is where the strata statistic comes in - strata indicates the quality of a server, with 1 being the best quality.

Typically, all of this happens "behind the scenes" (this is also true for other computing devices, including personal computers). However, in certain cases it may be necessary to check the meter's NTP status (to ensure it's reaching a valid server) or modify settings (if the default servers can't be reached). 

General Behavior

On bootup (e.g., after a reboot or when first installed), the eGauge will attempt to establish a connection to an NTP server. At this point, the meter may make a long jump to the correct date and time. This is technically referred to as a "step", using the settimeofday() function. This jump happens instantaneously, but it may only happen immediately after a reboot. However, if it takes too long to find an NTP server (e.g., because the network is not ready, because the NTP server is not resolvable, etc.) the meter may "miss" its chance to do this. Often, rebooting the meter will allow it to sync on the second try.

At any time during normal operation, the eGauge may attempt to slowly adjust the meter date and time to match the date and time provided by the NTP server. This is known as a "slew", using the adjtime() function. Unlike a "step", a "slew" will slowly change the date and time at a rate of about 1 ms per second. For example, a clock offset of 1 second would take about 1000 seconds or 16 minutes to sync up. Obviously this is much slower than a "step", but "slew" is really only intended to handle small changes. This is also part of the reason a meter may take several minutes to show "synced" status after a reboot - a reboot introduces about a 120ms offset into the date and time, which would take about 2 minutes to sync back up using "slew".