thoughts on fake IP addresses and clock specification
Hal Murray
hmurray at megapathdsl.net
Tue Dec 1 06:40:50 UTC 2015
esr at thyrsus.com said:
> I was under the impression that ntpd is internally set up so that clock
> samples come in as though they were packets from peers, with the fake IPv4
> addresses for their type and unit ID in the refid field. If so, then the
> fake addresses really are part of the wire protocol. Am I in error about
> this?
I don't think so, but I can't point a finger at the right place in the code.
I think they bypass that layer and join in at the peer level.
There are peer control blocks that have an IP Address in them. That's what
the main control logic works with.
Internally, each refclock has a FIFO holding the last ~64 samples. For
things like NMEA, each time the driver gets a valid sample it adds it to the
FIFO. For the Atom/PPS driver there is a hook that gets called/polled each
second. If it finds good data, it adds a sample to the FIFO. The FIFO is
actually a ring buffer. On overflow, old samples are dropped.
At the polling interval, the driver is "polled". (Note the possible
confusion on "poll".) That is parallel with sending a packet. The driver
can call back and say "process everything in the FIFO", or do something or
set a flag and call back later.
The process everything step sorts the contents of the FIFO, then discards
outliers, roughly 1/3 of the samples, and then figures out the average and
injects that into the peer buffer.
The peer buffer holds the last 8 samples from the wire. The normal logic
uses the one with the lowest round trip time. That's a hack to minimize
errors from queuing delays out on the big bad internet. The refclock data
always has a round trip time of 0. I assume the code is setup to take the
most recent of equal samples.
--
These are my opinions. I hate spam.
More information about the devel
mailing list