USE_PACKET_TIMESTAMP

Eric S. Raymond esr at thyrsus.com
Thu Jun 8 19:47:23 UTC 2017


Hal Murray <hmurray at megapathdsl.net>:
> 
> >> If Solaris doesn't support time stamps, I would expect
> >> ntp_packetstamp to die on a #error.  What happened with it?
> 
> > I factored the code so that if waf configure doesn't find a way to get
> > packet arrival times from the UDP layer it uses the arrival time collected
> > in userspace (ntp_packetstamp() isn't called or even built).  So the loss is
> > exactly the lag in the network stack.
> 
> The "lag" is only under light load.  Round up if a second packet arrives 
> while ntpd is working on the first packet (or refclock) or the OS scheduler 
> decides it has something more important to do.

True.  The packet-processing path is pretty fast, though.  Jitter due to
the scheduler probably dominates.  I judged this was acceptable at modern
tick rates, though it would not have been when ntpd was built.

> I can't find any hints of that sort of test in wscript or ntpd/wscript.
> 
> There was a blizzard of ifdefs in ntp_packetstamp that would do what you 
> describe.  I think.  The code was close to impossible to understand but there 
> wasn't anything else it could do.

You're right.  I had forgotten that waf isn't doing this directly.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.



More information about the devel mailing list