On Tue, 27 Mar 2007 11:04:02 -0400, "Richard B. gilbert" <[EMAIL PROTECTED]> wrote:
>Marc Brett wrote: >> On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert" >> <[EMAIL PROTECTED]> wrote: >>>Robert Dodier wrote: >>>>On Mar 26, 12:50 pm, "Richard B. gilbert" <[EMAIL PROTECTED]> >>>>wrote: >>>>>I believe that there is a limit to the date/time range that ntpd can >>>>>handle and that it's something like 36 years. Try setting the date >>>>>manually to something a little closer to being current. If it's off by >>>>>less than 36 years, I think ntpd will handle it correctly. A startup >>>>>script that set the date to a reasonable approximation; e.g. 2007 would >>>>>probably solve your problem and work for the next 36 years or so. >>>> >>>>Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd >>>>was >>>>able to handle the rest. It seems odd to me that ntpd gets confused by >>>>too large a time difference, but oh well, it's OK the way it is. >>> >>>It's hardly ever a problem since most systems have a hardware clock of >>>some sort that can supply a reasonable starting point. In 2007, I don't >>>think that 1970-is a reasonable starting point. >> >> "Be liberal in what you accept, conservative in what you send." >> >> We may not think that 1970 is a reasonable starting point, but these systems >> exist today and ntpd should deal gracefully with them. In fact, a POSIX >> time of >> 0 is not exactly an unreasonable starting date for a system with no hardware >> clock and no DHCP-specified NTP server. >> >> It's unfortunate that applications (especially an application dedicated to >> keeping the correct time, fer cryin out loud) fall over when faced with such >> a >> time value, but whose fault is that? > >The opposite argument would be that it's not reasonable for ntpd to make >a "leap of faith" and jump the time by 36 years! But 26 years, say, is perfectly reasonable? >Ntpd is designed to >consider a clock that's off by 1024 seconds or more as a situation it is >not equipped to handle. Ntpd is behaving as it's designed and >documented to behave. But it isn't. The "ntpd -g" documentation says: -g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. "Without restriction" means, to me, that time jumps of 26 years, 36 years, or 46 years are all perfectly fine. >The source is available and anyone with the necessary skills can modify >it to handle special cases like this. Anyone lacking the necessary >skills can pay someone with the skills to do the work. Maybe the gumstix folk can be persuaded... _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
