First several packets go out OK, but as soon as the card's memory 
	buffers fill up, and the driver raises OACTIVE [the driver "cheats"
	with OACTIVE much the same way that the "ed" driver does, in that 
	it only raises OACTIVE when it has actually filled all the on-card
	buffers] packets start getting dropped all over the floor [what a 
	mess!].  Quite a few packets, ranging up to the 1000's are dropped 
	before the card catches up.

	I realize that UDP is an inherently unreliable protocol, but should
	the kernel be dropping UDP packets so soon?  I don't see this happen
	when I use the HP9k, Sparc or RS6k as the sending piece of the link..

I think you're not looking hard enough if you don't see it on those machines.

There is no flow control mechanism available for UDP, and by convention
a write to a UDP socket when the output device is jammed discards the packet;
the kernel is willing to queue up some small number of mbufs on an OACTIVE
interface (usually 50, see IFQ_MAXLEN in /sys/net/if.[ch]), and after that,
they go on the floor.  An HP9000 should *certainly* be able to create UDP
packets faster than they can be transmitted, and I know that I've seen Sparcs
do that (with ttcp, even).

Indeed, in this case, the card will never "catch up" unless ttcp either exits
or swaps out, and for a long ttcp run, thousands of dropped packets aren't
too improbable.  The most important question is whether the throughput equals
the media rate:  if you're seeing thousands of dropped packets with a
throughput of 100KB/s, then the card or driver is spending way too much time
processing packets.  If you're getting 800KB/s or better, then the discards
are because you used UDP, not because the driver or card is bad.  But in
either case, discards are to be expected.