On 20.03.2003 at 08:04:08, "Post, Mark K" <[EMAIL PROTECTED]> wrote:
> Yes, no, yes. I think it needs a little more than that. ;-) It's part of a router's job to fragment packets if necessary. If VM TCP/IP really has to work *that* hard to fragment packets, then it would be another argument for virtual Linux routers. By changing the MTU for a link that can handle a large MTU, you are artificially constraining that link to a lower level of performance. If we carried this thought to its logical conclusion, we would never use an MTU greater than 576 because we could never be certain that some link somewhere did not use the minimum MTU. Sure, it can be an issue if packets go through the network with the "Do Not Fragment" flag set. These won't make it through a link/device whose MTU size is smaller than the size of the packet. ISTR this is the basis of Path MTU Discovery, a process that works out the optimum MTU size for each session, but I'm not sure how widely or consistently it is implemented. It's a matter of looking at your traffic patterns. If your main traffic flow from your guests is out to the LAN, then the system overall might benefit from changing the MTU (though now your Linux guest will be making more packets, so the CTC driver will have more work to do, potentially eating up the reduced VM TCP/IP load). If the guests spend a lot of time talking amongst each other, then reducing the MTU will cause more work for the guests through unnecessary fragmentation. It's all for nought, though, if your average packet size is less than 1492 bytes anyway (very often the case). Cheers, Vic Cross
