Odd FTP results ??!

Discussion in 'Cisco' started by SJM, Aug 17, 2004.

  1. SJM

    SJM Guest

    Hi,

    I've got an oddie going on:

    A Cisco 3640 at the remote end. 3745 this end. E1 presented 2Mbit
    International link. 100mS round trip time. Fast Ethernet LAN at
    both ends. Routers running 100Mbit Full Duplex on the FA0/0

    FTP a cisco image for the 3640 to a PC running an FTP server program
    on the
    remote LAN & get around 60KB throughput.

    FTP the same file back to a PC running an FTP server program, back the
    other
    way & get 120KB throughput. Double ?!!

    Tried this with all sorts of files & get similar results.

    Anyone got any ideas ? I have swapped hardware at one end &
    considering doing the remote... Am I missing something basic here ?

    SJ.
    SJM, Aug 17, 2004
    #1
    1. Advertising

  2. SJM

    Mirko Kulpa Guest

    SJM wrote:
    > Hi,
    >
    > I've got an oddie going on:
    >
    > A Cisco 3640 at the remote end. 3745 this end. E1 presented 2Mbit
    > International link. 100mS round trip time. Fast Ethernet LAN at
    > both ends. Routers running 100Mbit Full Duplex on the FA0/0
    >
    > FTP a cisco image for the 3640 to a PC running an FTP server program
    > on the
    > remote LAN & get around 60KB throughput.
    >
    > FTP the same file back to a PC running an FTP server program, back the
    > other
    > way & get 120KB throughput. Double ?!!
    >
    > Tried this with all sorts of files & get similar results.
    >
    > Anyone got any ideas ? I have swapped hardware at one end &
    > considering doing the remote... Am I missing something basic here ?
    >
    > SJ.


    Maybe the TCP window size is different at both stations. With a RTT of
    100ms a small tcp window can produce such effect.


    Mirko
    --
    http://uridium.net/net/guide2na - Fehlersuche in Netzwerken
    Mirko Kulpa, Aug 17, 2004
    #2
    1. Advertising

  3. SJM

    Hansang Bae Guest

    In article <>,
    says...
    > Hi,
    >
    > I've got an oddie going on:
    >
    > A Cisco 3640 at the remote end. 3745 this end. E1 presented 2Mbit
    > International link. 100mS round trip time. Fast Ethernet LAN at
    > both ends. Routers running 100Mbit Full Duplex on the FA0/0
    >
    > FTP a cisco image for the 3640 to a PC running an FTP server program
    > on the
    > remote LAN & get around 60KB throughput.
    >
    > FTP the same file back to a PC running an FTP server program, back the
    > other
    > way & get 120KB throughput. Double ?!!
    >
    > Tried this with all sorts of files & get similar results.
    >
    > Anyone got any ideas ? I have swapped hardware at one end &
    > considering doing the remote... Am I missing something basic here ?


    Typical behavior when you have differing window sizes. The guy having
    to do just the ACKs are not affected as much with a small window.


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
    Hansang Bae, Aug 18, 2004
    #3
  4. SJM

    AnyBody43 Guest

    Hansang Bae <> wrote
    > says...
    > > A Cisco 3640 at the remote end. 3745 this end. E1 presented 2Mbit
    > > International link. 100mS round trip time. Fast Ethernet LAN at
    > > both ends. Routers running 100Mbit Full Duplex on the FA0/0
    > >
    > > FTP a cisco image for the 3640 to a PC running an FTP server program
    > > on the
    > > remote LAN & get around 60KB throughput.
    > >
    > > FTP the same file back to a PC running an FTP server program, back the
    > > other
    > > way & get 120KB throughput. Double ?!!
    > >
    > > Tried this with all sorts of files & get similar results.
    > >
    > > Anyone got any ideas ? I have swapped hardware at one end &
    > > considering doing the remote... Am I missing something basic here ?

    >
    > Typical behavior when you have differing window sizes. The guy having
    > to do just the ACKs are not affected as much with a small window.


    Agreed.


    This is not a satisfactory network test. So you don't need (yet)
    to replace any hardware.

    What's wrong with 60 vs 120? What about 120 vs wire rate of say
    200? (10 bits per byte is good enough for me:)

    If you want to test network with ftp I suggest that you run several
    simultaneous sessions. Add sessions until the total data rate
    stops increasing and then you have either hit the limit of the
    wire or the ftp server or clients or something else. I would guess
    that a modern PC would easily fill 2M even with pretty crap ftp
    software.
    There is something called 3D ftp which is a multi session ftp client,
    which can fill up networks pretty good.

    It is best to use tools designed to test networks. ttcp springs to mind.
    There are other free tools too.
    Some routers have ttcp built in as an undocumented command, or
    is it documented now?

    Microsoft give away ttcp with the
    "Microsoft IPv6 Technology Preview for Windows 2000"
    It works with IP v4 too.

    Use undocumented commands on live production kit at your own risk?
    Been there, blown it's brains out. Maybe there is a reason that
    it is undocumented?

    Could also be duplex miss-match on LAN?

    The only way to figure out for sure why the throughput is limited
    in a particular case is by using a packet capture tool and examining
    the packets to see what is going on. Unless your brain is bent the
    right way for this though it can be a struggle.
    Winpcap with Windump and/or Ethereal are free and work pretty well.

    I find the TCP specs pretty opaque and it is v hard to figure out
    exactly what should be happening. It is easy though to see that the
    window sizes are sufficient using the above tools.

    In your case the TCP window size to achieve wire rate will
    need to be at least:-

    2 x .1sec x 2,000,000 bits/sec.

    400,000 bits or 50,000 bytes

    Smaller windows than this were quite common.
    MS Windows allows various adjustments.

    To investiate further search for [bandwidth delay product].

    TCP sender does stuff like:-
    - Establish session
    - Send 1 data pkt
    - :label-loop
    - When ack received and if the receivers window allows it
    send the number of packets sent last time + 1.
    - goto label-loop

    This process INEVITABLY (given long enough i.e. enough data to send)
    results in AT LEAST ONE lost packet(s). Eventually the + 1 will be one
    too many for the link buffers in the path and the data in transit
    to absorb.

    In the meantime the TCP runs various lost packet detectors.
    When it detect a lost packet it backs off the number of packets
    sent with each ack. Then ramps up again until - you guessed it -
    more packets are lost.

    Notice that lost packets are therefore a NORMAL indeed essential
    part of the operation of TCP. Think of it like Ethernet collisions.
    Well maybe not, you probably find those hard to take too.
    AnyBody43, Aug 18, 2004
    #4
  5. SJM

    SJM Guest

    Thanks for the input!

    I'm getting symetrical throughput using Chariot & When I perform a Windows
    copy.

    SJ.
    SJM, Aug 19, 2004
    #5
  6. SJM

    AnyBody43 Guest

    (SJM) wrote in message news:<>...
    > Thanks for the input!
    >
    > I'm getting symetrical throughput using Chariot & When I perform a Windows
    > copy.
    >
    > SJ.


    Windows copies can be much worse than FTP.

    Use the command line and I use xcopy though copy may be less broken
    than it was (DOS days). For network load testing copy one big file.
    Multiple sessions do not add to the load since windows uses a
    single TCP session for all SMB connections to a single server (I
    suspect).

    Caveat: I thnk that the following was the case for Windows 2k.

    If you use explorer there are a couple of issues. IIRC:(
    The main one is that if you copy to a remote location explorer
    wants to update the explorer window at the same time and over
    the same TCP session as it copies the file data. This may of course
    not affect single file copies but it can dramatically
    affect multi file copies. The effect is worse over high latency
    links, strictly high 'bandwidth delay product' links since the pipe
    empties every time such an update occurs and the explorer update
    involves the exchange of several small packets in what is effectively
    stop and wait mode. The SMB data block size is also different depending
    on the direction (64k vs 4k IIRC). I understand that this is designed to
    allow timely (you guessed it) explorer window updates of the remote
    directory.

    I have seen much of this documented somewhere but I can't find it
    right now.
    AnyBody43, Aug 21, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ellis_jay

    new ewido.. scan results..odd

    ellis_jay, Jul 5, 2005, in forum: Computer Support
    Replies:
    0
    Views:
    449
    ellis_jay
    Jul 5, 2005
  2. Frosty

    ftp://ftp.isc.org

    Frosty, Nov 22, 2006, in forum: Computer Support
    Replies:
    2
    Views:
    975
  3. Mike Easter

    Why can't I access ftp://ftp.isc.org/ ?

    Mike Easter, Mar 14, 2007, in forum: Computer Support
    Replies:
    10
    Views:
    793
    Vanguard
    Mar 15, 2007
  4. Replies:
    1
    Views:
    413
    Lutz Donnerhacke
    Sep 13, 2007
  5. inventor1984
    Replies:
    4
    Views:
    1,547
    Dave \Crash\ Dummy
    Dec 21, 2009
Loading...

Share This Page