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

Re: Failed to hand off onionskin



     On Wed, 17 Dec 2008 02:00:46 +0100 Mitar <mmitar@xxxxxxxxx> wrote:
>On Wed, Dec 17, 2008 at 12:44 AM, Roger Dingledine <arma@xxxxxxx> wrote:
>> Well, step one is to set
>> NumCPUs 2
>> but I think you already did that.
>
>Yes. That was something I tried first. But it did not change those
>warnings much (I have not really measured or counted them but I
>believe that there is the same amount of them in a day with one or two
>processors enabled).
>
>The only time I really see increase in CPU % (in top output on
>FreeBSD) is when I send HUP signal - then it gets much over 100 % for
>a few seconds.

     Several things happen when tor catches a SIGHUP that can eat CPU time
for a bit, including checking to see whether anything has changed that
would require publishing a new descriptor (e.g., checking to see if the
ExitPolicy specifications have changed) and building a new set of circuits.
>
>> Assuming you're referring to the relay "Arlequin", this is a very fast
>> relay, so you will be running up against various constraints that not
>> many people hit.
>
>Yes. But the system really does not seem busy.

     Most of tor's work seems to be done by a single thread, although one
can see occasional CPU usage by others.  Onionskin decrypting is handled
by NumCPUs threads.
>
>> How much ram is Tor using? If it's a lot, you might consider the -alpha
>> versions, as on some platforms they use much less ram.
>
>top reports 369M of total memory footprint. It has 3 threads. There
>are around 14000 TCP connections established (I can count this as the
>system has a dedicated IP address for Tor traffic).

     That is odd.  In my experience, tor has 4 + NumCPUs threads, except
right after a SIGHUP or during initialization.  I normally only see two
threads do any work, and most of it is done by one of those two.  Although
I run it on a P4 Prescott, it is HT-enabled, so I set NumCPUs 2.  Most
likely, the onionskin-decoding threads are used so infrequently that I only
see one in use at a time anyway.
>
>Could it be a memory use bound? So that memory access cannot keep with
>the use? And this is why the CPU is not maxed?
>
     Are you seeing any significant paging activity on that system?  If not,
then I doubt that is the problem.  Even small amounts of paging activity
are not likely a problem.  Is that machine dedicated to tor?  Or is it also
running other jobs with large (relative to the real memory of the machine)
memory requirements?


                                  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         *
**********************************************************************