System time incorrect - ntp not working?

I was fiddling with rrdtool and noticed updates weren't being logged.
I noticed that the 'last update' time was: Sat Dec 23 16:14:00 CET 2017
while 'N' i.e. now, current time was set to: Wed Feb 17 05:39:00 CET 2016

I never checked system time, in any case i would expect ntp to correct it at the next update.
any idea what could've happened? why it is/wasn't updating?


uci show system:
system.ntp.server='' '' '' ''

What is the output of date?

i just fixed the date manually so now it's correct ;-p

but i think it's a classic case of PEBCAK,
i (probably) was checking the rrdtool timestamps earlier with "date " ...
which (apparently) not only outputs the conversion but also sets the time, i.e. -s is implied when no options specified. which was a bit unexpected.

so how often is ntp supposed to update the system time?

if ntpd is running, continuously.

Please post the output of logread | grep 'ntp'

nothing in the logs , but ntpd seems to be unning

# logread | grep ntp
# ps | grep ntp
 1680 root      1204 S<   /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p -p -p -p 3.
 5152 root      1200 S    grep ntp

ntpd from busybox isn't anywhere near as sophisticated as the reference ntpd implementation.

Since the crystals on wireless routers are usually responsible for accurate frequency for the transmitters, they generally aren't horrible, typically 100 ppm or better.

100 ppm over an hour is 360 ms

If you want "great" time accuracy, and have the space on your device, I'd recommend installing the "real" ntpd package.

I just stopped and started sysntpd and am watching it with tcpdump, as you've got me curious as to how often the busybox version queries the servers.

While that's settling down,

MINPOLL is 5 (32 seconds)
MAXPOLL is 12 (4096 seconds, a little over an hour)

I seldom see more than 512 seconds for poll time with "real" ntpd running under FreeBSD on amd64, even with the pre-arranged peering I have.

After about half an hour, the OpenWrt poll interval looks like 128 seconds.

I'm not sure what sysntpd does, but usually the "real" ntpd first sets the clock at startup, and then skews the clock in order to make it track times. If you come along and suddenly set the clock to years in the past... it could maybe take months for it to skew it back to reality?? I doubt that ntpd implementations would skew at the rate of say weeks per second etc that is too unlikely to work well.

I think the solution is don't randomly mis-set the time using date :wink: and if you do, just reboot and let it pick up the time properly.

After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and ntpd will terminate itself, believing something very strange must have happened.

Even if ntpd seems to be running, timestamps might get rejected due to a huge time difference.

Wouldn't that show up in the logs somewhere?

anyway, the easy answer is indeed not to suddenly jump back in time :slight_smile:
now i'm just in the settling my curiousity phase :smiley:

thanks all for the quick responses!

No, it's just an operational parameter that isn't logged, even with the reference implementation of ntpd.

I've been watching

tcpdump -ni bat0 udp port 123

(bat0 is that device's link to the rest of the world)

There isn't the equivalent of ntpq in the busybox implementation so the internal state isn't available from the command line, as far as I know.

right, i didn't mean the internal parameter. I meant the fact that ntp did an update.
and could you confirm that ntp indeed does a 'skew' and not a whole-sale update. I always assumed it got an exact time from the server and did a wholesale update.

A well-behaved NTP implementation will generally slew the clock, once the initial set is made. Jumps in time are generally detrimental. Jumps backward in time can be disasterous. The slew rate is typically limited to 500 ppm. Note that a "good" NTP implementation will estimate the frequency of the device's internal clock and "continually" apply corrections. adjtime or similar often handles this slew within the kernel itself.

     adjtime -- correct the time to allow synchronization of the system clock

     #include <sys/time.h>

     adjtime(const struct timeval *delta, struct timeval *olddelta);

     adjtime() makes small adjustments to the system time, as returned by gettimeofday(2), advancing or retarding it by the time specified by the timeval delta.
     If delta is negative, the clock is slowed down by incrementing it more slowly than normal until the correction is complete.  If delta is positive, a larger
     increment than normal is used.  The skew used to perform the correction is generally a fraction of one percent.  Thus, the time is always a monotonically
     increasing function.  A time correction from an earlier call to adjtime() may not be finished when adjtime() is called again.  If olddelta is non-nil, the
     structure pointed to will contain, upon return, the number of microseconds still to be corrected from the earlier call.

Edit: At least for my OpenWrt boxes, very little happens that needs device-to-device synchronization much better than a second or so. There are only a couple things I can think of that happen faster that I need 100-ms or better device-to-device synchronization. Two that come to mind would be:

  • Examining STP topology-change speed
  • Examining 802.11r roaming speed

An hour in now, my OpenWrt box is polling "public pool" servers at 256 seconds and is within 3 ms of my "good" NTP server (which it is not using as a peer).

Two hours in now, the poll time appears to 512 seconds and is still within 3 ms of my reference.

thanks for digging in so deeply.

just to be clear: i have no application whatsoever for an extremely precise ntp timesync.

the root cause of my question was twofold:

  • unexpected behaviour of date when no -s was specified - which is indeed in the help albeit not so obvious
  • my expectation of a whole-sale time update - which doesn't make sense given the requirement of (an approximation) of monotonous time.

so both misunderstandings have been set right and i am wiser than i was before :smiley:

1 Like