>>>>>>>>>>>>>>>>>>> Message: 8 Date: Tue, 27 Mar 2007 23:38:12 +0000 (UTC) From: [EMAIL PROTECTED] (Per Hedeland) Subject: Re: [ntp:questions] ntpd sets clock to the year 1939 To: [email protected] Message-ID: <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] >>>>>>>>>>>>>>>>>>>> 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 [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
