SO_TIMESTAMP may go away

[Daniel Franke]

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 <dfoxfranke at gmail.com> wrote:
>
> On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond <esr at 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.