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