Gigabit Ethernet, and Linux -- first observations - SSH

This is a discussion on Gigabit Ethernet, and Linux -- first observations - SSH ; I installed a gigabit network switch and a gigabit enabled laptop wifi adapter (with gigabit, obviously, available on ethernet ports only) in my house. Two computers in my home are connected to the switch and one (laptop) to the wifi ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Gigabit Ethernet, and Linux -- first observations

  1. Gigabit Ethernet, and Linux -- first observations

    I installed a gigabit network switch and a gigabit enabled laptop wifi
    adapter (with gigabit, obviously, available on ethernet ports only) in
    my house.

    Two computers in my home are connected to the switch and one (laptop)
    to the wifi adaptor.

    The highest possible speed of a gigabit connection is about 111
    megabytes per second.

    Naturally, I did some tests with a noncompressible 1 gigabyte long
    file (fragment of some gzipped file exactly one GB long).

    My first test was to scp files from one computer on the switch to
    another. Here, I was disappointed as the highest speed was only 22
    megabytes per second one way and 46 another way. About 20 and 40
    percent of maximum.

    Then I tried using HTTP to transfer the same file (both computers are
    webservers). To my huge surprise, it made a world of difference and
    the transfer speed was 111 or so megabytes per second.

    So, now I have a dilemma, I have a fast pipe, but scp is not fast
    enough (given my CPU) to encrypt/decrypt so much data.

    I tried something else, which is doing wc -l on a NFS mounted drive
    (same two computers). It was UNBELIEVABLY slow and the load average on
    the NFS server shot WAY up. Transferring a 336 MB file took 157
    seconds, or about e megabytes per second (vs 111 mbps that I achieved
    with HTTP).

    So, the conclusion is, HTTP is fast (no wonder), SSH is "medium",
    and NFS is "slow, very bad".

    The connection to laptop is a disappointment in its own right, since
    even with all-ethernet connection, I get about 3 megabytes per
    second. I think that I need to pull a new wire in the wall.

    So, the short of it is that there is much work to be done.

    i

  2. Re: Gigabit Ethernet, and Linux -- first observations

    Ignoramus26973 wrote:
    > I installed a gigabit network switch and a gigabit enabled laptop wifi
    > adapter (with gigabit, obviously, available on ethernet ports only) in
    > my house.
    >
    > Two computers in my home are connected to the switch and one (laptop)
    > to the wifi adaptor.
    >
    > The highest possible speed of a gigabit connection is about 111
    > megabytes per second.
    >
    > Naturally, I did some tests with a noncompressible 1 gigabyte long
    > file (fragment of some gzipped file exactly one GB long).
    >
    > My first test was to scp files from one computer on the switch to
    > another. Here, I was disappointed as the highest speed was only 22
    > megabytes per second one way and 46 another way. About 20 and 40
    > percent of maximum.
    >
    > Then I tried using HTTP to transfer the same file (both computers are
    > webservers). To my huge surprise, it made a world of difference and
    > the transfer speed was 111 or so megabytes per second.
    >
    > So, now I have a dilemma, I have a fast pipe, but scp is not fast
    > enough (given my CPU) to encrypt/decrypt so much data.
    >
    > I tried something else, which is doing wc -l on a NFS mounted drive
    > (same two computers). It was UNBELIEVABLY slow and the load average on
    > the NFS server shot WAY up. Transferring a 336 MB file took 157
    > seconds, or about e megabytes per second (vs 111 mbps that I achieved
    > with HTTP).


    So, about 2.7 MB/s? :-)

    >
    > So, the conclusion is, HTTP is fast (no wonder), SSH is "medium",
    > and NFS is "slow, very bad".


    I ran into a similar problem with NFS ages back. Turns out you can
    largely fix it by configuring NFS to increase the packet size. Been a
    few years since I did anything with NFS, though, so you'll have to look
    through the docs. I hear they use it in computer clusters, so it can't
    be slow in *all* cases.

    Around the same time, I also noticed that rsync can have similar speed
    issues to SCP for a first copy, owing to it insisting on using SSH for RSH.

  3. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 01:14:07 -0400, Michael Mol wrote:

    > Ignoramus26973 wrote:
    >> I installed a gigabit network switch and a gigabit enabled laptop wifi
    >> adapter (with gigabit, obviously, available on ethernet ports only) in
    >> my house.
    >>
    >> Two computers in my home are connected to the switch and one (laptop)
    >> to the wifi adaptor.
    >>
    >> The highest possible speed of a gigabit connection is about 111
    >> megabytes per second.
    >>
    >> Naturally, I did some tests with a noncompressible 1 gigabyte long file
    >> (fragment of some gzipped file exactly one GB long).
    >>
    >> My first test was to scp files from one computer on the switch to
    >> another. Here, I was disappointed as the highest speed was only 22
    >> megabytes per second one way and 46 another way. About 20 and 40
    >> percent of maximum.
    >>
    >> Then I tried using HTTP to transfer the same file (both computers are
    >> webservers). To my huge surprise, it made a world of difference and the
    >> transfer speed was 111 or so megabytes per second.
    >>
    >> So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >> enough (given my CPU) to encrypt/decrypt so much data.
    >>
    >> I tried something else, which is doing wc -l on a NFS mounted drive
    >> (same two computers). It was UNBELIEVABLY slow and the load average on
    >> the NFS server shot WAY up. Transferring a 336 MB file took 157
    >> seconds, or about e megabytes per second (vs 111 mbps that I achieved
    >> with HTTP).

    >
    > So, about 2.7 MB/s? :-)
    >
    >
    >> So, the conclusion is, HTTP is fast (no wonder), SSH is "medium", and
    >> NFS is "slow, very bad".

    >
    > I ran into a similar problem with NFS ages back. Turns out you can
    > largely fix it by configuring NFS to increase the packet size. Been a
    > few years since I did anything with NFS, though, so you'll have to look
    > through the docs. I hear they use it in computer clusters, so it can't
    > be slow in *all* cases.


    How do you configure NFS to increase the packet size? Also are you
    talking about NFS V4 or V3?

  4. Re: Gigabit Ethernet, and Linux -- first observations

    On 12 Sep 2007 12:52:09 GMT, General Schvantzkoph wrote:


    >On Wed, 12 Sep 2007 01:14:07 -0400, Michael Mol wrote:


    >> Ignoramus26973 wrote:
    >>> I installed a gigabit network switch and a gigabit enabled laptop wifi
    >>> adapter (with gigabit, obviously, available on ethernet ports only) in
    >>> my house.
    >>>
    >>> Two computers in my home are connected to the switch and one (laptop)
    >>> to the wifi adaptor.
    >>>
    >>> The highest possible speed of a gigabit connection is about 111
    >>> megabytes per second.
    >>>
    >>> Naturally, I did some tests with a noncompressible 1 gigabyte long file
    >>> (fragment of some gzipped file exactly one GB long).
    >>>
    >>> My first test was to scp files from one computer on the switch to
    >>> another. Here, I was disappointed as the highest speed was only 22
    >>> megabytes per second one way and 46 another way. About 20 and 40
    >>> percent of maximum.
    >>>
    >>> Then I tried using HTTP to transfer the same file (both computers are
    >>> webservers). To my huge surprise, it made a world of difference and the
    >>> transfer speed was 111 or so megabytes per second.
    >>>
    >>> So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >>> enough (given my CPU) to encrypt/decrypt so much data.
    >>>
    >>> I tried something else, which is doing wc -l on a NFS mounted drive
    >>> (same two computers). It was UNBELIEVABLY slow and the load average on
    >>> the NFS server shot WAY up. Transferring a 336 MB file took 157
    >>> seconds, or about e megabytes per second (vs 111 mbps that I achieved
    >>> with HTTP).

    >>
    >> So, about 2.7 MB/s? :-)
    >>
    >>
    >>> So, the conclusion is, HTTP is fast (no wonder), SSH is "medium", and
    >>> NFS is "slow, very bad".

    >>
    >> I ran into a similar problem with NFS ages back. Turns out you can
    >> largely fix it by configuring NFS to increase the packet size. Been a
    >> few years since I did anything with NFS, though, so you'll have to look
    >> through the docs. I hear they use it in computer clusters, so it can't
    >> be slow in *all* cases.


    >How do you configure NFS to increase the packet size? Also are you
    >talking about NFS V4 or V3?


    when you mount it. Why didn't you just google for "nfs packet size"?

  5. Re: Gigabit Ethernet, and Linux -- first observations

    On Tue, 11 Sep 2007 23:02:37 -0500, Ignoramus26973 wrote:

    > I installed a gigabit network switch and a gigabit enabled laptop wifi
    > adapter (with gigabit, obviously, available on ethernet ports only) in
    > my house.
    >
    > Two computers in my home are connected to the switch and one (laptop)
    > to the wifi adaptor.
    >
    > The highest possible speed of a gigabit connection is about 111
    > megabytes per second.
    >
    > Naturally, I did some tests with a noncompressible 1 gigabyte long
    > file (fragment of some gzipped file exactly one GB long).
    >
    > My first test was to scp files from one computer on the switch to
    > another. Here, I was disappointed as the highest speed was only 22
    > megabytes per second one way and 46 another way. About 20 and 40
    > percent of maximum.
    >
    > Then I tried using HTTP to transfer the same file (both computers are
    > webservers). To my huge surprise, it made a world of difference and
    > the transfer speed was 111 or so megabytes per second.
    >
    > So, now I have a dilemma, I have a fast pipe, but scp is not fast
    > enough (given my CPU) to encrypt/decrypt so much data.
    >
    > I tried something else, which is doing wc -l on a NFS mounted drive
    > (same two computers). It was UNBELIEVABLY slow and the load average on
    > the NFS server shot WAY up. Transferring a 336 MB file took 157
    > seconds, or about e megabytes per second (vs 111 mbps that I achieved
    > with HTTP).
    >
    > So, the conclusion is, HTTP is fast (no wonder), SSH is "medium",
    > and NFS is "slow, very bad".
    >
    > The connection to laptop is a disappointment in its own right, since
    > even with all-ethernet connection, I get about 3 megabytes per
    > second. I think that I need to pull a new wire in the wall.
    >
    > So, the short of it is that there is much work to be done.
    >
    > i


    you didn't mention Jumbo Frames.

    IF ( BIG IF ) your Gigabit hardware supports 9K MTUs, you can get
    a big boost if you set your MTU to 9000 on your nics.

    I'll post some numbers from my setup in the next couple of days.

    jack


    --
    D.A.M. - Mothers Against Dyslexia

    see http://www.jacksnodgrass.com for my contact info.

    jack - Grapevine/Richardson

  6. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 13:32:12 GMT, Jack Snodgrass wrote:
    > On Tue, 11 Sep 2007 23:02:37 -0500, Ignoramus26973 wrote:
    >
    >> I installed a gigabit network switch and a gigabit enabled laptop wifi
    >> adapter (with gigabit, obviously, available on ethernet ports only) in
    >> my house.
    >>
    >> Two computers in my home are connected to the switch and one (laptop)
    >> to the wifi adaptor.
    >>
    >> The highest possible speed of a gigabit connection is about 111
    >> megabytes per second.
    >>
    >> Naturally, I did some tests with a noncompressible 1 gigabyte long
    >> file (fragment of some gzipped file exactly one GB long).
    >>
    >> My first test was to scp files from one computer on the switch to
    >> another. Here, I was disappointed as the highest speed was only 22
    >> megabytes per second one way and 46 another way. About 20 and 40
    >> percent of maximum.
    >>
    >> Then I tried using HTTP to transfer the same file (both computers are
    >> webservers). To my huge surprise, it made a world of difference and
    >> the transfer speed was 111 or so megabytes per second.
    >>
    >> So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >> enough (given my CPU) to encrypt/decrypt so much data.
    >>
    >> I tried something else, which is doing wc -l on a NFS mounted drive
    >> (same two computers). It was UNBELIEVABLY slow and the load average on
    >> the NFS server shot WAY up. Transferring a 336 MB file took 157
    >> seconds, or about e megabytes per second (vs 111 mbps that I achieved
    >> with HTTP).
    >>
    >> So, the conclusion is, HTTP is fast (no wonder), SSH is "medium",
    >> and NFS is "slow, very bad".
    >>
    >> The connection to laptop is a disappointment in its own right, since
    >> even with all-ethernet connection, I get about 3 megabytes per
    >> second. I think that I need to pull a new wire in the wall.
    >>
    >> So, the short of it is that there is much work to be done.
    >>
    >> i

    >
    > you didn't mention Jumbo Frames.
    >
    > IF ( BIG IF ) your Gigabit hardware supports 9K MTUs, you can get
    > a big boost if you set your MTU to 9000 on your nics.


    I think that it does support jumbo frames.

    > I'll post some numbers from my setup in the next couple of days.


    How do you set MTU? That would only work for local destinations,
    right? It would not work for connections outside of my home LAN?

    i

  7. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 13:08:06 GMT, AZ Nomad wrote:
    > On 12 Sep 2007 12:52:09 GMT, General Schvantzkoph wrote:
    >
    >
    >>On Wed, 12 Sep 2007 01:14:07 -0400, Michael Mol wrote:

    >
    >>> Ignoramus26973 wrote:
    >>>> I installed a gigabit network switch and a gigabit enabled laptop wifi
    >>>> adapter (with gigabit, obviously, available on ethernet ports only) in
    >>>> my house.
    >>>>
    >>>> Two computers in my home are connected to the switch and one (laptop)
    >>>> to the wifi adaptor.
    >>>>
    >>>> The highest possible speed of a gigabit connection is about 111
    >>>> megabytes per second.
    >>>>
    >>>> Naturally, I did some tests with a noncompressible 1 gigabyte long file
    >>>> (fragment of some gzipped file exactly one GB long).
    >>>>
    >>>> My first test was to scp files from one computer on the switch to
    >>>> another. Here, I was disappointed as the highest speed was only 22
    >>>> megabytes per second one way and 46 another way. About 20 and 40
    >>>> percent of maximum.
    >>>>
    >>>> Then I tried using HTTP to transfer the same file (both computers are
    >>>> webservers). To my huge surprise, it made a world of difference and the
    >>>> transfer speed was 111 or so megabytes per second.
    >>>>
    >>>> So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >>>> enough (given my CPU) to encrypt/decrypt so much data.
    >>>>
    >>>> I tried something else, which is doing wc -l on a NFS mounted drive
    >>>> (same two computers). It was UNBELIEVABLY slow and the load average on
    >>>> the NFS server shot WAY up. Transferring a 336 MB file took 157
    >>>> seconds, or about e megabytes per second (vs 111 mbps that I achieved
    >>>> with HTTP).
    >>>
    >>> So, about 2.7 MB/s? :-)
    >>>
    >>>
    >>>> So, the conclusion is, HTTP is fast (no wonder), SSH is "medium", and
    >>>> NFS is "slow, very bad".
    >>>
    >>> I ran into a similar problem with NFS ages back. Turns out you can
    >>> largely fix it by configuring NFS to increase the packet size. Been a
    >>> few years since I did anything with NFS, though, so you'll have to look
    >>> through the docs. I hear they use it in computer clusters, so it can't
    >>> be slow in *all* cases.

    >
    >>How do you configure NFS to increase the packet size? Also are you
    >>talking about NFS V4 or V3?

    >
    > when you mount it. Why didn't you just google for "nfs packet size"?


    When I configure rsize and wsize, the mount fails for some reason, it
    does not like these options, even if set at 4192. Client is Fedore 7,
    server is Fedora Core 6.

    i

  8. Re: Gigabit Ethernet, and Linux -- first observations

    Ignoramus26973 writes:
    >So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >enough (given my CPU) to encrypt/decrypt so much data.


    Using a different cipher like blowfish will speed this up a bit but http
    or ftp will still be faster.

    Later

    Mark Hittinger
    bugs@pu.net

  9. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 08:48:04 -0500, Ignoramus19897 wrote:


    .... trimmed....

    >>> So, the short of it is that there is much work to be done.
    >>>
    >>> i

    >>
    >> you didn't mention Jumbo Frames.
    >>
    >> IF ( BIG IF ) your Gigabit hardware supports 9K MTUs, you can get
    >> a big boost if you set your MTU to 9000 on your nics.

    >
    > I think that it does support jumbo frames.
    >


    .... there is 'think' and 'does'.... say that you have 2 computers
    connected via a switch... all 3 network devices have to support
    jumbo frames. Until fairly recently, home network switches did NOT.
    I don't think any of the NetGear nics support 9K jumbo frames...
    some manuafactures claim jumbo frame support, but they are smaller
    jumbo frames... 4.5K or 7K. I find it best when all the equipment
    supports 9K Jumbo Frames. Some 'versions' of switches support
    jumbo frames and other versions of the same switch do not. You really
    need to look at the specs of the equipment you have to figure out if
    this will work or not.


    >> I'll post some numbers from my setup in the next couple of days.

    >
    > How do you set MTU? That would only work for local destinations,
    > right? It would not work for connections outside of my home LAN?
    >

    ifconfig eth0 down
    ifconfig eth0 mtu 9000
    ifconfig eth0 up
    ifconfig eth0 | grep MTU
    should then show:
    UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1


    if your 9K Jumbo Frame MTU is not working... you'll get something like
    ssh remote_host
    prompt# dmesg
    ....about 1500 bytes of output from the command
    ....
    and then the session will hang..... you'll have to kill the session and
    set the MTU back to the default ( 1500 )


    jack

    > i


    --
    D.A.M. - Mothers Against Dyslexia

    see http://www.jacksnodgrass.com for my contact info.

    jack - Grapevine/Richardson

  10. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 16:41:40 GMT, Jack Snodgrass wrote:
    > On Wed, 12 Sep 2007 08:48:04 -0500, Ignoramus19897 wrote:
    >
    >
    > ... trimmed....
    >
    >>>> So, the short of it is that there is much work to be done.
    >>>>
    >>>> i
    >>>
    >>> you didn't mention Jumbo Frames.
    >>>
    >>> IF ( BIG IF ) your Gigabit hardware supports 9K MTUs, you can get
    >>> a big boost if you set your MTU to 9000 on your nics.

    >>
    >> I think that it does support jumbo frames.
    >>

    >
    > ... there is 'think' and 'does'.... say that you have 2 computers
    > connected via a switch... all 3 network devices have to support
    > jumbo frames. Until fairly recently, home network switches did
    > NOT. I don't think any of the NetGear nics support 9K jumbo
    > frames... some manuafactures claim jumbo frame support, but they are
    > smaller jumbo frames... 4.5K or 7K. I find it best when all the
    > equipment supports 9K Jumbo Frames. Some 'versions' of switches
    > support jumbo frames and other versions of the same switch do
    > not. You really need to look at the specs of the equipment you have
    > to figure out if this will work or not.


    My switch does support it:

    http://www.newegg.com/Product/Produc...82E16833124130

    LINKSYS SR2016 10/100/1000Mbps Gigabit Switch
    Jumbo Frames 9K bytes

    What I do not understand is, who needs to set 9k MTU? Both computers
    involved?

    How about regular Internet traffic, between one of these computers and
    a server elsewhere? Would the 9k MTU screw that up if the other
    computers on the Internet do not support jumbo frames??

    i


    >
    >>> I'll post some numbers from my setup in the next couple of days.

    >>
    >> How do you set MTU? That would only work for local destinations,
    >> right? It would not work for connections outside of my home LAN?
    >>

    > ifconfig eth0 down
    > ifconfig eth0 mtu 9000
    > ifconfig eth0 up
    > ifconfig eth0 | grep MTU
    > should then show:
    > UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
    >
    >
    > if your 9K Jumbo Frame MTU is not working... you'll get something like
    > ssh remote_host
    > prompt# dmesg
    > ...about 1500 bytes of output from the command
    > ...
    > and then the session will hang..... you'll have to kill the session and
    > set the MTU back to the default ( 1500 )
    >
    >
    > jack
    >
    >> i

    >


  11. Re: Gigabit Ethernet, and Linux -- first observations

    In comp.os.linux.networking Ignoramus26973 wrote:

    > Then I tried using HTTP to transfer the same file (both computers are
    > webservers). To my huge surprise, it made a world of difference and
    > the transfer speed was 111 or so megabytes per second.


    So much for suggesting you run netperf TCP_STREAM between the two
    systems

    WRT NFS, NFS is not a bulk transfer protocol. It is a
    request/response protocol, which means even for the file copies, there
    is a greater sensitivity to latency than with HTTP or FTP or whatnot.
    The suggestions to increase mount size are likely all good. I'm not
    sure that 4192 is a proper mount size, but 4096 or 8192 would be.
    Probably want something larger. You can get a feel for latency either
    with ping, or with a netperf TCP_RR test.

    WRT Jumbo Frames... You need to enable it at both ends, and through
    the middle - that means both your systems, _and_ the switch. For
    Linux hosts the ifconfig mtu has already been
    mentioned. If the switch requires configuration then that will be in
    the switch's docs.

    For TCP traffic, you don't have to worry about communication with the
    rest of the internet, nor the rest of the nodes (if any) in your LAN.
    The TCP MSS exchange will ensure that when speaking with a system with
    a smaller MTU a suitable TCP MSS is selected.

    For things using UDP though, you will have problems. Your systems
    with Jumbo Frames enabled will only fragment to ~9000 bytes, which
    will hit your switch, which will not be able to pass that along to
    other hosts on the LAN because switches, which operate at layer-2, do
    not (should not) fragment IP datagrams.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  12. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 17:11:10 +0000 (UTC), Rick Jones wrote:
    > In comp.os.linux.networking Ignoramus26973 wrote:
    >
    >> Then I tried using HTTP to transfer the same file (both computers are
    >> webservers). To my huge surprise, it made a world of difference and
    >> the transfer speed was 111 or so megabytes per second.

    >
    > So much for suggesting you run netperf TCP_STREAM between the two
    > systems
    >
    > WRT NFS, NFS is not a bulk transfer protocol. It is a
    > request/response protocol, which means even for the file copies, there
    > is a greater sensitivity to latency than with HTTP or FTP or whatnot.
    > The suggestions to increase mount size are likely all good. I'm not
    > sure that 4192 is a proper mount size, but 4096 or 8192 would be.
    > Probably want something larger. You can get a feel for latency either
    > with ping, or with a netperf TCP_RR test.


    OK, I spent a long time messing with NFS today and I am very
    confused. Specifying rsize and wsize does not work. I cannot mount if
    I specify rsize and wsize in fstab:

    DOES NOT WORK: manifold:/home/ichudov/tmp/incoming/torrent /torrents nfs ro,auto,rsize=8192,wsize=8192 0 0
    WORKS FINE: manifold:/home/ichudov/tmp/incoming/torrent /torrents nfs ro,auto 0 0

    Both systems are recent linux computers.

    > WRT Jumbo Frames... You need to enable it at both ends, and through
    > the middle - that means both your systems, _and_ the switch. For
    > Linux hosts the ifconfig mtu has already been
    > mentioned. If the switch requires configuration then that will be in
    > the switch's docs.
    >
    > For TCP traffic, you don't have to worry about communication with the
    > rest of the internet, nor the rest of the nodes (if any) in your LAN.
    > The TCP MSS exchange will ensure that when speaking with a system with
    > a smaller MTU a suitable TCP MSS is selected.
    >
    > For things using UDP though, you will have problems. Your systems
    > with Jumbo Frames enabled will only fragment to ~9000 bytes, which
    > will hit your switch, which will not be able to pass that along to
    > other hosts on the LAN because switches, which operate at layer-2, do
    > not (should not) fragment IP datagrams.


    I have a feeling that MTU is not what I should be working on at the
    moment, since HTTP is fine with 1492 MTU. Plus I cannot seem able to
    set MTU on one of the computers.

    i

  13. Re: Gigabit Ethernet, and Linux -- first observations

    Ignoramus19897 writes:

    >What I do not understand is, who needs to set 9k MTU? Both computers
    >involved?


    Both computers and possibly the switch.

    >How about regular Internet traffic, between one of these computers and
    >a server elsewhere? Would the 9k MTU screw that up if the other
    >computers on the Internet do not support jumbo frames??


    The MTU depends on the route, for the default route to the internet
    you usually get an MTU of 512, maybe more if PMTUD is used. This
    also means that all computers on the local network need to support
    Jumbo frames.

    In any case, the advantage of using Jumbo frames is overestimated.
    It's usually not worth the effort.

    --
    --
    Michael van Elst
    Internet: mlelstv@serpens.de
    "A potential Snark may lurk in every tree."

  14. Re: Gigabit Ethernet, and Linux -- first observations

    Mark Hittinger wrote:
    >>So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >>enough (given my CPU) to encrypt/decrypt so much data.


    >Using a different cipher like blowfish will speed this up a bit but http
    >or ftp will still be faster.


    You're measuring two different things: encryption speed and transmission speed.
    If you want encryption, you should compare with https, not http. Or if you
    don't want encryption, use the "none" cipher for ssh/scp.
    --
    Mark Rafn dagon@dagon.net

  15. Re: Gigabit Ethernet, and Linux -- first observations

    On 2007-09-12, Mark Rafn wrote:
    > Mark Hittinger wrote:
    >>>So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >>>enough (given my CPU) to encrypt/decrypt so much data.

    >
    >>Using a different cipher like blowfish will speed this up a bit but http
    >>or ftp will still be faster.

    >
    > You're measuring two different things: encryption speed and transmission speed.
    > If you want encryption, you should compare with https, not http. Or if you
    > don't want encryption, use the "none" cipher for ssh/scp.


    The "none" cipher may not be available.

    With Mandriva 2007.0, openssh-clients-4.5p1-0.1mdv2007.0,
    the scp man page says the -c option and its argument are
    passed from scp to ssh, and the ssh man page does not
    mention a 'none' argument. An attempt to do "ssh -c none
    ...." returns the following error message:

    No valid ciphers for protocol version 2 given, using defaults.

    --
    Robert Riches
    spamtrap42@verizon.net
    (Yes, that is one of my email addresses.)

  16. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 15:26:26 -0700, Mark Rafn wrote:
    > Mark Hittinger wrote:
    >>>So, now I have a dilemma, I have a fast pipe, but scp is not fast
    >>>enough (given my CPU) to encrypt/decrypt so much data.

    >
    >>Using a different cipher like blowfish will speed this up a bit but http
    >>or ftp will still be faster.

    >
    > You're measuring two different things: encryption speed and transmission speed.
    > If you want encryption, you should compare with https, not http. Or if you
    > don't want encryption, use the "none" cipher for ssh/scp.


    Does not work for me, scp says that "none" is not a valid cipher:

    ::~==>scp -c none hollywood:1gig /dev/null
    No valid ciphers for protocol version 2 given, using defaults.
    1gig 11% 118MB 32.1MB/s 00:28 ETA
    Killed by signal 2.
    BEAR::~==>

  17. Re: Gigabit Ethernet, and Linux -- first observations

    Ignoramus26973 writes:

    > I installed a gigabit network switch and a gigabit enabled laptop wifi
    > adapter (with gigabit, obviously, available on ethernet ports only) in
    > my house.
    >
    > Two computers in my home are connected to the switch and one (laptop)
    > to the wifi adaptor.
    >
    > The highest possible speed of a gigabit connection is about 111
    > megabytes per second.
    >
    > Naturally, I did some tests with a noncompressible 1 gigabyte long
    > file (fragment of some gzipped file exactly one GB long).
    >
    > My first test was to scp files from one computer on the switch to
    > another. Here, I was disappointed as the highest speed was only 22
    > megabytes per second one way and 46 another way. About 20 and 40
    > percent of maximum.




    A visit to http://www.psc.edu/networking/projects/hpn-ssh/ is in order.


    --
    #include /* I don't speak for IBM ... */
    /* Heck, I don't even speak for myself */
    /* Don't believe me ? Ask my wife :-) */
    Richard D. Latham lathamr@us.ibm.com

  18. Re: Gigabit Ethernet, and Linux -- first observations

    On Wed, 12 Sep 2007 21:57:17 -0400, Richard D. Latham wrote:
    > Ignoramus26973 writes:
    >
    >> I installed a gigabit network switch and a gigabit enabled laptop wifi
    >> adapter (with gigabit, obviously, available on ethernet ports only) in
    >> my house.
    >>
    >> Two computers in my home are connected to the switch and one (laptop)
    >> to the wifi adaptor.
    >>
    >> The highest possible speed of a gigabit connection is about 111
    >> megabytes per second.
    >>
    >> Naturally, I did some tests with a noncompressible 1 gigabyte long
    >> file (fragment of some gzipped file exactly one GB long).
    >>
    >> My first test was to scp files from one computer on the switch to
    >> another. Here, I was disappointed as the highest speed was only 22
    >> megabytes per second one way and 46 another way. About 20 and 40
    >> percent of maximum.

    >
    >
    >
    > A visit to http://www.psc.edu/networking/projects/hpn-ssh/ is in order.
    >
    >


    Looks *VERY* interesting, I am reading it right now!

    i

  19. Re: Gigabit Ethernet, and Linux -- first observations

    >On Wed, 12 Sep 2007 15:26:26 -0700, Mark Rafn wrote:

    >> You're measuring two different things: encryption speed and
    >> transmission speed.
    >> If you want encryption, you should compare with https, not http. Or if you
    >> don't want encryption, use the "none" cipher for ssh/scp.


    Ignoramus3635 wrote:
    >Does not work for me, scp says that "none" is not a valid cipher:


    Interesting. Seems OpenSSH doesn't have this without a patch, but some
    other implementations do.
    --
    Mark Rafn dagon@dagon.net

  20. Re: Gigabit Ethernet, and Linux -- first observations

    On 2007-09-13, Richard D. Latham wrote:
    > Ignoramus26973 writes:
    >
    >> I installed a gigabit network switch and a gigabit enabled laptop wifi
    >> adapter (with gigabit, obviously, available on ethernet ports only) in
    >> my house.

    [...]
    > A visit to http://www.psc.edu/networking/projects/hpn-ssh/ is in order.


    Try it by all means, but don't be surprised if it makes little difference
    on a LAN. The HPN patch gets most of it performance boost from increasing
    the SSH channel window size, but that only helps if that's the limiting
    factor. There are some other things that help (eg the scp IO buffer
    size bump gets around 3% more throughput) but the bulk probably won't
    apply to a LAN hop. If it does make a significant difference then I
    would be interested in understanding why.

    If you haven't already, try a few different ciphers. Of the standard
    ones, arcfour or blowfish-cbc will usually be the fastest but this
    depends on many things including your hardware, compiler and direction
    of the prevailing wind.

    You may also want to try OpenSSH 4.7 or newer if you haven't already.
    There are some performance improvements including reuse of the MAC
    contexts (less hash calls per packet, gives ~15% reduction in CPU usage)
    and a faster MAC algorithm (umac-64@openssh.com, maybe 15-20% faster than
    the default hmac-md5). It also has a channel window bump which is not
    as big as the HPN one and not dynamic (but unless your gigabit network has
    10s of ms of end-to-end delay then you probably won't see a difference).

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

+ Reply to Thread
Page 1 of 2 1 2 LastLast