This basically adds the "rtable %d" keyword to "listen on", "server",
"servers" keywords, to specify which routing table to use.
OK henning@ claudio@ sthen@
manpage reviewed by jmc@
corrections more often. Due to physical effects crystal oscillators aren't
really stable beyond 1000s or so - at least not the kind found in pc's.
ok henning
offset. This avoids future frequency adjustments based on measurements of a
clock that was being adjusted. End result: more stable clock and better
frequency convergence.
Also, fix a mis-ordered structure member while I'm here.
ok henning
the first query we will never do the settime because
SENSOR_QUERY_INTERVAL (30s) is greater than SETTIME_TIMEOUT (15s). so
during the settime period only, be more aggressive and use
SETTIME_TIMEOUT/3 for the query interval.
ok henning@
reason: the parent process must never ever block, but the dns routines can.
last not least this fixes ntpd -s 'hanging' for a long time.
tested by a couple of people
This allows recovery after an IP address change (e.g. on dialup links).
Also move the update of "nextaction" timeout below the deadline check.
OK henning@
happens when a SIGINFO is received, or when the majority of peers or
sensors is bad. The latter with a maximum of once per 24 hour.
ok henning@ ckuethe@ mbalmer@
improves sensor timekeeping significantly.
Before this patch my test system's frequency adjustment would range
between -350 and +250, with timedelta rarely getting close to 0. After,
frequency adjustmens is on the order of +/- 0.05ppm, with time +/- a
few microseconds away from 0
ok henning, mbalmer, otto
symbol, follow the guidelines from K&R: only one definition of a
global symbol (and possibly more declarations). Rename some vars
here and there to avoid shadowing. ok henning@
of the last sensor update time got broken, doesn't show up with gps since
it updates often (more often than we read), but naddy ran into it with dcf.
record time of last sensor datum seperately. ok naddy balmer
time, and make ntpd use that to send the next uery to an ntp peer and the
like. this has the advantage that changes to the clock do not interfere
with the intervals. for example, when we start on machines without an
RTC and the initial settime (-s) kicks in, intervals were strange.
idea from amandal@entrisphere.com, this implementation by me
tested ckuethe, phessler, mbalmer, ok mbalmer
them only every 30 seconds. now query them every 5,and take the median
value from 7 queries as sensor value. this takes outliers out of the
equation and makes the overall result much better, especially for
sensors with heavy jitter (like nmea for now)
only do frequency compensation if the clock is synced, and a slightly
diffent way of computing the linear regression.
You'll need a recent kernel and libc to use this.
Testing by naddy@ and ckuethe@ and others, thanks!
ok henning@
now. untested due to lack of hardware, and it wouldn't have worked in the
plane anyways. work in progress, currently picks up and uses all sensors
it finds, config file bits to be added soon. theo fine with this going in
benno