TCP, and clamping MSS..?
TCP, and clamping MSS..?
- Subject: TCP, and clamping MSS..?
- From: Andrew Gallatin <email@hidden>
- Date: Wed, 10 Jan 2007 16:50:19 -0500 (EST)
Most BSDs "clamp" the MSS to a multiple of MCLBYTES.
>From netinet/tcp_input.c in both darwin and and FreeBSD:
/*
* Determine a reasonable value for maxseg size.
* If the route is known, check route for mtu.
* If none, use an mss that can be handled on the outgoing
* interface without forcing IP to fragment; if bigger than
* an mbuf cluster (MCLBYTES), round down to nearest multiple of
MCLBYTES
* to utilize large mbufs. If no route is found, route has no mtu,
<....>
And in tcp_mss() FreeBSD actually does this:
tp->t_maxseg = mss;
#if (MCLBYTES & (MCLBYTES - 1)) == 0
if (mss > MCLBYTES)
mss &= ~(MCLBYTES-1);
#else
if (mss > MCLBYTES)
mss = mss / MCLBYTES * MCLBYTES;
#endif
tp->t_maxseg = mss;
Any idea why this code is missing from darwin?
While trying to get decent 10GbE jumbo frame performance numbers from
MacOSX 10.4.8 between a pair of 2.6Ghz Mac Pros, I found I was limited
to about 7Gb/s for a single threaded test, or 8.8Gb/s for a
multi-threaded test. If I manually set the MTU such that the MSS
winds up as 8192, then the single threaded performance jumps
to 8Gb/s and the multi-threaded to 9.08Gb/s. Eg:
% netperf242 -H macpro01-m -l10 -P 0
524288 524288 524288 10.00 7047.07
% sudo route change -mtu 8244 macpro01-m
change host macpro01-m
% netperf242 -H macpro01-m -l10 -P 0
524288 524288 524288 10.00 8009.17
(I'm quoting a small sample size for this email, but it is
reproducable over a large number of runs..)
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden