Re: [SOLVED]Re: Only 8 MB/sec write throughput with NetBSD 5.1 AMD64

On Sun, Oct 09, 2011 at 03:32:26PM -0700, Tony Bourke wrote:
> Hi All,
> 
> On 10/9/2011 2:12 PM, Thor Lancelot Simon wrote:
> >On Sun, Oct 09, 2011 at 12:19:59PM -0700, Tony Bourke wrote:
> >>changing MTU won't help really.
> >Do you have data on which to base this conclusioN?
> 
> It's been long assumed that to get better throughput, enable jumbo

Why assume?  And why trust benchmarketing (are there really any industry
publications that don't primarily engage in precisely that, any more?)
It is very, very easy to measure for yourself and see.  Note that 9K
MTU is strictly a lose unless you have a >9K hardware page size as the
SGI systems where the 9K MTU was originally used did.

I have -- many times, since network performance was my job for a long
time too -- measured, and many of those results can be found with the
NetBSD mail archive search engine or with simple Google.  Particularly
when using a kernel that doesn't support any kind of "large receive"
accelleration (NetBSD does not) an appropriate MTU size that fits,
with headers, within one or two hardware pages but is larger than 1500
will give a measurable performance benefit end-to-end (though not a very
large one) and a more measurable reduction in receiver CPU utilization.
Try it and see -- but be sure you have first eliminated other obvious
bottlenecks such as tiny TCP windows by setting appropriate socket
buffer sizes, etc.

I really can't agree with you about path MTU discovery, either.  With
proper blackhole detection (and if you don't have that, then you
should not be using path MTU discovery at all) it's plenty reliable;
and in any event, using a large local MTU won't cause a sudden magic
change of default to use the link layer MTU as the inital MTU for
remote peers anyway; only local ones.

Thor