[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: performance tuning...
While this isn't necessarily a fix for the problem, I noticed an extreme
performance improvement when I moved from my quad-xeon to a dual
opteron. The opterons appear to handle the exact same bandwidth load at
1-2% cpu vs. the xeons averaging 40-50%.
I haven't run oprofile on the latest code, which is also running as
fully 64-bit, but I was very surprised by the difference between xeon
and opteron wrt tor performance.
I've run the old tor binaries from the xeon on the opteron as is, and
the performance improvement is the same.
This is regarding 0.1.0.1 and beyond.
On Tue, Apr 12, 2005 at 08:35:30PM -0400, jon@xxxxxxxxxxxxx wrote 1.8K bytes in 38 lines about:
: On Tue, Apr 12, 2005 at 06:23:29PM -0400, Roger Dingledine wrote:
: : From the tor-spec.txt (documenting the descriptor line):
: : "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed
: : Estimated bandwidth for this router, in bytes per second. The
: : "average" bandwidth is the volume per second that the OR is willing
: : to sustain over long periods; the "burst" bandwidth is the volume
: : that the OR is willing to sustain in very short intervals. The
: : "observed" value is an estimate of the capacity this server can
: : handle. The server remembers the max bandwidth sustained output
: : over any ten second period in the past day, and another sustained
: : input. The "observed" value is the lesser of these two numbers.
: :Check out
: :for a bit more info.
: :Let us know what you find. The 0.1.0.3-rc release has some more
: :cpu improvements, but the main pain comes from crypto, and that is
: :proportional to the number of clients who are asking you to handle a
: :circuit for them. In any case, you won't be filling up all 100Mb yet --
: :see the lower graph of http://new.noreply.org/tor-running-routers/
: :Also check out
: I am running 0.1.0.3-rc and it has greatly decreased CPU utilization,
: though it doesn't seem to have increased "bandwidth-observed", this in
: retrospect is why I brought up the question. My thought being perhaps there
: was something in the TCP stack that was bottle necking.
: In the barest terms my CPU runs about 50% idle and my pipes aren't nearly
: full seems like it could be doing more work. Perhaps I've done all I can do.
: I already have NumCpus set to 2, perhaps increasing it will help...