Re: [Ntp] Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)

[Doug Arnold <[e-mail]>]

I started working on network timing in 1998.  At that time they told me not to worry about leap seconds because they were about to get rid of them in UTC.  I can always tell when someone is new to timing, because they tell me they heard that leap seconds are going away soon.   Unfortunately many technical standards and government regulations specify UTC rather than TAI.  So we definitely have to live them

Doug

On 1/8/21, 10:47 AM, "Martin Burnicki" <[e-mail]> wrote:

    Warner Losh said:
    > On Fri, Jan 8, 2021, 8:22 AM Martin Burnicki
    > <martin.burnicki=[e-mail]
    > <mailto:[e-mail]>> wrote:
    > 
    >     Doug Arnold wrote:
    >     > I think that the point of a leap smear is that no special handling
    >     of leap seconds is needed by the client.  It is introduced gradually
    >     over a number of polling periods.
    > 
    >     That's exactly the point. You want to hide the leap second from the
    >     client to avoid that *applications* run into problems when the kernel
    >     just steps the time back by 1 second.
    > 
    > 
    > My fundamental position on leap seconds hasn't changed in 20 years: they
    > are evil and must die. Earth clocks and atomic clocks need a different
    > way to synchronize.

    Agreed. But as long as there is no decision to abolish them, we have to
    live with them, and have the same discussions over and over again. ;-)

    > Leap seconds generate dozens of edge cases,
    > operational difficulties and data dependencies that complicate time for
    > everyone and all that added complication has a cost that far exceeds the
    > benefit. 
    > 
    > Smearing is the latest way to paper over all this and keep applications
    > naive. I'm not sure if I view it as a brilliant hack to protect the
    > applications from a rushed standard we are stuck with, or a deeply
    > worrying "enabling" of bad behavior by applications, libraries and
    > operating systems. 

    The biggest problem I see with smearing in general is to decide if
    applications that require millisecond accuracy can tolerate offsets up
    to +/- 0.5 or even 1 s in this special case.

    Beside this, there are lots of potential problems due to different
    shapes and intervals for the smearing.


    Martin
    -- 
    Martin Burnicki

    Senior Software Engineer

    MEINBERG Funkuhren GmbH & Co. KG
    Email: [e-mail]
    Phone: [phone]
    Linkedin: https://www.linkedin.com/in/martinburnicki/

    Lange Wand 9, 31812 Bad Pyrmont, Germany
    Amtsgericht Hannover 17HRA 100322
    Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
    Andre Hartmann, Heiko Gerstung
    Websites: https://www.meinberg.de  https://www.meinbergglobal.com
    Training: https://www.meinberg.academy