On Sun, Oct 21, 2007 at 03:14:39PM +0200, Robert Lemmen wrote:
> thanks for the report, it would be really cool if you could tell me
> how exactly you can create this situation, up to now i have never been
I'd be glad to help you debug it, if I can. It seems to be a problem
with any process that sends continuous streams, rather than bursty
traffic. So, for example, I see few problems with SSH itself, or with
things that have been set to sleep periodically (e.g. wget or hellanzb).
But, for example, tunneling the pan newsreader over a trickled ssh
session consistently causes the CPU spike. Other similar tools, such as
iprelay, don't exhibit the same behavior from a user perspective.
To recreate what I've done, set up something like the following:
# Set up a trickled ssh connection. Set the bandwidth to something
# significantly below your available pipe. The -t and -l settings
# don't seem to have much impact on this problem, so we'll ignore
# them.
trickle -d 30 ssh -fN -L 1119:localhost:119 foo.example.com
# Now run any newsreader that can do binary downloads. I've tested
# with pan, klibido, and hellanzb. Make sure they're pointing to
# localhost:1119 (or whatever) as your news server and start
# downloading something large.
pan --nzb example.nzb -o /tmp &
# Watch your cpu usage spike as ssh starts sucking up all the
# available cycles! Note that ssh doesn't exhibit this behavior with
# the same volume of traffic without trickle; it uses more
# bandwidth, but the cpu usage drops to normal.
xosview &
I see similar behavior with tunnelled HTTP downloads, as well. In
fairness, I *am* tunnelling over ssh, since many of the binaries aren't
dynamic executables, so I'm relying on ssh as the choke point, so there
may be some interaction there that is non-obvious.
Does this help at all?
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
