[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

RE: Clock problems

> Date: Sun, 8 Mar 2009 19:56:57 -0700
> Subject: Re: Clock problems
> From: coderman@xxxxxxxxx
> To: or-talk@xxxxxxxxxxxxx
> On Sun, Mar 8, 2009 at 6:16 PM, downie - <downgeoff2@xxxxxxxxxxx> wrote:
> >...
> > "[warn] Your system clock just jumped 160 seconds forward; assuming
> > established circuits no longer work."
> > There are big blocks of these errors occuring 3 minutes 40 seconds or so
> > apart, for 3 hours.
> > The reported clock jump is always 150-170 seconds, and always forwards.
> ...
> this sounds like the expected behavior of ntpd issuing adjtime() calls
> to slowly bring your clock skew down to current time. this can take
> hours depending on how large of an adjustment is needed.
> is the computer off for a longer period of time than usual when such
> behavior occurs?

It had been on for a couple of days before the latest rash of warnings, and Tor had been running for just over an hour after a daily shutdown of an hour.
 A few days ago I had some overnight broadband outages.
FWIW the clock synchronises to Apple's server, I'm not sure how often, and I haven't had any warnings about being out of sync.

> from OSX adjtime man page:
> Adjtime() makes small adjustments to the system time, as returned by
> gettimeofday(2), advancing or retarding it by the time specified by
> the timeval delta. If delta is negative, the clock is slowed down by
> incrementing it more slowly than normal until the correction is
> complete. If delta is positive, a larger increment than normal is
> used. The skew used to perform the correction is generally a fraction
> of one percent. Thus, the time is always a monotonically increasing
> function...

Hmm, I'll have to take that on trust - I have no manpages for adjtime or gettimeofday.
Those commands aren't recognised.

 also, ntpd / ntpdate may also perform similar incremental adjustment themselves:
> """
> [ntpd|ntpdate may] step the time using settimeofday(2) if the offset
> is greater than +-128 ms. Note that, if the offset is much greater
> than +-128 ms in this case, it can take a long time (hours) to slew
> the clock to the correct value. During this time, the host should not
> be used to synchronize clients.
> """
> best regards,

Thank you,

Hotmail® is up to 70% faster. Now good news travels really fast. Find out more.