Hi,
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?
tnx!
uci show system:
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.server='0.openwrt.pool.ntp.org' '1.openwrt.pool.ntp.org' '2.openwrt.pool.ntp.org' '3.openwrt.pool.ntp.org'
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?
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.
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 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.
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.
NAME
adjtime -- correct the time to allow synchronization of the system clock
SYNOPSIS
#include <sys/time.h>
int
adjtime(const struct timeval *delta, struct timeval *olddelta);
DESCRIPTION
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.