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

[Tony Bourke <tony%vegan.net@localhost>]

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

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

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


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


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

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. 

Tony


> 
> Thor