Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Ben O'Brien
April 28, 2005, 5:51 pm
rate this thread
York, for the inquisitive). Ssh performs horribly over this link
(~70kB/s instead of ~7MB/s, that's 10^2 people!).
Is there a way to increase the window size or whatever it's called in
the ssh protocol between the server (OpenSSH 3.6 on RHES 3) and the
clients (multiflavoured, but mostly new PuTTY and newish OpenSSH)
without recompiling on both ends? Failing that, anyone got some patches?
If anyone can come up with another reason for the abysmal speeds I'd be
p.s. It's not the encryption slowing things down (4 way 3GHz Xeons on
the server, and mostly P4 hosts connecting).
Re: High performance SSH on RHES 3. Does it exist?
You can try these:
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
High performance PuTTY (was Re: High performance SSH on RHES 3. Does it exist?)
Assuming window sizes are your problem, then I'm afraid even the newest
PuTTY won't do anything for you -- it has a fixed window size of 16k.
This is something we'd like fixed at some point, but at the moment we
don't have any patches.
If you can recompile PuTTY then it should be fairly easy to tweak the
relevant constants upwards, which may improve things for you.
(A common strategy, or at least the one given on the other URL in this
thread, is to base the SSH window size on the TCP window size. I haven't
looked into this in great detail, but the impression I got was that on
Unix at least, most stock TCPs are such that this in itself doesn't add
much, and you have to obtain a performance-enhanced TCP. Assuming I
haven't misunderstood, does anyone know what the situation is for
- » SSH access to two different ports on the same IP address
- — Next thread in » Secure Shell Forum
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum