Re: odd clock jump messages from 0.2.0.21-rc

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Mon, 17 Mar 2008 00:12:06 -0400 Roger Dingledine <arma@xxxxxxx>
wrote:
>On Sun, Mar 16, 2008 at 01:27:38AM -0500, Scott Bennett wrote:
>>      Something weird seems to be happening several times a day since
>> I installed 0.2.0.21-rc.  The tor traffic drops to nothing suddenly
>> and a message is logged claiming that the system clock has jumped
>> forward some number of seconds and that all circuits are assumed to
>> be unusable.  (That assumption seems to me unwarranted for relatively
>> short jumps of the system clock, but that's a separate issue.)  In any
>> case, I haven't spotted any other evidence in my system that the clock
>> has indeed suddenly jumped forward.  Only tor is claiming that it has.
>[snip]
>> Mar 15 14:05:55.095 [warn] Your system clock just jumped 111 seconds forward; assuming established circuits no longer work.
>[snip]
>>      I don't recall seeing these messages prior to 0.2.0.21-rc unless I did
>> something that would change the system clock.  What has changed that could
>> possibly be affecting tor's mechanism for determining whether it has been
>> unexpectedly dormant?
>
>See also the previous thread on this topic:
>http://archives.seul.org/or/talk/Feb-2008/msg00285.html
>

     Interesting.  Such problems crop up frequently with VM systems, but
mine is running native.

>In this case, Lucky found the problem was that he was running with
>multiple CPUs, and vmware kept track of time differently on each CPU
>(different meaning they were several hours apart from each other). So

     Several *hours*??  Yikes.  That's extreme.
     Is there some reason that tor assumes connections have died after
short clock jumps, rather than trying them to see whether they still work?
In fact, I'm not really clear why tor should assume that a clock jump
implies broken connections at all.  I can see that if one is running it
on a portable and puts it into standby mode, then the clock jump may be
a clue afterward that a suspension did occur, which probably means the
connections are dead.  But in any other circumstances, clock jumps would
seem to imply nothing at all about the status of connections.  Surely,
a test cell sent on each connection ought to reveal the current situation
without breaking active circuits when nothing is really wrong with them.

>when Tor moved from one CPU to the other, its time changed wildly.
>
>It sounds like that's not what's happening here. But are you on more than
>one cpu (or more than one 'core', now that we're in the 21st century)?

     No, but it's a hyperthreading CPU, and I've set the sysctl variable
to allow hyperthreading to be used by FreeBSD, so two logical CPUs are
in use.  NumCPUs 2 is set in torrc.  There is usually a clock interrupt
on each CPU every millisecond or so.  cron runs ntpdate once an hour, which
does not correspond to the messages logged by tor, so I doubt that that
could be what's causing them.  ntpdate only causes clock jumps when the
network time differs by more than 500 ms from the system time.  Otherwise
it uses adjtime(2), whose effects should not be detectable by tor or other
problem programs.
>
>I've also heard from some FreeBSD users who had problems with the clock
>jump warnings, and once they upgraded their kernel sufficiently the
>complaints went away. I don't think you mentioned what OS you're using,
>but it looks like you're using FreeBSD too?

     It's FreeBSD 6.3-STABLE, so it's up to date for the 6.x releases.
I'm not convinced that I want to deal with 7.0's problems in order to get
its benefits, so I'll likely wait for 7.1-RELEASE (several months from now
at least) before moving on.  (7.0 is being extolled as the only OS currently
available to do efficient scheduling of loads across more than eight CPUs,
as well as many other improvements and new features.)
>
>The other option is that you're massively swapping and Tor really is
>getting starved for hundreds of seconds at a time. But I'm guessing
>that's not it.
>
     No, it's a 1 GB machine and rarely ever puts anything into the swap
area.  A few days ago, I finally attempted the upgrade from X.org 6.9 to
7.3, which involved a huge amount of processing.  During that time, the
swap area usage peaked at about 80 MB, the highest by far I can recall ever
seeing in FreeBSD.  (Windows XP is another matter, of course, and can glibly
take 500-600 MB or occasionally more, but I only run tor as a client when
using Windows these days.)


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************