On 2008-03-26, Andrew Gideon wrote:
> On Tue, 25 Mar 2008 22:52:25 -0500, Ignoramus6291 wrote:
>
>> and speed of NFS over A, B and C is 4.5 megabytes per second.
>
> 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)?

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:

> Not intentionally. I set MTU to 1492 manually and it did not help.

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 wrote:
> On Wed, 26 Mar 2008 09:04:32 -0500, Ignoramus13009 wrote:
>
>> Not intentionally. I set MTU to 1492 manually and it did not help.
>
> But did you try playing with the rsize and wsize options for NFS?

No. But keep in mind, NFS is fine mostly (though not near the gigabit
speeds). The issue is with scp.

> 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.

i

johnny bobby bee writes:

>AZ Nomad wrote:
>> Yes. The encryption overhead makes anything over ssh much slower than
>> other protocols.

>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.

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 wrote:
> johnny bobby bee writes:
>
>>AZ Nomad wrote:
>>> Yes. The encryption overhead makes anything over ssh much slower than
>>> other protocols.
>
>>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.
>
> 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)
>
>

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:

>> But did you try playing with the rsize and wsize options for NFS?
>
> No. But keep in mind, NFS is fine mostly (though not near the gigabit
> speeds). The issue is with scp.

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:

> So I am beginning to place blame on router A. Something is wrong with it
> when I do scp.

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:
>
>
> 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.

--

Tauno Voipio
tauno voipio (at) iki fi

On 2008-03-26, Andrew Gideon wrote:
> On Wed, 26 Mar 2008 12:02:07 -0500, Ignoramus13009 wrote:
>
>> So I am beginning to place blame on router A. Something is wrong with it
>> when I do scp.
>
> Is it a router or a switch? If it's a router, another difference is the
> network connected on the "far" side of A.

It is a DIR-655 Wifi router. However, I used a Ethernet connection
between laptop and DIR-655 and not wifi.

> How "smart" is A? Might it have rate limiting on SSH about which you
> don't know (or have forgotten)?

I would be surprised, but this is already surprising.

i

On 2008-03-26, Tauno Voipio wrote:
> 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.
>

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 writes:

> On 2008-03-26, Tauno Voipio wrote:
>> 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.
>>
>
> 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.

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 wrote:
> Ignoramus13009 writes:
>
>> On 2008-03-26, Tauno Voipio wrote:
>>> 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.
>>>
>>
>> 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.
>
> If you suspect collisions, the easiest way to see them
> is with the ifconfig command.
>
> "Normal" for collisions is zero.

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 wrote:
>On 2008-03-26, Tauno Voipio wrote:
>> 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.
>>

>Tauno, your explanation so far is the only one that is consistent with
>all available information.

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.

On 2008-03-25, Ignoramus16148 wrote:
>>
>> Use NFS instead of SCP?
>
> I want to use SCP. It is a bad security to se NFS in this manner.

If it is on your home network, not routing outside in any way, there
is no security risk. Your call, though...


--
Joe - Linux User #449481/Ubuntu User #19733
joe at hits - buffalo dot com
"Hate is baggage, life is too short to go around pissed off all the
time..." - Danny, American History X

On 2008-03-26, johnny bobby bee wrote:
> AZ Nomad wrote:
>> Yes. The encryption overhead makes anything over ssh much slower than
>> other protocols.
>
> 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.
>

Not to be too pedantic, but that is not really that likely. Ethernet
isn't that efficient. Usually you can expect to get about 70Mbps or
so on a 100M LAN...


--
Joe - Linux User #449481/Ubuntu User #19733
joe at hits - buffalo dot com
"Hate is baggage, life is too short to go around pissed off all the
time..." - Danny, American History X

On 2008-03-27, Joe wrote:
> On 2008-03-26, johnny bobby bee wrote:
>> AZ Nomad wrote:
>>> Yes. The encryption overhead makes anything over ssh much slower than
>>> other protocols.
>>
>> 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.
>>
>
> Not to be too pedantic, but that is not really that likely. Ethernet
> isn't that efficient. Usually you can expect to get about 70Mbps or
> so on a 100M LAN...
>

My experience is that I often get top performance on LANs.

MANIFOLD::~==>test-speed-hollywood-http
--10:08:02-- http://hollywood.algebra.com/tmp/1gig
=> `/dev/null'
Resolving hollywood.algebra.com... 75.146.106.185
Connecting to hollywood.algebra.com|75.146.106.185|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,073,741,824 (1.0G) [text/plain]

100%[================================================== ====================================>] 1,073,741,824 112.21M/s ETA 00:00

10:08:12 (112.04 MB/s) - `/dev/null' saved [1073741824/1073741824]

Here I get 112 megaBYTES [er second on a gigabit home LAN.

i

On 2008-03-27, Joe wrote:
> On 2008-03-25, Ignoramus16148 wrote:
>>>
>>> Use NFS instead of SCP?
>>
>> I want to use SCP. It is a bad security to se NFS in this manner.
>
> If it is on your home network, not routing outside in any way, there
> is no security risk. Your call, though...
>

First of all, though I like my network, I do not exclude the
possibility of unfriendly computers on it. I have wifi, and also,
there is a windows laptop on my network, plus from time to time I have
friends coming in with their laptops.

So I try to be safe from such unfriendly computers.

i

In comp.security.ssh Dan Espen wrote:
>> I will try scp again, then will switch to half duplex, and see if that
>> makes any difference.
>
> If you suspect collisions, the easiest way to see them
> is with the ifconfig command.

> "Normal" for collisions is zero.

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 ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
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:
> In comp.security.ssh Dan Espen wrote:
>>> I will try scp again, then will switch to half duplex, and see if
>>> that makes any difference.
>> If you suspect collisions, the easiest way to see them is with the
>> ifconfig command. "Normal" for collisions is zero.
> Collisions cannot occur on a full duplex interface.

Um... broadcast packets can collide. This is relatively rare, but it
does happen. 3F89CAF3.CBC5AF8E@house-from-hell.demon.co.uk said 62
million packets, 1 collision.

> However if the other end is set to half-duplex, you should see errors
> on the interface (almost certainly receive errors).

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: http://crow202.dyndns.org:8080/wordpress/
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see