Leap second functional question - NTP

This is a discussion on Leap second functional question - NTP ; Hi there, I've dug a bit for the answer to this question, but have not yet see the answer. Perhaps it is buried somewhere that I haven't found it yet. Exactly what is the specified behaviour for transmission of the ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 78

Thread: Leap second functional question

  1. Leap second functional question

    Hi there,

    I've dug a bit for the answer to this question, but have not yet see the
    answer. Perhaps it is buried somewhere that I haven't found it yet.

    Exactly what is the specified behaviour for transmission of the NTP
    protocol around a leap second event?

    1. Leap second indicator: shows leap second pending
    - how far in advance of the leap second does it start showing it
    pending? One minute? One hour? 12 hours? One day?
    - I assume that it turns off at the **end** of the leap second it
    announces, correct?

    2. NTP timestamp: shows seconds since 1900-01-01 00:00:00
    - is this value corrected for the leap second event? Or does it
    just increase monotonically right on through, expecting the "listener"
    to correct for the leap second?

    Contrived Example - Adding a Leap Second
    ========================================
    As an example, let's say that there was a leap second to be added on
    2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This
    is a contrived example, for sure, but it's a value for which I have the
    timestamp worked out.

    If the leap second indicator bits turn off at the **end** of the leap
    second it announces, and if the timestamp increases monotonically right
    through, then the values returned in this contrived example might look
    like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2008-02-10 23:59:58.0000 CB5A0E7E.00000000 01
    2008-02-10 23:59:59.0000 CB5A0E7F.00000000 01
    2008-02-10 23:59:59.5000 CB5A0E7F.80000000 01
    2008-02-10 23:59:59.9000 CB5A0E7F.E6666666 01
    2008-02-10 23:59:60:0000 CB5A0E80.00000000 01
    2008-02-10 23:59:60.5000 CB5A0E80.80000000 01
    2008-02-10 23:59:60.9000 CB5A0E80.E6666666 01
    2008-02-11 00:00:00.0000 CB5A0E81.00000000 00
    2008-02-11 00:00:01.0000 CB5A0E82.00000000 00

    Contrived Example - Deleting a Leap Second
    ==========================================
    Another contrived example, let's say that there was a leap second to be
    removed on 2008-02-11 at 00:00:00 (or is that 2008-02-10 at 23:59:59?).

    Then the values returned in this contrived example might look like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2008-02-10 23:59:58.0000 CB5A0E7E.00000000 01
    2008-02-10 23:59:58.5000 CB5A0E7E.80000000 01
    2008-02-10 23:59:58.9000 CB5A0E7E.E6666666 01
    2008-02-11 00:00:00.0000 CB5A0E7F.00000000 00
    2008-02-11 00:00:01.0000 CB5A0E80.00000000 00

    Is this correct? Or, can you mark up my examples to show how I might be
    in error?

    Regards,

    Dean Weiten.

  2. Re: Leap second functional question

    Dean Weiten wrote:

    >
    > 1. Leap second indicator: shows leap second pending
    > - how far in advance of the leap second does it start showing it
    > pending? One minute? One hour? 12 hours? One day?


    At most the whole day. See ntpd/ntp_loopfilter.c for details.

    > - I assume that it turns off at the **end** of the leap second it
    > announces, correct?


    It turns off at the start of the next day.

    In line with being tolerant in what you accept, you should probably only
    look at the leap indication that existed just before you crossed the
    candidate insertion/deletion time, and not assume that it will be unset
    on other days.


    >
    > 2. NTP timestamp: shows seconds since 1900-01-01 00:00:00
    > - is this value corrected for the leap second event? Or does it just
    > increase monotonically right on through, expecting the "listener" to
    > correct for the leap second?


    It behaves the same way as POSIX time, i.e. you can calculate a civil
    date and time for any time, except an inserted leap second, without
    knowing when leap seconds were used.

    >
    > Contrived Example - Adding a Leap Second
    > ========================================
    > As an example, let's say that there was a leap second to be added on
    > 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This


    That's not possible. The nearest valid leap second insertion point
    would be the end of December 2007. The only other candidate is the end
    of June.


  3. Re: Leap second functional question

    Dean Weiten wrote:

    > As an example, let's say that there was a leap second to be added on
    > 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This


    It would be added at 2007-12-31T23:59:60 or 2008-06-30T23:59:60. For a
    deleted second, 2007-12-31T23:59:59 or 2008-06-30T23:59:59 would be deleted.

  4. Re: Leap second functional question

    Hmm, I **said** that it was a contrived example. Let me put it more
    correctly.

    Dean.


    Contrived Example - Adding a Leap Second
    ========================================
    As an example, let's say that there was a leap second to be added on
    2008-01-01 at 00:00:00.

    If the leap second indicator bits turn off at the **end** of the leap
    second it announces, and if the timestamp increases monotonically right
    through, then the values returned in this contrived example might look
    like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2008-02-10 23:59:58.0000 CB2400FE.00000000 01
    2008-02-10 23:59:59.0000 CB2400FF.00000000 01
    2008-02-10 23:59:59.5000 CB2400FF.80000000 01
    2008-02-10 23:59:59.9000 CB2400FF.E6666666 01
    2008-02-10 23:59:60:0000 CB240100.00000000 01
    2008-02-10 23:59:60.5000 CB240100.80000000 01
    2008-02-10 23:59:60.9000 CB240100.E6666666 01
    2008-02-11 00:00:00.0000 CB240101.00000000 00
    2008-02-11 00:00:01.0000 CB240102.00000000 00

    Contrived Example - Deleting a Leap Second
    ==========================================
    Another contrived example, let's say that there was a leap second to be
    removed on 2008-01-01 at 00:00:00.

    Then the values returned in this contrived example might look like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2008-02-10 23:59:58.0000 CB2400FE.00000000 01
    2008-02-10 23:59:58.5000 CB2400FE.80000000 01
    2008-02-10 23:59:58.9000 CB2400FE.E6666666 01
    2008-02-11 00:00:00.0000 CB2400FF.00000000 00
    2008-02-11 00:00:01.0000 CB240100.00000000 00

    Is this correct? Or, can you mark up my examples to show how I might be
    in error?


    David Woolley wrote:
    > Dean Weiten wrote:
    >
    >>
    >> 1. Leap second indicator: shows leap second pending
    >> - how far in advance of the leap second does it start showing it
    >> pending? One minute? One hour? 12 hours? One day?

    >
    > At most the whole day. See ntpd/ntp_loopfilter.c for details.
    >
    >> - I assume that it turns off at the **end** of the leap second it
    >> announces, correct?

    >
    > It turns off at the start of the next day.
    >
    > In line with being tolerant in what you accept, you should probably only
    > look at the leap indication that existed just before you crossed the
    > candidate insertion/deletion time, and not assume that it will be unset
    > on other days.
    >
    >
    >>
    >> 2. NTP timestamp: shows seconds since 1900-01-01 00:00:00
    >> - is this value corrected for the leap second event? Or does it
    >> just increase monotonically right on through, expecting the "listener"
    >> to correct for the leap second?

    >
    > It behaves the same way as POSIX time, i.e. you can calculate a civil
    > date and time for any time, except an inserted leap second, without
    > knowing when leap seconds were used.
    >
    >>
    >> Contrived Example - Adding a Leap Second
    >> ========================================
    >> As an example, let's say that there was a leap second to be added on
    >> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This

    >
    > That's not possible. The nearest valid leap second insertion point
    > would be the end of December 2007. The only other candidate is the end
    > of June.
    >


  5. Re: Leap second functional question

    I did it again, didn't correct the left hand time stamps!

    Contrived Example - Adding a Leap Second
    ========================================
    As an example, let's say that there was a leap second to be added on
    2008-01-01 at 00:00:00.

    If the leap second indicator bits turn off at the **end** of the leap
    second it announces, and if the timestamp increases monotonically right
    through, then the values returned in this contrived example might look
    like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2007-12-31 23:59:58.0000 CB2400FE.00000000 01
    2007-12-31 23:59:59.0000 CB2400FF.00000000 01
    2007-12-31 23:59:59.5000 CB2400FF.80000000 01
    2007-12-31 23:59:59.9000 CB2400FF.E6666666 01
    2007-12-31 23:59:60:0000 CB240100.00000000 01
    2007-12-31 23:59:60.5000 CB240100.80000000 01
    2007-12-31 23:59:60.9000 CB240100.E6666666 01
    2008-01-01 00:00:00.0000 CB240101.00000000 00
    2008-01-01 00:00:01.0000 CB240102.00000000 00

    Contrived Example - Deleting a Leap Second
    ==========================================
    Another contrived example, let's say that there was a leap second to be
    removed on 2008-01-01 at 00:00:00.

    Then the values returned in this contrived example might look like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2007-12-31 23:59:58.0000 CB2400FE.00000000 01
    2007-12-31 23:59:58.5000 CB2400FE.80000000 01
    2007-12-31 23:59:58.9000 CB2400FE.E6666666 01
    2008-01-01 00:00:00.0000 CB2400FF.00000000 00
    2008-01-01 00:00:01.0000 CB240100.00000000 00

    Is this correct? Or, can you mark up my examples to show how I might be
    in error?



  6. Re: Leap second functional question

    David Woolley writes:

    >Dean Weiten wrote:


    >> As an example, let's say that there was a leap second to be added on
    >> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This


    >It would be added at 2007-12-31T23:59:60 or 2008-06-30T23:59:60. For a
    >deleted second, 2007-12-31T23:59:59 or 2008-06-30T23:59:59 would be deleted.


    He is asking how it is added or subtracted.
    His date of Feb 11 was wrong, but was a trivial part of his question. He
    wants to know HOW the second is added or subtracted.

    NTP time is UTC which assumes 86400 seconds in each and every year.
    Exactly. Ie, those leap seconds are "forgotten" after they occur.
    Thus UTC does not tell you how many actual seconds occur between date A and
    date B/ There is a time scale, TAI which is the actual number of seconds.
    There have apparently been debates as to whether ntp should keep UTC or
    TAI. The latter makes more sense. The former is easier for operating
    systems to deal with since clocks and legal stuff it UTC (with timezone
    corrections).

    AFAIK ntp deletes a leap second by jumping, and inserts a second by
    stopping the clock for a second. -- well I am not sure that ntp actually
    does that. It may just hand the leap second to the kernel and hope the
    kernel does the right thing. If the kernel does not, then ntp spends the
    next hour readjusting the clock.



  7. Re: Leap second functional question

    Thanks, that was what I was looking for. You are saying that I didn't
    have it right, how about this.

    If I were to say "the timestamp will be what it would be outside the
    area of the leap second, regardless of whether or not a leap second is
    inserted or deleted", would that be correct? For instance, the
    timestamp 3 seconds after a leap second would be the same as without the
    leap second?

    Adding a Leap Second
    ====================
    As an example, let's say that there was a leap second to be added on
    2008-01-01 at 00:00:00.

    If the leap second indicator bits turn off at the **end** of the leap
    second it announces, and if the timestamp **holds** for the leap second,
    then the values returned in this contrived example might look like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2007-12-31 23:59:58.0000 CB2400FE.00000000 01
    2007-12-31 23:59:59.0000 CB2400FF.00000000 01
    2007-12-31 23:59:59.5000 CB2400FF.80000000 01
    2007-12-31 23:59:59.9000 CB2400FF.E6666666 01
    2007-12-31 23:59:60:0000 CB2400FF.FFFFFFFF* 01
    2007-12-31 23:59:60.5000 CB2400FF.FFFFFFFF* 01
    2007-12-31 23:59:60.9000 CB2400FF.FFFFFFFF* 01
    2008-01-01 00:00:00.0000 CB240100.00000000 00
    2008-01-01 00:00:01.0000 CB240101.00000000 00

    * - Undefined, fraction can be any value but would generally be held to
    no less the value of the last legitimate call during the previous second
    2007-12-31 at 23:59:59.

    NB time stamp of 2008-01-01 00:00:00 and 00:00:01 are the same as they
    would have been without the leap second addition.

    Deleting a Leap Second
    ======================
    Another example, let's say that there was a leap second to be removed on
    2008-01-01 at 00:00:00.

    Then the values returned might look like this:

    Time Timestamp Leap Second Bits
    ---- --------- ----------------
    2007-12-31 23:59:58.0000 CB2400FE.00000000 01
    2007-12-31 23:59:58.5000 CB2400FE.80000000 01
    2007-12-31 23:59:58.9000 CB2400FE.E6666666 01
    2008-01-01 00:00:00.0000 CB240100.00000000 00
    2008-01-01 00:00:01.0000 CB240101.00000000 00

    NB again time stamp of 2008-01-01 00:00:00 and 00:00:01 are the same as
    they would have been without the leap second addition.


    Unruh wrote:
    > David Woolley writes:
    >
    >> Dean Weiten wrote:

    >
    >>> As an example, let's say that there was a leap second to be added on
    >>> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This

    >
    >> It would be added at 2007-12-31T23:59:60 or 2008-06-30T23:59:60. For a
    >> deleted second, 2007-12-31T23:59:59 or 2008-06-30T23:59:59 would be deleted.

    >
    > He is asking how it is added or subtracted.
    > His date of Feb 11 was wrong, but was a trivial part of his question. He
    > wants to know HOW the second is added or subtracted.
    >
    > NTP time is UTC which assumes 86400 seconds in each and every year.
    > Exactly. Ie, those leap seconds are "forgotten" after they occur.
    > Thus UTC does not tell you how many actual seconds occur between date A and
    > date B/ There is a time scale, TAI which is the actual number of seconds.
    > There have apparently been debates as to whether ntp should keep UTC or
    > TAI. The latter makes more sense. The former is easier for operating
    > systems to deal with since clocks and legal stuff it UTC (with timezone
    > corrections).
    >
    > AFAIK ntp deletes a leap second by jumping, and inserts a second by
    > stopping the clock for a second. -- well I am not sure that ntp actually
    > does that. It may just hand the leap second to the kernel and hope the
    > kernel does the right thing. If the kernel does not, then ntp spends the
    > next hour readjusting the clock.
    >
    >


  8. Re: Leap second functional question

    Unruh wrote:
    []
    > AFAIK ntp deletes a leap second by jumping, and inserts a second by
    > stopping the clock for a second. -- well I am not sure that ntp
    > actually does that. It may just hand the leap second to the kernel
    > and hope the kernel does the right thing. If the kernel does not,
    > then ntp spends the next hour readjusting the clock.


    No. At least on Windows. IIRC, it doubles the clock speed for one second
    to move forward, and halves the clock speed for two seconds to move
    backwards. Something like that. No step is used. My recollection is at
    best vague about this, but searching the newsgroup archives may help you.

    Cheers,
    David



  9. Re: Leap second functional question

    Dean Weiten writes:

    >Thanks, that was what I was looking for. You are saying that I didn't
    >have it right, how about this.


    >If I were to say "the timestamp will be what it would be outside the
    >area of the leap second, regardless of whether or not a leap second is
    >inserted or deleted", would that be correct? For instance, the
    >timestamp 3 seconds after a leap second would be the same as without the
    >leap second?


    In theory yes. In practice, maybe not. It may well take a while for any
    specific machine to actually work through the leap second.


    >Adding a Leap Second
    >====================
    >As an example, let's say that there was a leap second to be added on
    >2008-01-01 at 00:00:00.


    >If the leap second indicator bits turn off at the **end** of the leap
    >second it announces, and if the timestamp **holds** for the leap second,
    >then the values returned in this contrived example might look like this:


    >Time Timestamp Leap Second Bits
    >---- --------- ----------------
    >2007-12-31 23:59:58.0000 CB2400FE.00000000 01
    >2007-12-31 23:59:59.0000 CB2400FF.00000000 01
    >2007-12-31 23:59:59.5000 CB2400FF.80000000 01
    >2007-12-31 23:59:59.9000 CB2400FF.E6666666 01
    >2007-12-31 23:59:60:0000 CB2400FF.FFFFFFFF* 01
    >2007-12-31 23:59:60.5000 CB2400FF.FFFFFFFF* 01
    >2007-12-31 23:59:60.9000 CB2400FF.FFFFFFFF* 01
    >2008-01-01 00:00:00.0000 CB240100.00000000 00
    >2008-01-01 00:00:01.0000 CB240101.00000000 00


    >* - Undefined, fraction can be any value but would generally be held to
    >no less the value of the last legitimate call during the previous second
    >2007-12-31 at 23:59:59.


    I think that the right answer is "held to be greater than the value of the
    last legitimate call. Ie, the time always increases.


    >NB time stamp of 2008-01-01 00:00:00 and 00:00:01 are the same as they
    >would have been without the leap second addition.


    They should be. Whether or not they are may well depend.



    >Deleting a Leap Second
    >======================
    >Another example, let's say that there was a leap second to be removed on
    >2008-01-01 at 00:00:00.


    >Then the values returned might look like this:


    >Time Timestamp Leap Second Bits
    >---- --------- ----------------
    >2007-12-31 23:59:58.0000 CB2400FE.00000000 01
    >2007-12-31 23:59:58.5000 CB2400FE.80000000 01
    >2007-12-31 23:59:58.9000 CB2400FE.E6666666 01
    >2008-01-01 00:00:00.0000 CB240100.00000000 00
    >2008-01-01 00:00:01.0000 CB240101.00000000 00


    >NB again time stamp of 2008-01-01 00:00:00 and 00:00:01 are the same as
    >they would have been without the leap second addition.



    I believe this to be the case. However, I am not an ntp expert so I hope
    that the people who really know (Mills?) can correct any errors I make.


    >Unruh wrote:
    >> David Woolley writes:
    >>
    >>> Dean Weiten wrote:

    >>
    >>>> As an example, let's say that there was a leap second to be added on
    >>>> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This

    >>
    >>> It would be added at 2007-12-31T23:59:60 or 2008-06-30T23:59:60. For a
    >>> deleted second, 2007-12-31T23:59:59 or 2008-06-30T23:59:59 would be deleted.

    >>
    >> He is asking how it is added or subtracted.
    >> His date of Feb 11 was wrong, but was a trivial part of his question. He
    >> wants to know HOW the second is added or subtracted.
    >>
    >> NTP time is UTC which assumes 86400 seconds in each and every year.
    >> Exactly. Ie, those leap seconds are "forgotten" after they occur.
    >> Thus UTC does not tell you how many actual seconds occur between date A and
    >> date B/ There is a time scale, TAI which is the actual number of seconds.
    >> There have apparently been debates as to whether ntp should keep UTC or
    >> TAI. The latter makes more sense. The former is easier for operating
    >> systems to deal with since clocks and legal stuff it UTC (with timezone
    >> corrections).
    >>
    >> AFAIK ntp deletes a leap second by jumping, and inserts a second by
    >> stopping the clock for a second. -- well I am not sure that ntp actually
    >> does that. It may just hand the leap second to the kernel and hope the
    >> kernel does the right thing. If the kernel does not, then ntp spends the
    >> next hour readjusting the clock.
    >>
    >>


  10. Re: Leap second functional question

    "David J Taylor" writes:

    >Unruh wrote:
    >[]
    >> AFAIK ntp deletes a leap second by jumping, and inserts a second by
    >> stopping the clock for a second. -- well I am not sure that ntp
    >> actually does that. It may just hand the leap second to the kernel
    >> and hope the kernel does the right thing. If the kernel does not,
    >> then ntp spends the next hour readjusting the clock.


    >No. At least on Windows. IIRC, it doubles the clock speed for one second
    >to move forward, and halves the clock speed for two seconds to move
    >backwards. Something like that. No step is used. My recollection is at
    >best vague about this, but searching the newsgroup archives may help you.


    Is this a windows OS dependent procedure? This of course means that the
    time is wrong for at least two seconds, plus errors due to overshoots, etc.


    >Cheers,
    >David




  11. Re: Leap second functional question

    Unruh wrote:
    > "David J Taylor"

    []
    >> No. At least on Windows. IIRC, it doubles the clock speed for one
    >> second to move forward, and halves the clock speed for two seconds
    >> to move backwards. Something like that. No step is used. My
    >> recollection is at best vague about this, but searching the
    >> newsgroup archives may help you.

    >
    > Is this a windows OS dependent procedure? This of course means that
    > the
    > time is wrong for at least two seconds, plus errors due to
    > overshoots, etc.


    You would need to check with the implementors, or back in this newsgroup
    archives. It means that any step is avoided which, IMHO, is far more
    important. I haven't seen any "errors due to overshoots".

    David



  12. Re: Leap second functional question

    "David J Taylor" writes:

    >Unruh wrote:
    >> "David J Taylor"

    >[]
    >>> No. At least on Windows. IIRC, it doubles the clock speed for one
    >>> second to move forward, and halves the clock speed for two seconds
    >>> to move backwards. Something like that. No step is used. My
    >>> recollection is at best vague about this, but searching the
    >>> newsgroup archives may help you.

    >>
    >> Is this a windows OS dependent procedure? This of course means that
    >> the
    >> time is wrong for at least two seconds, plus errors due to
    >> overshoots, etc.


    >You would need to check with the implementors, or back in this newsgroup
    >archives. It means that any step is avoided which, IMHO, is far more
    >important. I haven't seen any "errors due to overshoots".


    Also a step forward is not a problem. A step backward is a problem and
    should always be avoided on a computer.

    By overshoot error, I mean that they speed up the clock for one second say.
    How do they know when 1 sec has passed? The timer tick could have been
    delayed for some reason ( or even lost) suddenly the clock has been running
    at double speed or half speed not for 1 sec but for 1.01 sec or 1.05 sec.
    That is a large error ( even on linux with a 100Hz clock it is up to 5ms).
    Then
    ntp has to try to correct that error. that is what I mean by overshoot.
    Note that leap seconds have been happening so rarely that almost noone has
    seen one happen, or watched the system as the clock goes through that.

    Having ntp run on TAI would certainly be simpler, but would of course make
    the time keeping on the system much more complicated.


    >David




  13. Re: Leap second functional question

    Unruh wrote:
    > David Woolley writes:
    >
    >> Dean Weiten wrote:

    >
    >>> As an example, let's say that there was a leap second to be added on
    >>> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This

    >


    > He is asking how it is added or subtracted.
    > His date of Feb 11 was wrong, but was a trivial part of his question. He
    > wants to know HOW the second is added or subtracted.


    The date error is significant because, once one realizes there are only
    two possible days a year, it becomes unimportant when the flags are set
    and cleared. I have a suspicion that the transmission used not to be
    limited to the date of change, so the code may not restrict their
    forwarding because people were not limiting their implementation to
    those particular days..

    The current code basically checks the date and only sets the bits if it
    is one of those two days.

  14. Re: Leap second functional question

    David Woolley writes:

    >Unruh wrote:
    >> David Woolley writes:
    >>
    >>> Dean Weiten wrote:

    >>
    >>>> As an example, let's say that there was a leap second to be added on
    >>>> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?). This

    >>


    >> He is asking how it is added or subtracted.
    >> His date of Feb 11 was wrong, but was a trivial part of his question. He
    >> wants to know HOW the second is added or subtracted.


    >The date error is significant because, once one realizes there are only
    >two possible days a year, it becomes unimportant when the flags are set
    >and cleared. I have a suspicion that the transmission used not to be
    >limited to the date of change, so the code may not restrict their
    >forwarding because people were not limiting their implementation to
    >those particular days..


    Well, no, it is still important on those days. It does not occur every year
    or every day ( in fact I think we have not had one in about 4 years).



    >The current code basically checks the date and only sets the bits if it
    >is one of those two days.


    No, it does not. It only sets the bit if it has been told by a majority of
    its servers that a leap second is coming up. And we had a number of people
    having trouble in that a leap second seemed to have been announced to them
    in the middle of Jan this year. Ie, ntp on your system relies on your
    servers to tell about leap second. It is announce a month before hand and
    then on the day.




  15. Re: Leap second functional question

    Unruh wrote:
    > David Woolley writes:


    >> The date error is significant because, once one realizes there are only
    >> two possible days a year, it becomes unimportant when the flags are set


    > Well, no, it is still important on those days. It does not occur every year
    > or every day ( in fact I think we have not had one in about 4 years).


    But you can safely have it set for most of the previous six months and
    the following six months, whereas the questioner is assuming it must be
    cleared immediately the leap second has been implemented and not set
    more than a very short time in advance. (It certainly has to be set
    hours in advance, because some clients may not have polled within an
    hour, and each stratum can extend the propagation delay of the setting
    of the flags.)
    >
    >
    >
    >> The current code basically checks the date and only sets the bits if it
    >> is one of those two days.

    >
    > No, it does not. It only sets the bit if it has been told by a majority of
    > its servers that a leap second is coming up. And we had a number of people


    4p4's ntpd/ntp_loopfilter.c:
    /*
    * Set the leap bits in the status word, but
    * only on the last day of June or December.
    */
    tstamp = peer->rec.l_ui - JAN_1970;
    tm = gmtime(&tstamp);
    if (tm != NULL) {
    if ((tm->tm_mon + 1 == 6 &&
    tm->tm_mday == 30) || (tm->tm_mon +
    1 == 12 && tm->tm_mday == 31)) {
    if (leap_next & LEAP_ADDSECOND)
    ntv.status |= STA_INS;
    else if (leap_next &
    LEAP_DELSECOND)
    ntv.status |= STA_DEL;
    }
    }

    > having trouble in that a leap second seemed to have been announced to them
    > in the middle of Jan this year. Ie, ntp on your system relies on your
    > servers to tell about leap second. It is announce a month before hand and
    > then on the day.


    That tends to confirm that it has been acceptable to set the flag any
    time after the preceding candidate time.

  16. Re: Leap second functional question

    See http://www.eecis.udel.edu/~mills/leap.html.
    That would seem to be the authoritative source.

    Paul

  17. Re: Leap second functional question

    On Feb 18, 3:41 pm, Unruh wrote:

    > NTP time is UTC which assumes 86400 seconds in each and every [[year]] day.

    ....

    My understanding is the opposite: In the UTC time scale, the
    minute, hour, day, week are of variable duration, depending
    on the insertion or deletion of leap seconds.

    In the TAI time scale, the minute, hour, day, week are of
    constant duration.

    Paul


  18. Re: Leap second functional question

    Unruh wrote:
    > "David J Taylor"
    > writes:
    >
    >>Unruh wrote:
    >>> "David J Taylor"

    >>[]
    >>>> No. At least on Windows. IIRC, it doubles the clock speed for one
    >>>> second to move forward, and halves the clock speed for two seconds
    >>>> to move backwards. Something like that. No step is used. My
    >>>> recollection is at best vague about this, but searching the
    >>>> newsgroup archives may help you.
    >>>
    >>> Is this a windows OS dependent procedure? This of course means that
    >>> the
    >>> time is wrong for at least two seconds, plus errors due to
    >>> overshoots, etc.

    >
    >>You would need to check with the implementors, or back in this newsgroup
    >>archives. It means that any step is avoided which, IMHO, is far more
    >>important. I haven't seen any "errors due to overshoots".


    The Windows-specific implementation of the leap second handling in ntpd has
    been implemented by me.

    At the time I did that ntpd did not handle the leap second by itself. It
    just passed the leap second announcement to the kernel, so how the leap
    second was handled depended on the implementation of the kernel of a
    specific OS.

    If the host OS did not provide a kernel PLL then ntpd just did nothing
    during the leap second, so when a NTP server had inserted a leap second
    properly then ntpd running on a client without kernel PLL just observed a 1
    second time offset after UTC midnight and then stepped the system time
    about 15 minutes later. See NTP bug #508:
    See http://bugs.ntp.org/508

    I wrote a piece of code which handles the leap second under Windows and we
    at Meinberg made that version of ntpd available shortly before the leap
    second occurred. It still took some time until the patch made its way into
    the NTP code base, and when that happened I documented this in bug #686:
    http://bugs.ntp.org/686

    As already mentioned earlier there is also leap second info page which
    contains some information on leap seconds:
    http://www.meinberg.de/english/info/leap-second.htm

    This also contains a log of the last leap second under Windows, where the
    time is measured against a Meinberg GPS PCI card:
    http://www.meinberg.de/english/info/...nd.htm#log-ntp

    Recently Dave Mills has made some changes to the NTP development code base
    which shall handle leap seconds on any OS which does not provide a kernel
    PLL. I'll still have to check how this code works on Windows, and whether
    Dave and my leap second code would now insert 2 leap seconds instead of 1
    (I'm afraid this would be the case).

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  19. Re: Leap second functional question

    Martin Burnicki wrote:
    []
    > The Windows-specific implementation of the leap second handling in
    > ntpd has been implemented by me.

    []
    > This also contains a log of the last leap second under Windows, where
    > the time is measured against a Meinberg GPS PCI card:
    > http://www.meinberg.de/english/info/...nd.htm#log-ntp

    []
    > Martin


    Many thanks for those details, Martin.

    David



  20. Re: Leap second functional question

    David,

    David Woolley wrote:
    > The date error is significant because, once one realizes there are only
    > two possible days a year, it becomes unimportant when the flags are set
    > and cleared.


    That is not correct. End-of-June and end-of-December are only the
    _preferred_ dates. Here's a quote from paragraph "Coordinated Universal
    Time (UTC)" on the USNO web page:
    http://tycho.usno.navy.mil/leapsec.html

    "According to the CCIR Recommendation, first preference is given to the
    opportunities at the end of December and June, and second preference to
    those at the end of March and September."

    A similar statement can be found on the IERS web page:
    http://hpiers.obspm.fr/eop-pc/eartho...eapsecond.html

    "According to international agreements, first preference is given to the
    opportunities at the end of December and June, and second preference to
    those at the end of March and September. Since the system was introduced in
    1972, only dates in June and December have been used."

    Up to the recent changes in ntpd (which I have not yet reviewed in detail)
    ntpd would indeed have only accepted a leap second at the end of June or
    December, which is obviously wrong.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast