One thing to keep in mind is that if the client is using SO_TIMESTAMP but the server isn't, or vice versa, you're going to introduce a persistent inaccuracy on the order of a microsecond, due to the resulting asymmetry in the point at which the timestamp is captured.
On Mon, Mar 4, 2019 at 8:36 AM Daniel Franke <dfoxfra...@gmail.com> wrote: > > On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond <e...@thyrsus.com> wrote: > > (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.) > > Scheduler timeslices haven't changed much. The current default on > Linux is 1ms and it's been that way for a long time. What's changed is > that everybody has multicore processors now, so contention almost > never happens. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
