Richard A. Steenbergen: Saturday, June 17, 2000 7:55 AM
On Sat, 17 Jun 2000, RJ Atkinson wrote:
Sounds like a filter on which product one buys. :-)
Based on those who don't support a non-standard extension? At any rate, people will buy them, and problems will ensue. :P
Currently, there are places in internal sites that are doing exactly this. What happens is, in the interests of invoice standardization, the same filter is being applied to the externally visible equipment. My personal nightmare is some tech using the wrong NIC in the wrong machine and the architecture (my responsibility area) is erroneously shown to fail. It is far safer to spec the same equipment/capability homogenously and eliminate that failure-mode <grin>.
I see its getting better though, there is more support then there used to be the last time I looked.
Uneven distribution is always an issue during technology roll-out/adoption. I expect it to take years, with some extentions being orphaned, and it could even cause some market re-alignments and new vendors to pop up... normal stuff, prior to feature commoditization.
The point is that unless everyone makes these changes, any attempt to run a higher MTU along a non-supporting path without a reliable PMTU-D mechanism will result in bloody horror.
For content replication, as differentiated from content distribution, the larger MTU should be safe. A larger than 1518 MTU won't be safe for content distribution anytime soon because the Cable Modem standards specify a 1518 MTU and cable modems are a leading way to provide high performance networking to homes.
Does anyone know if this same restriction applies to any form of DSL? If so, then this capability will rapidly become a data center internal-only usage. This will also restrict its usage on the co-lo trunks. Otherwise, we need to point at the cable-modem specs and get that changed. As alluded to previously, there are some who take the MTU=1500 issue with religious zeal. They will resist all rational argument in this. MTU values should remain a configuration parameter and should not be spec'd in the protocol... ever!
Based off 4.0-STABLE, using some work I'm doing on the FreeBSD TCP/IP stack (mainly cleaner code and a few trivial optimizations at this point, nothing earth shattering), some additional optimizations and shortcuts through the stack based on IP Flow which I'm writing, using back to back NetGear GA620s, 512k send/recvspace buffers and a 1MB socket buffer, and a really quick in-kernel ack & discard in the receiving end.
<g> You will release open-source so the Linux community can use <please>?
The last time I tried it with standard userland transfers was on back to back p3 500s which pulled about 450Mbps between a GA620 and an Intel GE.
This is much better than what I'm seeing (MTU=1500). With MTU=4096+40 I get closer. I've not tried higher MTU values because not all of my equipment supports it. Have you done any analysis of MTU=<value> vs. thoughput? If so, at what increment?
It would certainly help to be doing less packets/rateoftime though, as this is a (the?) major bottleneck.
Packet processing overhead and memory manipulation are generally the bottlenecks in hosts. There is substantial literature to this effect.
Isn't that the truth. I think of a lot of it is poorly optimized and well-planned code though.
In defense of the programmer, code dealing with a fixed MTU value can be much more efficient than code that has to discover MTU value at run-time. I suspect that this may also be the case for cable-modems. It would have a direct effect on CPU cost and therefore COGm. At a scale of 10M units, $0.001 COGm can add up to a lot of money. However, this is a transitive benefit, as CPU/RAM gets cheaper and faster. Ascend found this out with the Pipeline 25 (a lot of which they've had to replace with Pipeline 75's, under warranty, resulting in reduced profitablility, overall [to Ascend's credit, they actually did it, where warranted, at no additional consumer cost]). I don't intend this to be a defense for a fixed MTU value, I am only postulating a probable cause for its appearance in the cable-modem spec (that they are not completely irrational<g>).