Re: questions Digest, Vol 29, Issue 78 - NTP

This is a discussion on Re: questions Digest, Vol 29, Issue 78 - NTP ; >>>>>>>>>>>>>>>>>>> Message: 8 Date: Tue, 27 Mar 2007 23:38:12 +0000 (UTC) From: per@hedeland.org (Per Hedeland) Subject: Re: ntpd sets clock to the year 1939 To: questions@lists.ntp.isc.org Message-ID: In article GDowd@symmetricom.com (Greg Dowd) writes: > >The problem is not so much ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: questions Digest, Vol 29, Issue 78

  1. Re: questions Digest, Vol 29, Issue 78

    >>>>>>>>>>>>>>>>>>>
    Message: 8
    Date: Tue, 27 Mar 2007 23:38:12 +0000 (UTC)
    From: per@hedeland.org (Per Hedeland)
    Subject: Re: ntpd sets clock to the year 1939
    To: questions@lists.ntp.isc.org
    Message-ID:

    In article
    <4B73D9EBE2327E40B4D69822D7C45802068D0880@sjmail1.s ymmetricom.com>
    GDowd@symmetricom.com (Greg Dowd) writes:
    >
    >The problem is not so much that NTP has a limitation on bits and an
    >overflow condition. This is always the case. Dave was able to modify
    >the code slightly, by switching to a double earlier, and change the
    >window from 34 years to 68 years. This allowed him to keep that least
    >significant bit included in the calculation.


    I agree with this basic principle (and the rest of what you wrote), but
    I believe that your numbers are off by a factor of two. NTP timestamps
    use a 32-bit unsigned quantity for the seconds, with the base year 1900
    - this means that the window should be 136 years, and that any point in
    time in the range ~ 1900..2036 can be unambiguously represented. I
    believe that the fix was to change the effective window from 68 years
    (due to what must be considered a bug) to the "proper" 136 years. And I
    wonder if this fix is in the version the OP used (not mentioned as far
    as I can see).

    Assuming a window of 68 years (for whatever reason), timestamps in the
    ranges 1900..1968 and 1968..2036 can not be distinguished from each
    other, and some assumption has to be made if the current year is 1970
    and the time stamp supposedly representing "correct" time can be
    interpreted as either 1939 or 2007 - 1939 is definitely closer, and thus
    a reasonable choice absent other "additional logic" (such as time of
    compilation of the binary that has been mentioned - or in this case even
    a hardwired constant in the code). Or put another way, ntpd assumes a
    window that is symmetric around the current system time.

    OK, I had to test it myself, especially after having been chastised by
    Steve in the orphan thread.:-) With ntpd 4.2.0-a (what ships with
    FreeBSD 5.4), I saw exactly the same behaviour as the OP - I set the
    date to 1970, and ntpd -g hapily set it back to 1939. However ntpd
    4.2.4p0 did the right thing:

    Jan 1 00:00:26 pelle ntpd[21059]: ntpd 4.2.4p0@1.1472-o Tue Mar 27
    22:43:41 UTC
    2007 (1)
    Mar 28 00:45:25 pelle ntpd[21060]: time reset +1175039090.075990 s

    - and in fact it continues to do the right thing if the original date is
    as far back as 1940 (too bad my syslogd doesn't show the year:-):

    Jan 1 00:00:09 pelle ntpd[21110]: ntpd 4.2.4p0@1.1472-o Tue Mar 27
    22:43:41 UTC
    2007 (1)
    Mar 28 00:54:34 pelle ntpd[21111]: time reset +2121810856.014114 s

    - whereas with the original date in 1938, the 136-year window comes into
    play, and it decides to interpret the received timestamp as 1871 (67
    years off) rather than 2007 (69 years off):

    Jan 1 00:00:07 pelle ntpd[21102]: ntpd 4.2.4p0@1.1472-o Tue Mar 27
    22:43:41 UTC
    2007 (1)
    Mar 28 00:52:17 pelle ntpd[21103]: time reset -2110084575.114568 s

    - however at this point the Unix internal time representation comes into
    play, and we end up at 2007 despite ntpd's efforts to the contrary.:-)

    And just to hopefully dispel some myths about *that*, i.e. Unix/POSIX
    time representation: First of all it really has nothing to do with NTP
    timestamps, but obviously ntpd needs to convert between the two. And it
    (currently) uses a 32-bit *signed* quantity for the seconds, with the
    value 0 in Jan 1970. This means that it too has a 136-year window, and a
    range of ~ 1902..2038 - i.e. it doesn't "start" in 1970. There is
    (currently) no issue with deciding what time a given value represents
    though - the window is locked down to that single range.

    I.e. bottom line to the OP: Upgrade ntpd and you should be fine until
    2038. But at that point you will have to do something unless "additional
    logic" has been put into ntpd - Unix time will likely be a 64-bit signed
    quantity by then, but still with 0 in 1970...

    --Per Hedeland
    per@hedeland.org

    >>>>>>>>>>>>>>>>>>>>


    That's cool that you tested this. Guess I better do the same :-) I
    sometimes wish Dave had a larger ego and would opine about the great
    stuff that he adds into the codebase. I assume some radixing code has
    been added to systime? In any case, the original problem was a 34 year
    problem as the difference of 2 timestamps is a signed value (68 years).
    Back then, IIRC, the code was adding the results of the two first
    differences (t3-t2) and (t1-t0) BEFORE dividing by 2. Hence, 34 years.


    Greg Dowd
    gdowd at symmetricom dot com (antispam format)
    Symmetricom, Inc.
    www.symmetricom.com
    "The current implementation is non-obvious and may need to be improved."



    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: ntpd sets clock to the year 1939 (Was: Re: questions Digest, Vol 29, Issue 78)

    In article
    <4B73D9EBE2327E40B4D69822D7C45802068D0886@sjmail1.s ymmetricom.com>
    GDowd@symmetricom.com (Greg Dowd) writes:
    >
    >That's cool that you tested this. Guess I better do the same :-) I
    >sometimes wish Dave had a larger ego and would opine about the great
    >stuff that he adds into the codebase. I assume some radixing code has
    >been added to systime? In any case, the original problem was a 34 year
    >problem as the difference of 2 timestamps is a signed value (68 years).


    The difference can range from -68 to +68 years - sounds like 136 years
    to me. But maybe we're just quibbling about terminology - while I
    believe this means that the window is 136 years, the more interesting
    thing is perhaps that given a window symmetric around current system
    time (as ntpd currently uses), the actual time can't be determined
    correctly if it is more than 68 years off (and correspondingly for 68
    and 34, of course) - as demonstrated by my test with current code.

    >Back then, IIRC, the code was adding the results of the two first
    >differences (t3-t2) and (t1-t0) BEFORE dividing by 2. Hence, 34 years.


    Ah, this is likely the (only) fix that happened at some point between
    4.2.0 and 4.2.4p0.

    --Per Hedeland
    per@hedeland.org

+ Reply to Thread