SO_TIMESTAMP may go away

[Daniel Franke]

Yes, if you go back that far then there's been significant change.
Nonetheless, that change isn't relevant. The current granularity of
1ms is still coarse enough that it would be obvious if it were a
factor. Multicore processors are the reason it isn't.

On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymond <esr at thyrsus.com> wrote:
>
> Daniel Franke <dfoxfranke at gmail.com>:
> > 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.
>
> Your historical baseline isn't long enough.  The NTP code has roots in
> the 1980s, but there was a massive change in Unix schedular
> granularity in the 1990s as typical clock speeds went from 10e7Hz to
> 10e8Hz. On Linux it happened early enough that the changeover was
> poorly documented and is now largely forgotten; it's reasonable
> that you don't know about it.
>
> I actually learned this the hard way when it happened; one of my older
> small projects was a real-time game (Tetris implemented for curses) with a
> delay loop that became unplayably fast after the jump.  If I groveled
> through my git logs I could probably pin down when I had to change it.
>
> The NTP packet-stamp code dates from the before time, when sampling lag
> due to timeslice granularity was an order of magnitude or more worse
> than it is now.  From some of its details I'd guess it was written about
> '87 or '88.
> --
>                 <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.
>
>