|
> 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: > > DESCRIPTION > 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, GD Hotmail® is up to 70% faster. Now good news travels really fast. Find out more. |