[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Failed to hand off onionskin
- To: "Scott Bennett" <bennett@xxxxxxxxxx>
- Subject: Re: Failed to hand off onionskin
- From: Mitar <mmitar@xxxxxxxxx>
- Date: Sat, 20 Dec 2008 21:56:09 +0100
- Cc: or-talk@xxxxxxxxxxxxx
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Sat, 20 Dec 2008 15:56:19 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2cZVpv3ADSzHlKSHFdByxEE5U0u/C8gKgT2ZTpaa5pc=; b=I65HDmXR+SFH0xBlZzS/UL3HBb0gc8lYYZ2EjqBVPxEOcuQFI5UejVjyl/YuTwStMq T5oSjjzEWg3k/3T2AjEukNQTv8I8b/PENBp6QK7Ebva2dPL8qIB88uFngtIuk3QvZW2k mVvhVbCTyiFLyucFgPX492jvrDDvPo44VcWMU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aQpAFBlLBFN3X9o8JLID133LHHUsUl1bfRZfBDRacUqzTm1YNEtWfQE2KtsnLOaHEI KZC/G4M/6kTErmdddsOeKQ8SdpUp3EAthTdQ3qMP6hAD0lGYyu3BjleMpah2uR6RmrDD kDZsR7/3/aPJFHn75QFZLe9JFd/5+vHXXjCA8=
- In-reply-to: <200812200905.mBK95jwJ028676@xxxxxxxxxxxxx>
- References: <200812200905.mBK95jwJ028676@xxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
Hi!
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).
> 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.)
> [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.
But mostly: I am just using terminology from Tor man pages.
> 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.
But of course. Someone can always donate the newest multi-core CPU to
me and I will gladly install it into a system. :-)
Mitar