Lep seconds - NTP

This is a discussion on Lep seconds - NTP ; Unruh - thanks for responding. You are the only one who did. I certainly did not mean to disparage NTP time. I have spec'ed that it be used on our system. Where I run into problems is when a leap ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Lep seconds

  1. Lep seconds


    Unruh - thanks for responding. You are the only one
    who did.

    I certainly did not mean to disparage NTP time. I
    have spec'ed that it be used on our system. Where I
    run into problems is when a leap second occurs.
    According to everything I've read when NTP signals
    the operating system that the second is occurring it
    also outputs time. It uses the POSIX standard method
    - duplicate a second (or in some cases stretch the
    last second). This causes confusion when a time
    sample is taken before the leap second and one during
    the leap second. The UTC standard (which only
    addresses ascii time representations) actually counts
    the second 0..60 rather than 0..59.

    At this point I am obligated to use UTC and NTP.

    Tht missing second is causing me to get a lot of heat.
    Does anyone know of a way to get NTP to count the
    leap second rather than to delete it? Or am I missing
    the point.


    >I don't want to step on anyones toes but I am getting
    >a lot of heat over using a POSIX compliant ntp re

    leap
    >seconds. The 1 second error inserted can cause a lot
    >of trouble.


    Exactly what heat are you getting and what trouble is
    it causing you?
    Perhaps if you tell us the problem rather than your
    solution, we could come
    up with a solution.


    >I now that the Olsen mod changes most Unix/Linux time
    >processing to handle the leap second in a
    >theoretically correct manner rather than being POSIX


    I have no idea what "a theoretically correct manner "
    is. The Posix IS a
    theoretically correct manner.

    >compliant. Is there a similar mod for NTP. I am
    >hoping that there is a mod that will cause NTP to
    >supply theoretical UTC (even if it is not ascci).


    NTP DOES supply both theoretical and practical UTC.

    I think what you are worried about is that you want
    your system to provide
    something like TIA-- Atomic time-- which has no leap
    seconds. I believe the
    Olsen mods have your system clock run on atomic time
    and then use the
    leapsecond file and the zoneinfo file for your region
    to translate that to
    your local time.

    You could just set up ntp to add 33 sec to its time,
    and you would have
    atomic time.




    > Mark


  2. Re: Lep seconds

    Mark,

    Mark Newman wrote:
    > Unruh - thanks for responding. You are the only one
    > who did.
    >
    > I certainly did not mean to disparage NTP time. I
    > have spec'ed that it be used on our system. Where I
    > run into problems is when a leap second occurs.
    > According to everything I've read when NTP signals
    > the operating system that the second is occurring it
    > also outputs time. It uses the POSIX standard method
    > - duplicate a second (or in some cases stretch the
    > last second). This causes confusion when a time
    > sample is taken before the leap second and one during
    > the leap second. The UTC standard (which only
    > addresses ascii time representations) actually counts
    > the second 0..60 rather than 0..59.


    If you "normalize" the time with second 60 then you see there _is_ a
    duplicate time stamp. This is because a leap second _is_ a inconsistency of
    time.

    > At this point I am obligated to use UTC and NTP.


    On most Unix-like kernels NTP just passes a leap second announcement to the
    OS kernel, and the kernel handles the leap second in the way it is
    implemented in the kernel. For details, please see
    http://www.meinberg.de/english/info/leap-second.htm

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: Lep seconds

    Mark,

    Details on how leapseconds are handled are in the NTP leapseconds
    executive summary on the NTP Project Page linked from www.ntp.org. The
    return code from ntp-gettime() reveals when a leap second is or is not
    in progress. In the intended model, ctime or equivalant should notice
    this an map 0 to 60 for the second second. At the end of this second the
    ASCII seconds number will resume from 0. So far as I know, nobody has
    ever implemented that.

    Dave

    Mark Newman wrote:

    > Unruh - thanks for responding. You are the only one
    > who did.
    >
    > I certainly did not mean to disparage NTP time. I
    > have spec'ed that it be used on our system. Where I
    > run into problems is when a leap second occurs.
    > According to everything I've read when NTP signals
    > the operating system that the second is occurring it
    > also outputs time. It uses the POSIX standard method
    > - duplicate a second (or in some cases stretch the
    > last second). This causes confusion when a time
    > sample is taken before the leap second and one during
    > the leap second. The UTC standard (which only
    > addresses ascii time representations) actually counts
    > the second 0..60 rather than 0..59.
    >
    > At this point I am obligated to use UTC and NTP.
    >
    > Tht missing second is causing me to get a lot of heat.
    > Does anyone know of a way to get NTP to count the
    > leap second rather than to delete it? Or am I missing
    > the point.
    >
    >
    >
    >>I don't want to step on anyones toes but I am getting
    >>a lot of heat over using a POSIX compliant ntp re

    >
    > leap
    >
    >>seconds. The 1 second error inserted can cause a lot
    >>of trouble.

    >
    >
    > Exactly what heat are you getting and what trouble is
    > it causing you?
    > Perhaps if you tell us the problem rather than your
    > solution, we could come
    > up with a solution.
    >
    >
    >
    >>I now that the Olsen mod changes most Unix/Linux time
    >>processing to handle the leap second in a
    >>theoretically correct manner rather than being POSIX

    >
    >
    > I have no idea what "a theoretically correct manner "
    > is. The Posix IS a
    > theoretically correct manner.
    >
    >
    >>compliant. Is there a similar mod for NTP. I am
    >>hoping that there is a mod that will cause NTP to
    >>supply theoretical UTC (even if it is not ascci).

    >
    >
    > NTP DOES supply both theoretical and practical UTC.
    >
    > I think what you are worried about is that you want
    > your system to provide
    > something like TIA-- Atomic time-- which has no leap
    > seconds. I believe the
    > Olsen mods have your system clock run on atomic time
    > and then use the
    > leapsecond file and the zoneinfo file for your region
    > to translate that to
    > your local time.
    >
    > You could just set up ntp to add 33 sec to its time,
    > and you would have
    > atomic time.
    >
    >
    >
    >
    >
    >> Mark


  4. Re: Lep seconds

    Martin,

    In the current development code when the kernel does not implement a
    leap function, the clock is stepped "near" the leap epoch. Here, "near
    means within one second early or late and yes, this can be considered
    pinball behavior. This should probably be an option.

    Dave

    Martin Burnicki wrote:

    > Mark,
    >
    > Mark Newman wrote:
    >
    >>Unruh - thanks for responding. You are the only one
    >>who did.
    >>
    >>I certainly did not mean to disparage NTP time. I
    >>have spec'ed that it be used on our system. Where I
    >>run into problems is when a leap second occurs.
    >>According to everything I've read when NTP signals
    >>the operating system that the second is occurring it
    >>also outputs time. It uses the POSIX standard method
    >>- duplicate a second (or in some cases stretch the
    >>last second). This causes confusion when a time
    >>sample is taken before the leap second and one during
    >>the leap second. The UTC standard (which only
    >>addresses ascii time representations) actually counts
    >>the second 0..60 rather than 0..59.

    >
    >
    > If you "normalize" the time with second 60 then you see there _is_ a
    > duplicate time stamp. This is because a leap second _is_ a inconsistency of
    > time.
    >
    >
    >>At this point I am obligated to use UTC and NTP.

    >
    >
    > On most Unix-like kernels NTP just passes a leap second announcement to the
    > OS kernel, and the kernel handles the leap second in the way it is
    > implemented in the kernel. For details, please see
    > http://www.meinberg.de/english/info/leap-second.htm
    >
    > Martin


  5. Re: Lep seconds

    markn_46@yahoo.com (Mark Newman) writes:


    >Unruh - thanks for responding. You are the only one
    >who did.


    >I certainly did not mean to disparage NTP time. I
    >have spec'ed that it be used on our system. Where I
    >run into problems is when a leap second occurs.


    Since no leap seconds have occured in the past 2 years, and before that for
    7 years, I doubt that you
    have every seen a problem when a leap second occurs.

    >According to everything I've read when NTP signals
    >the operating system that the second is occurring it
    >also outputs time. It uses the POSIX standard method


    ?? I have no idea what that phrase "outputs time" means.

    >- duplicate a second (or in some cases stretch the
    >last second). This causes confusion when a time
    >sample is taken before the leap second and one during
    >the leap second. The UTC standard (which only
    >addresses ascii time representations) actually counts
    >the second 0..60 rather than 0..59.


    Yes. And since that one second occurs about once every 2-3 years, on Dec 31
    or June 30, who cares. Again what is your problem that you are trying to
    fix?


    >At this point I am obligated to use UTC and NTP.


    >Tht missing second is causing me to get a lot of heat.


    From whom? There is no missing second. Noone has seen a leap second in
    quite a while. Who is giving you the heat? And if they do, explain to them
    how UTC works.


    > Does anyone know of a way to get NTP to count the
    >leap second rather than to delete it? Or am I missing
    >the point.


    ???? I have no idea what you mean. Most leap seconds add a second to the
    year-- Just as leap years add a day ( or do you also have trouble with leap
    years, and want us to go on lunar time, which does not have them.)




    >>I don't want to step on anyones toes but I am getting
    >>a lot of heat over using a POSIX compliant ntp re

    >leap
    >>seconds. The 1 second error inserted can cause a lot
    >>of trouble.


    Again, heat from whom? You have never told us what problem you are trying
    to solve.



    >Exactly what heat are you getting and what trouble is
    >it causing you?
    >Perhaps if you tell us the problem rather than your
    >solution, we could come
    >up with a solution.



    >>I now that the Olsen mod changes most Unix/Linux time
    >>processing to handle the leap second in a
    >>theoretically correct manner rather than being POSIX


    >I have no idea what "a theoretically correct manner "
    >is. The Posix IS a
    >theoretically correct manner.


    >>compliant. Is there a similar mod for NTP. I am
    >>hoping that there is a mod that will cause NTP to
    >>supply theoretical UTC (even if it is not ascci).


    >NTP DOES supply both theoretical and practical UTC.


    >I think what you are worried about is that you want
    >your system to provide
    >something like TIA-- Atomic time-- which has no leap
    >seconds. I believe the
    >Olsen mods have your system clock run on atomic time
    >and then use the
    >leapsecond file and the zoneinfo file for your region
    >to translate that to
    >your local time.


    >You could just set up ntp to add 33 sec to its time,
    >and you would have
    >atomic time.





    >> Mark


  6. Re: Lep seconds

    Martin Burnicki writes:

    >Mark,


    >Mark Newman wrote:
    >> Unruh - thanks for responding. You are the only one
    >> who did.
    >>
    >> I certainly did not mean to disparage NTP time. I
    >> have spec'ed that it be used on our system. Where I
    >> run into problems is when a leap second occurs.
    >> According to everything I've read when NTP signals
    >> the operating system that the second is occurring it
    >> also outputs time. It uses the POSIX standard method
    >> - duplicate a second (or in some cases stretch the
    >> last second). This causes confusion when a time
    >> sample is taken before the leap second and one during
    >> the leap second. The UTC standard (which only
    >> addresses ascii time representations) actually counts
    >> the second 0..60 rather than 0..59.


    >If you "normalize" the time with second 60 then you see there _is_ a
    >duplicate time stamp. This is because a leap second _is_ a inconsistency of
    >time.


    No there is not. Just like a leap year is not an inconsistancy of time.
    It is not inconsistant to add a leap second. It may be a pain for some
    purposes (eg if you are an astronomer), but then so areleap years, and I
    do not hear for a great push that we go onto say lunar time, for which each
    year is exactly the same.

    >
    >> At this point I am obligated to use UTC and NTP.


    >On most Unix-like kernels NTP just passes a leap second announcement to the
    >OS kernel, and the kernel handles the leap second in the way it is
    >implemented in the kernel. For details, please see
    >http://www.meinberg.de/english/info/leap-second.htm


  7. Re: Lep seconds

    Dave,

    David L. Mills wrote:
    > Martin,
    >
    > In the current development code when the kernel does not implement a
    > leap function, the clock is stepped "near" the leap epoch. Here, "near
    > means within one second early or late and yes, this can be considered
    > pinball behavior. This should probably be an option.


    I've already seen that change, and I'm going to do some tests with the new
    function.

    Shortly before the latest leap second I had added some code to handle the
    leap second correctly under Windows. This is in the Windows-only portion of
    the code and I'm afraid this interferes now with your latest changes.

    BTW, as already mentioned in one of my other posts: wouldn't it be a good
    idea to generate a log entry which tells from which upstream source a leap
    second announcement has been received?

    We have seen several times in the past that ntpd thought it had to introduce
    a leap second because some bad guy had passed a faulty leap second
    announcement. Knowing the source of the announcement would help to identify
    the original source of the announcement.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  8. Re: Lep seconds

    Martin,

    I'm a little anxious about the non-kernel step. My original kernel code
    for the Alpha carefully crafted monotonicity. In particular, the clock
    would not be stepped back unless more than two seconds. This was done
    purposely so that a leap back of only one second would simply stop the
    clock or allow it to creep forward on nanosecond per call until the
    second was amortized. I doubt very much that this design is universal.

    Martin Burnicki wrote:

    > Dave,
    >
    > David L. Mills wrote:
    >
    >>Martin,
    >>
    >>In the current development code when the kernel does not implement a
    >>leap function, the clock is stepped "near" the leap epoch. Here, "near
    >>means within one second early or late and yes, this can be considered
    >>pinball behavior. This should probably be an option.

    >
    >
    > I've already seen that change, and I'm going to do some tests with the new
    > function.
    >
    > Shortly before the latest leap second I had added some code to handle the
    > leap second correctly under Windows. This is in the Windows-only portion of
    > the code and I'm afraid this interferes now with your latest changes.
    >
    > BTW, as already mentioned in one of my other posts: wouldn't it be a good
    > idea to generate a log entry which tells from which upstream source a leap
    > second announcement has been received?
    >
    > We have seen several times in the past that ntpd thought it had to introduce
    > a leap second because some bad guy had passed a faulty leap second
    > announcement. Knowing the source of the announcement would help to identify
    > the original source of the announcement.
    >
    > Martin


+ Reply to Thread