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

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

  • Next message: Goran Gajic: "Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd)" 
    Date: Tue, 8 Mar 2005 18:39:07 +0100
To: Mark Tinguely <tinguely@casselton.net>

    On Tue, Mar 08, 2005 at 08:11:00AM -0600, Mark Tinguely wrote:

    > The server is not telling the client that a packet has been lost.
    > The first two ACKs are correct duplicate ACKs, but the remaining
    > ACKs coming from he server have window adjustments, so the
    > client does not treat them as duplicate ACKs coming from a packet
    > loss.

    Ah, I didn't realize that duplicates must have the same window sizes,
    that explains it.

    Now I wonder why the server should be using the same window size on
    those near duplicate ACKs. It looks like th_win is recalculated every
    time in tcp_output(), based on how full the receive buffer is (the win =
    sbspace(&so->so_rcv); statement).

    Assuming there is usually some window space left when a loss occurs, and
    the sender will continue to fill the window with some more segments
    until the dupacks should trigger a fast retransmit, why should the
    receiver not adjust its window size in every ack? This seems not to
    occur in most cases, otherwise fast retransmit would rarely work.

    In this particular case, the server is increasing the window size with
    subsequent ACKs. What does this mean? The receive buffer became less
    full so quickly? The receive buffer was enlarged?

    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: "Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd)"

    Relevant Pages

    • Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
      ... > traffic-shaping by tweaking the TCP window size field. ... the tcpdump is taken on the very box that generates the acks ... Unless the shaper is the Linux kernel itself... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Problem with a 5.2.1 system and downloading
      ... Note the last two acks you pasted were acking data ... > buffer yet, though, so the window slams shut. ... > server isn't sending any more packets for some reason, ... my 5 box never really has to catch up (most of the time its one data packet, ...
      (freebsd-hackers)
    • Re: excessive TCP duplicate acks?
      ... There are three places able to cause ACKs: ... > call tcp_output [not the case here as there are no corresponding input packets ... 3) tcp timers are misfiring or not properly dis- ... sender didn't have enough space in the window to send any more ...
      (freebsd-current)
    • Re: FreeBSD 4.x and OS-X tcp performance
      ... > The first two ACKs are correct duplicate ACKs, ... their previous window sizes in parenthesises for each line. ... There are four dup ACKs whose window field is the same as its previous ... the receiver application seems to call readwith bufsize=1024. ...
      (freebsd-net)
    • Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
      ... >> many duplicate acks that serve no purpose ... > tiny segments, and those are normal ACKs acking those segments, note ... for this real-time stream at peak times. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)