David S. Miller wrote:
On Thu, 05 May 2005 13:17:31 -0700
Rick Jones <rick.jones2@xxxxxx> wrote:
I seem to recall that some of the stack defaults for SO_SNDBUF (IIRC) would
result in netperf sending 16KB at a time into the connection - once you sent the
MTU above 16K you may have started running into issues with Nagle and delayed
ACK? You could try some tests adding a test-specific -D to disable Nagle, or -C
to set TCP_CORK, or use -m to set the send size to say, 32KB.
Yes, for one don't expect reasonable behavior if the MTU is near to or less
than the send buffer size in use.
Also, many of Nagle's notions start to fall apart at such high MTU settings.
For example, all of Nagle (even with Minshall's modifications) basically define
"small packet" as anything smaller than 1 MSS.
So something to look into (besides increasing your send buffer size with jacking
up the MTU so large) is changing Nagle to use some constant. Perhaps something
like
512 bytes or smaller, or even 128 bytes or smaller.
IMO 128 is too small - 54 bytes of header to only 128 bytes of data seems
"worthy" of encountering Nagle by default. If not 1460, then 536 feels nice - I
would guess it likely was a common MSS "back in the day" when Nagle first
proposed the algorithm/heuristic - assuming of course that the intent of the
algorithm was to try to get the average header/header+data ratio to something
around 0.9 (although IIRC, none of a 537 byte send would be delayed by Nagle
since it was the size of the user's send being >= the MSS, so make that ~0.45 ?)
rick jones
|