Re: Failed to hand off onionskin

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Sat, 20 Dec 2008 21:56:09 +0100 Mitar <mmitar@xxxxxxxxx> wrote:
>On Sat, Dec 20, 2008 at 10:05 AM, Scott Bennett <bennett@xxxxxxxxxx> wrote:
>> Increasing the queue limit to a high enough value means that none will be
>> lost, even if it takes a bit longer for your CPUs to get caught up.
>
>This is what I was thinking with "smoothing out". But delay is longer
>then (for some).

     Ah.  Okay.  As long as the delays don't frequently reach the level that
circuit-building times out, it shouldn't be a problem.
>
>> Note that you do not have to shut down your relay in order to make this change.
>> Just edit torrc, resave it, and send tor a SIGHUP.
>
>I know that. I was playing with this when I was trying to dynamically
>deny exit for Bittorrent connections. The problem was only that Tor
>does not support such complex (and big) exit configurations.
>
>> It isn't routing of onionskins.  It is decrypting of onionskins.
>
>It has to decrypt onionskin to get destination of the next hop (and of
>course payload to send there). So if it takes long to decrypt it, then
>it also takes long to route it forward.
>
>(Or is route static and only payload is decrypted in layers? I do not
>know so much of Tor internals.)

     AFAIK and from one of Roger's responses to me many moons ago, the
onionskin processing occurs only when extending a circuit.  That is why
most relay operators never see the message you got, even though their
relays run with the default value of 100.  Because your relay advertised
such a high capacity, it got many such operations per second, apparently
with onionskins queued for decryption peaking at over 100.
>
>> [pet-peeve rant on]
>> How about if people stop misusing the term "bandwidth" for data
>> transmission rates and capacities, which have nothing at all to do with
>> the {wavelength,wavenumber,frequency,period} bandwidths?  Slang popularity
>> is not justification for misuse of technical terminology.
>> [pet-peeve rant off]
>
>It has to do with a physical layer of a transmission. More bandwidth
>used as a carrier signal more data it can carry.

     Um...that's a bit garbled, I think.  At the physical layer, which is
really the only place the term is truly applicable, bandwidth refers to the
degree of frequency spreading of a channel.  If the frequency bands (channels)
in use are too close together in the frequency spectrum, the bands overlap.
If the degree of overlap is too great, then the various channels's signals
cannot be distinctly resolved.  This is why government agencies that license
parts of the broadcast spectrum to radio, TV, and other types of stations
must assign only frequencies that are adequately spectrally separated within
a given reception area.  Better technology over the decades has made it
possible both to reduce the spreading and to improve sampling rates, which
have led to much greater packing of channels into the frequency spectrum
in the broadcast media and in material devices like computer cables, TV
transmission cables, etc.  For example, several decades ago, a good comm
radio for aircraft had only 120 channels, but now the same spectrum covers
720 channels.  The numbers today would likely be far higher were it not for
the obstructionist policies of the FAA and FCC in the U.S. because the
technology has been available for seeming ages already.
     In any case, bandwidth has nothing to do with the data transmission
capacity of a particular channel and nothing to do with tor.

>But mostly: I am just using terminology from Tor man pages.

     Yes.  It's slang and not really appropriate for technical material
about tor, including torrc.
>
>> As for having one core running at 85% - 100% CPU-bound, a good rule
>> of thumb is that a processor on a production system that averages higher
>> than 70% CPU-bound is due for an upgrade.
>
>With other cores idling? I would rather try to improve parallelism in
>used programs.

     Well, then, OpenSSL has been identified on this list as a target of
opportunity.  You're welcome to have at it. :-)  Alternatively, you might
choose to run a separate copy of tor on each core, I suppose, but remember
to add the "MyFAmily" line to each of the torrc files.  If you have 100 Mb/s
connection to the outside world, you could probably tie it up fairly solidly
by running two or three tor processes.
>
>But of course. Someone can always donate the newest multi-core CPU to
>me and I will gladly install it into a system. :-)
>
     Ah, yes, with the state of affairs in the world today, an optimist
must surely be needed (somewhere:).


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