On Wed, Sep 03, 2003 at 08:59:27AM -0700, Randal L. Schwartz wrote:
> >>>>> "Sungo" == Sungo <[EMAIL PROTECTED]> writes:
>
> Sungo> Rocco Caputo wrote:
> >> I have heard conflicting stories about whether the time shift is
> >> significant. Jeff Bisbee posted that systems based on UTC don't see
> >> shifts in time() when DST/Standard arrive. Matt Cashner is convinced
> >> that NTP prevents the problem from occurring.
>
> Sungo> the combination of those two ideas pretty much guarantee a time shift
> Sungo> less system on a well maintained box. ntp will keep the system time
> Sungo> from drifting more than a few attoseconds from standard. and utc
> Sungo> doesn't change. the epoch time where $ENV{TZ} is set to UTC, GMT or
> Sungo> one of the other synonyms will see no time shift around the daylight
> Sungo> saving time jumps.
>
> Well, NTP generally uses adjtime(2) to get the time in sync, but
> occasionally must catastrophically use settimeofday(2), which makes a
> discontinuous jump. Consider a box that has gone off the net for a
> day, drifting the local clock a minute or two badly, and suddenly
> reconnects.
>
> At least, that's my understanding.
>
Needles to say the progress of time is an important issue in unix,
and I hope in other operating systems. Ntpd goes out of it's way
to ensure that time moves forward at a steady and predictable rate.
It will even commit suicide before causing a unrequested time
discontinuity of more than 128ms. Both the standards and the
documentation for ntpd are quite clear on this issue.
An administrator or an os vendor has to go out of their way to make
ntpd break from this default behavior.
If I understand Rocco Caputo's posting he believes that the solution
to the signal delivery problem is to solve the signal delivery
problem rather than to fiddle with the scheduler.
For what little my opinion matters, I agree with him.
--
This space intentionally left blank
