Re: FreeBSD 4.x and OS-X tcp performance

From: Daniel Hartmeier (daniel_at_benzedrine.cx)
Date: 03/07/05

  • Next message: Goran Gajic: "ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd)" 
    Date: Mon, 7 Mar 2005 21:48:25 +0100
To: Charles Sprickman <spork@fasttrackmonkey.com>

    On Mon, Mar 07, 2005 at 02:04:01PM -0500, Charles Sprickman wrote:

    > Very interesting, thank you for that read of the tcpdump output. If you
    > have the time, could you post back a few lines of the tcpdump with
    > comments so that I might learn a little about what's going on? I don't
    > have the best understanding of the intricacies of tcp...

    Data is flowing only in one direction (from client to server), so we
    see the client sending payload and the server acknowledging it.

    As long as no packets are lost and the server keeps acknowledging, the
    client could send one continuous stream of maximum sized payload packets.
    However, if the server stops acknowledging, the client must stop sending
    more data once it has filled up the window advertised by the server and
    wait for the server to either acknowledge further data or increase its
    window.

    Nothing exciting happens until timestamp 16:41:29.008909 in your log.

    16:41:29.008672 client 321457:322905(1448)
    16:41:29.008751 server ack 322905 win 7240
    16:41:29.008909 client 324353:325801(1448)

    Since the log represents the server's view, the lack of segment
    324353:322905 in the log means that this packet from the client was lost
    in transit. Now the server keeps acknowledging 322905, and we expect the
    client to notice and retransmit the lost segment.

    16:41:29.009064 server ack 322905 win 7400
    16:41:29.009146 client 325801:327249(1448)
    16:41:29.009233 server ack 322905 win 8424
    16:41:29.009409 client 328697:330145(1448)
    16:41:29.009521 server ack 322905 win 9448

    The client hasn't noticed yet and is still sending further segments past
    the gap. The server is advertising increasing window sizes, probably
    because it's still draining the data up to the gap.

    Notice that there's a new gap created as 327249:328697(1448) was lost.

    16:41:29.011250 client 335937:337385(1448)
    16:41:29.011331 server ack 322905 win 14568

    Now the client has filled up the window. If it doesn't retransmit now,
    it has to stall. It can't send anymore higher segments because the
    window is full.

    16:41:29.011758 client 322905:324353(1448)

    Finally, the retransmit.

    16:41:29.011919 server ack 327249 win 10224

    Now the server acknowledges up the the second gap.

    16:41:29.021620 server ack 327249 win 13296
    ...
    16:41:29.024911 server ack 327249 win 56304

    And keeps acknowledging the same, while the window grows again. But
    nothing from the client.

    16:41:29.146218 192.168.0.40.58347 > home.manymonkeys.com.ftp: . ack 376
    win 65535 <nop,nop,timestamp 38 05665564 543875729> (DF) [tos 0x10]

    Odd, an acknowledgment on the FTP control connection just at this time.
    I don't know what that means, but it's not a coincidence, I'd bet.

    16:41:30.462822 client 327249:328697(1448)

    Now the client finally retransmitted the segment from the second gap.
    But look at the timestamp, about 1.4 seconds have passed, which is much
    too long.

    After that, things go back to normal.

    The same thing repeats nine more times throughout the connection. You
    can spot the places by comparing subsequent timestamps. You'll find the
    spots where there are >1s delays in between two packets.

    > The tcpdump was run on the server (FBSD). Later today I will gladly do
    > this again with a dump from each side.

    Before we blame the client, let's look at the dump from the client.
    Maybe the client is trying to retransmit earlier, but those packets get
    lost. It's just odd that this would happen for more than a full second.

    Daniel
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Goran Gajic: "ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd)"

    Relevant Pages

    • Re: What doesnt lend itself to OO?
      ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
      (comp.object)
    • Re: Nothing happens after freeing kernel memory
      ... I thought using BusyBox for everything possible makes it easiest for me to ... But I saw yesterday that BusyBox provides a dhcp client. ... event occurs the entire window contents for the top window (visible ... You should know that I don't have a server here. ...
      (comp.os.linux.embedded)
    • This is going straight to the pool room
      ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
      (comp.os.vms)
    • Re: Challenge: Local App to Run in TS Session??
      ... each aisle, from above, to see if this helps saturate the warehouse better. ... Microsoft MVP - Terminal Server ... Launch Navision RDP Client (preconfigured parameters auto-connects to ... to run in a non-full-screen window, because as soon as the user clicks to ...
      (microsoft.public.windows.terminal_services)
    • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
      ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
      (Full-Disclosure)