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.