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

>=20
> Why assume?  And why trust benchmarketing (are there really any =
industry
> publications that don't primarily engage in precisely that, any more?)

One of the benchmarks I referenced wasn't from any company, just a =
curious individual in the virtualization field. The other was a test =
done by VMWare and NetApp, and they weren't comparing themselves to =
competitors, just comparing protocols that were already supported. I =
don't see how that's benchmarketing.=20

> It is very, very easy to measure for yourself and see. =20


> 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.

Do you have any references to back that up? I'm geniuinly curious.=20


>=20
> 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 spent some time searching, and came up empty. If you could point to =
any posts/tests, I'd be grateful.=20


>=20
> 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.

If you're talking about MSS clamping, I agree. But at the same time, is =
the original poster upping his MTU going to help? Unlikely, and it would =
likely complicate his network needlessly.=20

Speaking of the original poster, isn't it a shame how instead of being a =
group effort to helps users and expand our understanding, the tone =
quickly devolves into adversarial point/counterpoint battle royal? All =
we're missing is a phat beat, and we could go rap battle on this.=20

Tony


>=20
> Thor