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