Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Nov 2001 16:22:57 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Richard Sharpe <sharpe@ns.aus.com>
Cc:        Alfred Perlstein <bright@mu.org>, rsharpe@ns.aus.com, Alexander Haderer <alexander.haderer@charite.de>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: FreeBSD performing worse than Linux?
Message-ID:  <200112010022.fB10MvZ27957@apollo.backplane.com>
References:  <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <3C07FCFF.4070008@ns.aus.com> <20011130150843.L46769@elvis.mu.org> <3C081867.9090900@ns.aus.com>

next in thread | previous in thread | raw e-mail | index | archive | help

:Hi,
:
:I think that there are two different problems here. My situation 
:involves a LAN (actually, a crossover cable).
:
:I have captured a trace of a 1 client run between the Linux driver and 
:the FreeBSD test system as well as between the Linux driver and the same 
:test system running Linux.
:
:I am noticing some interesting things. Linux uses the timestamp option 
:in all the TCP segments I have looked at, so it is sending 12 more bytes 
:per segment that FreeBSD.
:
:However, more interesting is that for small messages (less that 1460), 
:FreeBSD does not seem to delay sending ACKs, so we get the following 
:pattern:
:
:FREEBSD
:
:Driver -> Test system: 94 byte IP DG with simulated command
:Test System -> Driver: Ack after 83uS
:Test System -> Driver: Psh Ack after 29uS with 79 total bytes in IP DG
:
:LINUX
:
:Driver -> Test system: 106 byte IP DG with simulated command
:Test System -> Driver: Psh Ack after 89uS with 91 total bytes in IP DG
:
:So, as you can see, Linux seems to shave some time off each transaction 
:by avoiding sending extra ACKs.
:
:Also, what I am seeing is that neither FreeBSD nor Linux is doing ACK coalescing (if that is possible).
:
:
:While I understand that coalescing ACKs will mess up RTT calculations and SRTT a bit, it would serve to reduce the time taken until responses come back.

    Hmm.  If I ssh between two machines and use tcpdump to monitor
    the packets I see proper delayed-ack operation:

(^A - a keystroke that is not echo'd, a delayed-ack occurs)
16:15:36.673259 216.240.41.12.1025 > 216.240.41.11.22: P 200:220(20) ack 181 win 17520 (DF) [tos 0x10] 
16:15:36.766660 216.240.41.11.22 > 216.240.41.12.1025: . ack 220 win 17520 (DF) [tos 0x10] 

('a' - a keystroke that is echo'd, delayed-ack, ack is returned in echod data)
16:15:49.143239 216.240.41.12.1025 > 216.240.41.11.22: P 240:260(20) ack 181 win 17520 (DF) [tos 0x10] 
16:15:49.156878 216.240.41.11.22 > 216.240.41.12.1025: P 181:201(20) ack 260 win 17520 (DF) [tos 0x10] 
16:15:49.251975 216.240.41.12.1025 > 216.240.41.11.22: . ack 201 win 17520 (DF) [tos 0x10] 

    The timestamp could be creating an issue in your tests, though I'm not
    entirely sure what the rules are for replies to timestamped packets.

    Are you sure delayed acks are turned on on the FreeBSD box?  An actual
    tcpdump might be helpful here.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112010022.fB10MvZ27957>