[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [SOLVED]Re: Only 8 MB/sec write throughput with NetBSD 5.1 AMD64
> 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.
Main Index |
Thread Index |