In message <200406101410.27014.netbsdMLpostNO@SPAM.quake.ca>, Marc Tooley write
s:
>On Saturday 05 June 2004 05:49, Steven M. Bellovin wrote:
>>
>> The real question is what Schamil is trying to test.  The tcp test
>> shows that the link is working well.  For actual application use,
>> Perry is right -- there are things you need to do that slow you down
>> a lot. tcp is really *very* efficient these days; claims of its
>> inefficiency are either mythology or based on *very* old
>> implementations.
>
>TCP guarantees in-order delivery. If you relax this and one or two of 
>the other constraints TCP operates under, you can sometimes eke out 
>more speed from it if you are delivering defined, discrete chunks of 
>data like files.
>
>Also, the spectre of exponential back-off raises its head now and again. 
>If you don't care about network impact, own the networks involved, and 
>can hit them as hard as you like, there's not as much need to use an 
>exponential back-off and can probably get away with geometric or linear 
>to eke a *bit* of extra performance under ideal conditions, especially 
>if the networks drop packets.
>
>A company which seems bound and determined to apply these kinds of 
>principles to real-world networks is the following:
>
>http://www.dataexpedition.com/
>
>(No, I'm not affiliated in any way and am not even a customer of 
>theirs. :)
>
>Finally there are definitely some tricks getting optimal UDP 
>transmission out of NetBSD: buffer sizes, socket options, etc. These 
>are not set for you automatically, and I'm not surprised you're seeing 
>slower performance out of a tool like that.
>
>Mostly I've seen applications (such as vtun) shred any sane use of UDP 
>entirely and *seem* to ignore the possibility of optimising thing any 
>for relatively quicker network environments.
>

It's very hard to do better than TCP.  On an unloaded network between 
an 800 Mhz laptop and a 450 Mhz desktop (don't ask), both with Intel 
NICs, ttcp says that I'm doing 89388.32 Kbits/sec (I ran with -fk on 
the receiver for output in bits/sec, and -n20480 on the transmitter to 
get a longer sample).  So I'm already getting 90% of the possible link 
bandwidth, over a full-duplex Intel switch.  But note that that doesn't 
account for TCP, IP, and Ethernet overhead.  The TCP header is 32 bytes 
(20 bytes base plus 12 bytes of option), and the IP header is 20 bytes; 
that leaves 1448 bytes of payload.  Ethernet has 14 bytes of source and 
destination address plus, 4 bytes of CRC, and (if memory serves) 8 
bytes of preamble, for a total frame size of 1524 bytes.  My actual 
consumed bandwidth is therefore 1524/1448 * 89388.32 Kbps.  
Furthermore, a glance at ttcp.c reveals that they're using a computer 
scientist's "K", or 1024.  Multiplying it all out I see that I'm 
getting 96,337,891 bits/sec, on a 100 Mbps link.  (I haven't factored 
in the Ethernet inter-frame spacing, since I don't know what that is on 
a 100 Mbps, full-duplex link, but it has to be *something*.)

I don't care how clever your tricks are; there's just not a lot of room 
for improvement....

Yes, my test was done under near-ideal conditions; in particular, the 
network was almost completely unloaded.  But most of these tricks cause 
problems on active networks.  But the moral is simple:  measure before 
you optimize; you may find that the bottleneck is somewhere else 
entirely.

		--Steve Bellovin, http://www.research.att.com/~smb