slow ftp put transfer rate - Networking

This is a discussion on slow ftp put transfer rate - Networking ; Need help to solve a problem I'm having with ftp during a put operation. The transfer rate is very slow when connected to the LAN through my wireless card. When I execute a put operation to a second Linux workstation ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: slow ftp put transfer rate

  1. slow ftp put transfer rate

    Need help to solve a problem I'm having with ftp during a put operation. The
    transfer rate is very slow when connected to the LAN through my wireless
    card. When I execute a put operation to a second Linux workstation on the
    LAN of a file that is 20MBs in size it took 352 sec to complete. When I
    switched to the built-in network card of the PC the same file was put to the
    same Linux workstation in 9 sec.

    When I execute get through the wireless card it took 8.12 sec to complete
    and with the built-in network card it took 7.56 sec to complete. So,
    something is going on from the push side which I can't detect.

    There nothing special about the ftp (vsftpd-2.0.5-8) configuration and the
    defaults are uncommented. The PC is installed with FC6 / 2.6.18-1.2798.fc6.

    --
    tek



  2. Re: slow ftp put transfer rate

    When diagnosing network performance problems I generally follow this
    set of steps:

    *) check for retransmissions/lost packets up at the transport layer -
    that means netstat statistics for TCP when FTP is involved. On the
    receiver you would likely see an increasing number of out of order
    segments being received. On the sender you would see data segments
    being retransmitted and perhaps retransmission timeouts.

    *) if I see those, I try to check link-level statistics - in this case
    that would be via ethtool on linux. (lanadmin under HP-UX, kstat
    under Solaris, and knuth only knows what under Windows and the
    rest...) checking stats on the switch(es) is goodness too, the
    mechanism would be switch-specific.

    *) if the link-level statistics show lots of _late_ collisions or
    FCS/CRC errors then I look into a duplex mismatch. here is some
    boilerplate about duplex and ethernet:

    How 100Base-T Autoneg is supposed to work:

    When both sides of the link are set to autoneg, they will "negotiate"
    the duplex setting and select full-duplex if both sides can do
    full-duplex.

    If one side is hardcoded and not using autoneg, the autoneg process
    will "fail" and the side trying to autoneg is required by spec to use
    half-duplex mode.

    If one side is using half-duplex, and the other is using full-duplex,
    sorrow and woe is the usual result.

    So, the following table shows what will happen given various settings
    on each side:

    Auto Half Full

    Auto Happiness Lucky Sorrow

    Half Lucky Happiness Sorrow

    Full Sorrow Sorrow Happiness

    Happiness means that there is a good shot of everything going well.
    Lucky means that things will likely go well, but not because you did
    anything correctly Sorrow means that there _will_ be a duplex
    mis-match.

    When there is a duplex mismatch, on the side running half-duplex you
    will see various errors and probably a number of _LATE_ collisions
    ("normal" collisions don't count here). On the side running
    full-duplex you will see things like FCS errors. Note that those
    errors are not necessarily conclusive, they are simply indicators.

    Further, it is important to keep in mind that a "clean" ping (or the
    like - eg "linkloop" or default netperf TCP_RR) test result is
    inconclusive here - a duplex mismatch causes lost traffic _only_ when
    both sides of the link try to speak at the same time. A typical ping
    test, being synchronous, one at a time request/response, never tries
    to have both sides talking at the same time.

    Finally, when/if you migrate to 1000Base-T, everything has to be set
    to auto-neg anyway.


    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    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...

+ Reply to Thread