Printable View
AZ Nomad wrote:[color=blue]
> Yes. The encryption overhead makes anything over ssh much slower than
> other protocols.[/color]
Much slower, that's a bit of a stretch.
As I said, I use SSHFS and i get 100Mbps on a plain 10/100 Mb network.
--
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously.
--Benjamin Franklin
On Tue, 25 Mar 2008 22:52:25 -0500, Ignoramus6291 wrote:
[color=blue]
> and speed of NFS over A, B and C is 4.5 megabytes per second.[/color]
I wonder if the packets used by SSH are larger than those used by NFS. I
vaguely recall some NFS setting which by default keeps packets small.
But I could be easily misremembering.
Is there anything else involved that might alter packet sizes? For
example, are you using some type of packet tagging (ie. 802.1q)?
- Andrew
On 2008-03-26, Andrew Gideon <c172driver1@gideon.org> wrote:[color=blue]
> On Tue, 25 Mar 2008 22:52:25 -0500, Ignoramus6291 wrote:
>[color=green]
>> and speed of NFS over A, B and C is 4.5 megabytes per second.[/color]
>
> I wonder if the packets used by SSH are larger than those used by NFS. I
> vaguely recall some NFS setting which by default keeps packets small.
> But I could be easily misremembering.
>
> Is there anything else involved that might alter packet sizes? For
> example, are you using some type of packet tagging (ie. 802.1q)?[/color]
Not intentionally. I set MTU to 1492 manually and it did not help.
i
On Wed, 26 Mar 2008 09:04:32 -0500, Ignoramus13009 wrote:
[color=blue]
> Not intentionally. I set MTU to 1492 manually and it did not help.[/color]
But did you try playing with the rsize and wsize options for NFS?
Also, did you try a smaller MTU? Perhaps that would help performance
through switch A for some reason.
Is your NFS using TCP or UDP? I cannot imagine why it would matter, but
if it is using UDP perhaps that is the significant difference.
- Andrew
On 2008-03-26, Andrew Gideon <c172driver1@gideon.org> wrote:[color=blue]
> On Wed, 26 Mar 2008 09:04:32 -0500, Ignoramus13009 wrote:
>[color=green]
>> Not intentionally. I set MTU to 1492 manually and it did not help.[/color]
>
> But did you try playing with the rsize and wsize options for NFS?[/color]
No. But keep in mind, NFS is fine mostly (though not near the gigabit
speeds). The issue is with scp.
[color=blue]
> Also, did you try a smaller MTU? Perhaps that would help performance
> through switch A for some reason.
>
> Is your NFS using TCP or UDP? I cannot imagine why it would matter, but
> if it is using UDP perhaps that is the significant difference.[/color]
i
johnny bobby bee <useraddshine-no_spam_eh@yahoo.ca> writes:
[color=blue]
>AZ Nomad wrote:[color=green]
>> Yes. The encryption overhead makes anything over ssh much slower than
>> other protocols.[/color][/color]
[color=blue]
>Much slower, that's a bit of a stretch.[/color]
[color=blue]
>As I said, I use SSHFS and i get 100Mbps on a plain 10/100 Mb network.[/color]
Well depends on your machine. If he is running an old IBM 8086 machine, I
am sure what he says is true-- that ssh adds appreciably to the time.
(Mind you he sure would not get even 10Mb/s without encryption)
On 2008-03-26, Unruh <unruh-spam@physics.ubc.ca> wrote:[color=blue]
> johnny bobby bee <useraddshine-no_spam_eh@yahoo.ca> writes:
>[color=green]
>>AZ Nomad wrote:[color=darkred]
>>> Yes. The encryption overhead makes anything over ssh much slower than
>>> other protocols.[/color][/color]
>[color=green]
>>Much slower, that's a bit of a stretch.[/color]
>[color=green]
>>As I said, I use SSHFS and i get 100Mbps on a plain 10/100 Mb network.[/color]
>
> Well depends on your machine. If he is running an old IBM 8086 machine, I
> am sure what he says is true-- that ssh adds appreciably to the time.
> (Mind you he sure would not get even 10Mb/s without encryption)
>
>[/color]
Speed is not the issue. Something about ssh/scp and a unknown network
problem that shows up over ssh, is the issue. For example, here's the
output of scp speed (31 megabytes per second) and HTTP speed (112
MB/Sec) going between routers B and C (but not A). The other server is
not my laptop.
Here SCP is 3 times slower than HTTP, which does not surprise me due
to encryption.
But between laptop, A, B, C, and my server, the speed diff. was 36
times. The laptop was able to go a lot faster without routers A and B.
So I am beginning to place blame on router A. Something is wrong with
it when I do scp.
i
On Wed, 26 Mar 2008 10:32:25 -0500, Ignoramus13009 wrote:
[color=blue][color=green]
>> But did you try playing with the rsize and wsize options for NFS?[/color]
>
> No. But keep in mind, NFS is fine mostly (though not near the gigabit
> speeds). The issue is with scp.[/color]
But you're looking for the difference. If NFS defaults to smaller packet
sizes, that might be the difference.
- Andrew
On Wed, 26 Mar 2008 12:02:07 -0500, Ignoramus13009 wrote:
[color=blue]
> So I am beginning to place blame on router A. Something is wrong with it
> when I do scp.[/color]
Is it a router or a switch? If it's a router, another difference is the
network connected on the "far" side of A.
How "smart" is A? Might it have rate limiting on SSH about which you
don't know (or have forgotten)?
- Andrew
Ignoramus6291 wrote:[color=blue]
>
>
> What I found is that if I use a chain of switches A, B, C I get
> 180 kbytes/sec throughput with ssh. If I use switches C, D, I get 3.9
> MB/second (over 20x faster).
>
> However, for A,B,C as well as for C, D the HTTP speed is roughly the
> same IIRC.
>
> i[/color]
Check that there are no duplex mismatches. A port erroneously
forced full-duplex can slow down an Ethernet link drastically
due to unnecessary collisions generated.
The protocols have different needs for return traffic, which
will be the victim in duplex mismatch.
--
Tauno Voipio
tauno voipio (at) iki fi
On 2008-03-26, Andrew Gideon <c172driver1@gideon.org> wrote:[color=blue]
> On Wed, 26 Mar 2008 12:02:07 -0500, Ignoramus13009 wrote:
>[color=green]
>> So I am beginning to place blame on router A. Something is wrong with it
>> when I do scp.[/color]
>
> Is it a router or a switch? If it's a router, another difference is the
> network connected on the "far" side of A.[/color]
It is a DIR-655 Wifi router. However, I used a Ethernet connection
between laptop and DIR-655 and not wifi.
[color=blue]
> How "smart" is A? Might it have rate limiting on SSH about which you
> don't know (or have forgotten)?[/color]
I would be surprised, but this is already surprising.
i
On 2008-03-26, Tauno Voipio <tauno.voipio@INVALIDiki.fi> wrote:[color=blue]
> Ignoramus6291 wrote:[color=green]
>>
>>
>> What I found is that if I use a chain of switches A, B, C I get
>> 180 kbytes/sec throughput with ssh. If I use switches C, D, I get 3.9
>> MB/second (over 20x faster).
>>
>> However, for A,B,C as well as for C, D the HTTP speed is roughly the
>> same IIRC.
>>
>> i[/color]
>
>
> Check that there are no duplex mismatches. A port erroneously
> forced full-duplex can slow down an Ethernet link drastically
> due to unnecessary collisions generated.
>
> The protocols have different needs for return traffic, which
> will be the victim in duplex mismatch.
>[/color]
Tauno, your explanation so far is the only one that is consistent with
all available information.
I will try scp again, then will switch to half duplex, and see if that
makes any difference.
i
Ignoramus13009 <ignoramus13009@NOSPAM.13009.invalid> writes:
[color=blue]
> On 2008-03-26, Tauno Voipio <tauno.voipio@INVALIDiki.fi> wrote:[color=green]
>> Ignoramus6291 wrote:[color=darkred]
>>>
>>>
>>> What I found is that if I use a chain of switches A, B, C I get
>>> 180 kbytes/sec throughput with ssh. If I use switches C, D, I get 3.9
>>> MB/second (over 20x faster).
>>>
>>> However, for A,B,C as well as for C, D the HTTP speed is roughly the
>>> same IIRC.
>>>
>>> i[/color]
>>
>>
>> Check that there are no duplex mismatches. A port erroneously
>> forced full-duplex can slow down an Ethernet link drastically
>> due to unnecessary collisions generated.
>>
>> The protocols have different needs for return traffic, which
>> will be the victim in duplex mismatch.
>>[/color]
>
> Tauno, your explanation so far is the only one that is consistent with
> all available information.
>
> I will try scp again, then will switch to half duplex, and see if that
> makes any difference.[/color]
If you suspect collisions, the easiest way to see them
is with the ifconfig command.
"Normal" for collisions is zero.
On 2008-03-26, Dan Espen <daneNO@MORE.mk.SPAMtelcordia.com> wrote:[color=blue]
> Ignoramus13009 <ignoramus13009@NOSPAM.13009.invalid> writes:
>[color=green]
>> On 2008-03-26, Tauno Voipio <tauno.voipio@INVALIDiki.fi> wrote:[color=darkred]
>>> Ignoramus6291 wrote:
>>>>
>>>>
>>>> What I found is that if I use a chain of switches A, B, C I get
>>>> 180 kbytes/sec throughput with ssh. If I use switches C, D, I get 3.9
>>>> MB/second (over 20x faster).
>>>>
>>>> However, for A,B,C as well as for C, D the HTTP speed is roughly the
>>>> same IIRC.
>>>>
>>>> i
>>>
>>>
>>> Check that there are no duplex mismatches. A port erroneously
>>> forced full-duplex can slow down an Ethernet link drastically
>>> due to unnecessary collisions generated.
>>>
>>> The protocols have different needs for return traffic, which
>>> will be the victim in duplex mismatch.
>>>[/color]
>>
>> Tauno, your explanation so far is the only one that is consistent with
>> all available information.
>>
>> I will try scp again, then will switch to half duplex, and see if that
>> makes any difference.[/color]
>
> If you suspect collisions, the easiest way to see them
> is with the ifconfig command.
>
> "Normal" for collisions is zero.[/color]
I will check tonight Dan. Did not know that it was so easy. Collisions
may be between the laptop and A, or between A and B (I suspect the
latter). The second case is not so easy.
i
On Wed, 26 Mar 2008 13:32:18 -0500, Ignoramus13009 <ignoramus13009@NOSPAM.13009.invalid> wrote:[color=blue]
>On 2008-03-26, Tauno Voipio <tauno.voipio@INVALIDiki.fi> wrote:[color=green]
>> Ignoramus6291 wrote:[color=darkred]
>>>
>>>
>>> What I found is that if I use a chain of switches A, B, C I get
>>> 180 kbytes/sec throughput with ssh. If I use switches C, D, I get 3.9
>>> MB/second (over 20x faster).
>>>
>>> However, for A,B,C as well as for C, D the HTTP speed is roughly the
>>> same IIRC.
>>>
>>> i[/color]
>>
>>
>> Check that there are no duplex mismatches. A port erroneously
>> forced full-duplex can slow down an Ethernet link drastically
>> due to unnecessary collisions generated.
>>
>> The protocols have different needs for return traffic, which
>> will be the victim in duplex mismatch.
>>[/color][/color]
[color=blue]
>Tauno, your explanation so far is the only one that is consistent with
>all available information.[/color]
His explanation is only valid if a network hub is used and I haven't seen
one sold in ten years. Network switches buffer the traffic and collisions
are impossible.
In comp.security.ssh Dan Espen <daneNO@more.mk.spamtelcordia.com> wrote:[color=blue][color=green]
>> I will try scp again, then will switch to half duplex, and see if that
>> makes any difference.[/color]
>
> If you suspect collisions, the easiest way to see them
> is with the ifconfig command.[/color]
[color=blue]
> "Normal" for collisions is zero.[/color]
Collisions cannot occur on a full duplex interface. By definition, it
will be zero. However if the other end is set to half-duplex, you
should see errors on the interface (almost certainly receive errors).
--
Darren Dunham [email]ddunham@taos.com[/email]
Senior Technical Consultant TAOS [url]http://www.taos.com/[/url]
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
["Followup-To:" header set to comp.os.linux.misc.]
Darren Dunham staggered into the Black Sun and said:[color=blue]
> In comp.security.ssh Dan Espen wrote:[color=green][color=darkred]
>>> I will try scp again, then will switch to half duplex, and see if
>>> that makes any difference.[/color]
>> If you suspect collisions, the easiest way to see them is with the
>> ifconfig command. "Normal" for collisions is zero.[/color]
> Collisions cannot occur on a full duplex interface.[/color]
Um... broadcast packets can collide. This is relatively rare, but it
does happen. [email]3F89CAF3.CBC5AF8E@house-from-hell.demon.co.uk[/email] said 62
million packets, 1 collision.
[color=blue]
> However if the other end is set to half-duplex, you should see errors
> on the interface (almost certainly receive errors).[/color]
Yes. Other posts from the OP make me think the problem is related to
having multiple 802.11 routers involved in the chain, rather than
something wrong with the protocol being used or duplex settings. The OP
didn't ever reply to my post about using scp -v and checking the output
for anything odd, either.
--
I will rule you all with my iron fist. YOU! Obey the fist!
--Invader Zim
My blog and resume: [url]http://crow202.dyndns.org:8080/wordpress/[/url]
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
In comp.security.ssh Dances With Crows <danceswithcrows@usa.net> wrote:[color=blue]
> Darren Dunham staggered into the Black Sun and said:[color=green]
>> Collisions cannot occur on a full duplex interface.[/color]
>
> Um... broadcast packets can collide. This is relatively rare, but it
> does happen. [email]3F89CAF3.CBC5AF8E@house-from-hell.demon.co.uk[/email] said 62
> million packets, 1 collision.[/color]
What do you mean by a "broadcast packet"? At the media level (where
collisions occur), there's no such distinction that I can think of. All
packets are seen by all recipients on the link.
But regardless of the actual topology, an interface that is configured
for full-duplex should ignore or disable collision detection. Traffic
cannot cause a collision to be reported to the driver. If it is, it's
either not really in full-duplex mode or it's a bug.
[color=blue]
> Other posts from the OP make me think the problem is related to having
> multiple 802.11 routers involved in the chain, rather than something
> wrong with the protocol being used or duplex settings. The OP didn't
> ever reply to my post about using scp -v and checking the output for
> anything odd, either.[/color]
I definitely agree that the behavior seems to be more involved with the
path chain than a simple duplex mismatch.
--
Darren Dunham [email]ddunham@taos.com[/email]
Senior Technical Consultant TAOS [url]http://www.taos.com/[/url]
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
On 2008-03-26, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:[color=blue]
>
> Yes. The encryption overhead makes anything over ssh much slower than
> other protocols.[/color]
Depends on the encryption you use. Try Blowfish.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
["Followup-To:" header set to comp.os.linux.misc.]
On 2008-03-25, Frank <fb@tri.olk> wrote:[color=blue]
> Ignoramus16148 wrote:
>[color=green]
>> I am on a good network here. I need to copy a bunch of AVI from a
>> laptop to my basement server. Wired network. HTTP test yields about 6
>> megabytes per second transfer speed.
>>
>> SCP is only doing 188 kB per second, or 36 times slower.
>>
>> I am copying from Ubuntu Hardy to Fedora 7.
>>
>> WTF, how can I debug this. Thanks.[/color][/color]
[color=blue]
> Get a real OS.
> Switch to Vista.[/color]
AFAIK, Vista doesn't include scp or any other secure file transfer
software at all.
--
John (john@os2.dhs.org)