On Sat, 20 Jan 2001, Brian Minton wrote:
> for a reasonably fast cpu, the cipher won't take up that much cpu usage... I
> think that the problem is network bandwidth. I think, but am not sure, that
> most ciphers greatly increase the amount of space used compared to unencrypted
> transmission.
this doesn't make any sense to me - correct me if i'm wrong, but scp
still uses plain tcp/ip to transmit the packets themselves, so there is no
additional networking overhead, correct? if that's the case, then data is
data - or are you saying that what's being reported by scp's meter is not
the actual thruput, but rather the amount of the original file that has
been transmitted?
that would make sense, i spose. i can test that.
scp says: 143.2 kBytes/sec
iptraf says: 1216.71 kbits/sec
so, my interface monitor agrees with SCP about the amount of data being
passed.
there are marked lags in copying, though. I really do think Something Bad
Is Happening in scp land. scp does the 'thruput normalizing' trick of
showing thruput over the length of the transfer. watching it via iptraf, i
can see it go from 3MB/sec down to 20k, sit, and wait, and then go back
up. it see-saws very badly. there is something up with the network
writes.
in fact, im sure that if i strace my scp and watch it, it will burst up to
max thruput, then wait while all those EAGAINs pop up.
ssh crew? any thoughts? i would make a wild guess that this is a buffer or
mallocation issue in sshd. am i on crack?
--
Blue Lang, Unix Voodoo Priest http://www.gator.net/~blue
202 Ashe Ave, Apt 3, Raleigh, NC. 919 835 1540
"A computer is a state machine. Threads are for people who can't program
state machines." - Alan Cox, From Larry McVoy's quote page
