receive time stamps - current status

Eric S. Raymond esr at thyrsus.com
Sun Jun 11 11:40:26 UTC 2017


Hal Murray <hmurray at megapathdsl.net>:
> 
> I remove the SO_BINTIME mode.  It's only supported by FreeBSD and they don't 
> support it for IPv6.  They do support SO_TIMESTAMP.
> 
> The downside of that is reduced resolution on the time stamps.  BINTIME gives 
> 32 bit fractions of a second while TIMESTAMP gives microseconds (roughly 20 
> bits).  We could get the extra resolution for IPv4, but the extra complexity 
> of the code doesn't seem worth it.

Agreed.

> The current code assumes that we have either SO_TIMESTAMP or SO_TIMESTAMPNS.
> So far SO_TIMESTAMPNS is Linux only.  Configure doesn't check.  It should die 
> at build time.
> 
> So far, Solaris is the only OS I know of where we have encountered troubles.  
> See Issue #342
>   https://gitlab.com/NTPsec/ntpsec/issues/342
> 
> I'm assuming gcc on Solaris will  get fixed.
> 
> The current code will require intervention when we discover an OS/environment 
> where it doesn't work.  So far, with a sample size of 1 (or maybe 1/2), the 
> solution is to fix the waf recipe.  When we get a test case where that 
> doesn't work we can figure out how to handle it.
> 
> It would not be hard to make things build and run without receive time 
> stamps.  It might work poorly under heavy load, but we've been running that 
> way for 6 months and nobody complained.
> 
> I think time stamps are important so I haven't implemented any way to run 
> without them.  If we need that, one option would be to add a configure option 
> such as --disable-timestamps.

Half-anticipating such problems is why I isolated the timestamp getter to
is own module.  That reduced the chances that stirring this pot will damage
something else.

As you say, "we've been running that way for 6 months and nobody
complained."  I was rather expecting that the induced jitter would
be well below normal NTP accuracy expectations.

Hm, I think I'll add a comment about that in the internals tour.
-- 
		<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