Clock problems

[downie -]

> Date: Sun, 8 Mar 2009 19:56:57 -0700
> Subject: Re: Clock problems
> From: coderman at gmail.com
> To: or-talk at freehaven.net
> 
> On Sun, Mar 8, 2009 at 6:16 PM, downie - <downgeoff2 at hotmail.com> 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. 
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20090308/fc0c5c18/attachment.htm>