David Laight <david@l8s.co.uk> writes:
> On Fri, Jun 04, 2004 at 08:43:14PM -0400, Perry E. Metzger wrote:
>> Schamil Wackenhut <sw@wacke.org> writes:
>> > I did some benchmarking in my private network today, and i saw that
>> > the udp transferrate between my server(NetBSD 1.6.2/GENERIC/ipf
>> > disabled) and my firewall(OpenBSD 3.5/GENERIC/pf disabled) (both
>> > have 100mbit ethernet link) is down to only ~25MBit/s. TCP transferrate
>> > is ok (90MBit/s). What can be a reason for such slow udp traffic?
>> 
>> I'd read TCP/IP Illustrated, volume 1, to learn the answer, but
>> in general UDP tends to be pretty slow unless you implement all the
>> nice things TCP does, at which point you have TCP.
>
> On a 10M HDX local LAN segment, UDP should be faster then TCP because
> there are no acks being sent.

Not necessarily. TCP will actually often be faster unless the UDP
based protocol does TCP style congestion management. There are some
neat papers in some past SIGCOMMs about this sort of thing.

> With a large TCP window, the receiving system can have many acks
> queued to be sent by the time the cable becomes idle enough to
> send any of them - they then go out as back-to-back packets.
>
> Provided no packets are being lost UDP should be faster than TCP.
> I suspect this is one reason why NFS used TCP.

You mean UDP. Initially NFS used UDP, but it turns out that most of
the time you're better off with a TCP based implementation anyway, and
almost all modern NFSes do TCP.


-- 
Perry E. Metzger		perry@piermont.com