On 1/27/07, David Barrett <[EMAIL PROTECTED]> wrote:
Is it actually any cheaper to send a 0-byte UDP packet than to send one that is sized at the MTU?
In terms of CPU and bus burnage, small UDP packets are going to be WAAAAAY more expensive than sending/receiving large UDP packets. It isn't too hard to confirm this through simple experiments. I wrote a link emulator that ran on standard hardware a couple of years ago. I compared performance of systems sending datagrams directly from one gig card to another (direct fiber connect) with jumbo frames enabled, and compared it with the performance when the link emulator was between the two systems. I could achieve results almost indistinguishable from line-rate for UDP packets sized between about 800-9000 bytes. With datagrams less than 896 bytes, performance started to tail off, so that by the time I was down to 128-byte datagrams, I was only achieving about 85% line rate. These results make perfect sense in this setting; each time a datagram comes into the box, it must be copied from the network cards buffer, over the bus, to system memory, and then out again. Those operations cost virtually the same amount regardless of packet size, so sending packets as close to the MTU size as possible results in the highest throughput. I measured similar results with fast ethernet cards.
Is it possible that the simple overhead of sending *any* packet dwarfs the amount of time it takes to send the payload?
Yes, *especially* if there is *any* hardware at all between the systems that are communicating. Certainly, high-end routers and switches handle small packets better than the generic hardware that I targeted with my little link emulator, but you'll never escape the overhead of the operations that are required to move that data from one buffer to another, potentially doing processing on the packet header in the process (vlans, routing, et. al). Alen _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
