scp UNBELIEVABLY slow - SSH

This is a discussion on scp UNBELIEVABLY slow - SSH ; 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 47

Thread: scp UNBELIEVABLY slow

  1. Re: scp UNBELIEVABLY slow

    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.

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

  2. Re: scp UNBELIEVABLY slow

    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)?

    - Andrew


  3. Re: scp UNBELIEVABLY slow

    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

  4. Re: scp UNBELIEVABLY slow

    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


  5. Re: scp UNBELIEVABLY slow

    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

  6. Re: scp UNBELIEVABLY slow

    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)



  7. Re: scp UNBELIEVABLY slow

    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

  8. Re: scp UNBELIEVABLY slow

    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


  9. Re: scp UNBELIEVABLY slow

    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


  10. Re: scp UNBELIEVABLY slow

    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


  11. Re: scp UNBELIEVABLY slow

    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

  12. Re: scp UNBELIEVABLY slow

    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

  13. Re: scp UNBELIEVABLY slow

    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.

  14. Re: scp UNBELIEVABLY slow

    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

  15. Re: scp UNBELIEVABLY slow

    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.

  16. Re: scp UNBELIEVABLY slow

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

  17. Re: scp UNBELIEVABLY slow

    ["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

  18. Re: scp UNBELIEVABLY slow

    In comp.security.ssh Dances With Crows wrote:
    > Darren Dunham staggered into the Black Sun and said:
    >> 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.


    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.

    > 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 definitely agree that the behavior seems to be more involved with the
    path chain than a simple duplex mismatch.

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

  19. Re: scp UNBELIEVABLY slow

    On 2008-03-26, AZ Nomad wrote:
    >
    > Yes. The encryption overhead makes anything over ssh much slower than
    > other protocols.


    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

  20. Re: scp UNBELIEVABLY slow

    ["Followup-To:" header set to comp.os.linux.misc.]
    On 2008-03-25, Frank wrote:
    > Ignoramus16148 wrote:
    >
    >> 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.


    > Get a real OS.
    > Switch to Vista.


    AFAIK, Vista doesn't include scp or any other secure file transfer
    software at all.

    --

    John (john@os2.dhs.org)

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast