Subject: Re: Slow UDP traffic
To: None <netbsd-users@NetBSD.org>
From: Marc Tooley <netbsdMLpostNO@SPAM.quake.ca>
Date: 06/10/2004 14:10:27
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
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:
(No, I'm not affiliated in any way and am not even a customer of
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.