SO_TIMESTAMP may go away

[Eric S. Raymond]

Daniel Franke via devel <devel at ntpsec.org>:
> One thing ntpd does do (both in NTP Classic and in NTPsec) is fetch
> kernel timestamps on incoming packets using the SO_TIMESTAMP option.
> This is different from hardware timestamps; they're not generated by
> the NIC, they're generated by the kernel at the moment the NIC passes
> the packet to it. No analogue to SO_TIMESTAMP exists for outgoing
> packets.

Be aware that that code is on my hit list.

Last year, due to a config bug, we were building for a while with this feature
disabled.  *Nobody noticed.*  Here's what the tour document says about this:

    (Also, it turns out not to be important at post-Y2K machine speeds to
    get those arrival timestamps from the UDP layer ASAP, rather than
    looking at packet read time in userspace. The cost of the latter,
    naive approach is additional jitter dominated by process-scheduling
    time; this used to be significant relative to users' accuracy
    expectations for NTP, but scheduler timeslices have since decreased
    by orders of magnitude and squashed the issue. We know this from some
    tests setup having run for six months with packet-timestamp fetching
    accidentally disabled...  But they weren't busy systems.)

I haven't actually removed this yet because I'd prefer to perform some actual
alpha/beta testing before I affirmatively rip it out. But if it gets lost
during a move to Go I won't fash myself about it.  I suspect nobody would
ever notice.

Gary, you're the test and metrics expert.  How would you audit for performance
degradation from disabling this feature?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.