Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 Dec 2001 10:08:15 +1030
From:      Richard Sharpe <sharpe@ns.aus.com>
To:        Alfred Perlstein <bright@mu.org>
Cc:        rsharpe@ns.aus.com, Matthew Dillon <dillon@apollo.backplane.com>, Alexander Haderer <alexander.haderer@charite.de>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: FreeBSD performing worse than Linux?
Message-ID:  <3C081867.9090900@ns.aus.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>

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.


What I am seeing for large transmits is the following:


FreeBSD (Test)         Linux (Driver)
                 <----  Request, 1500 bytes including request and some
			data

                <----  More segments from the request

Some ACKs       ----->
About one every two segments
                 <----  Last data segment, usually less that 1500
Lots of ACKs    ---->

one per segment

Usually with large window (ie 16020 when the max window seems to
be 16384).
Response        ---->
Less than 1500

Now, I have seen something like 10+ ACKS after the driver has finished 
sending. They appear to be one per sent segment. Then the FreeBSD system 
sends its response. The optimal would be for the FreeBSD system to delay 
the ack until it has data to send, which it probably already has.

What I see with the Linux trace is that Linux coalesces ACKs. However, 
the most I have seen it coalesce is two segments.


HTH.

-- 
Richard Sharpe, rsharpe@ns.aus.com, LPIC-1
www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba
in 24 Hours, Special Edition, Using Samba


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?3C081867.9090900>