UDP traffic has no intrinsic pacing.
Whether your client is ready to receive or not, your transmitter is putting out the traffic.
If the receiver's buffer fills up and the transmitter is still sending, the traffic will be dropped.
When UDP is used, you need to either pace it from a higher level (like TFTP does), or you don't care (or there's no correction) that traffic gets dropped (like streaming video or VoIP).
When I say "don't care or no corrective action" think of a VoIP phone call ... if the receiver figures out that a packet has been dropped, there's no way to get another one sent and still maintain the correct sequence .... so, for VoIP, the receiver's CODEC "fills in" the missing packet(s) by "blending" the packets before and after the one(s) that were dropped.
If there's a bunch dropped, then the receiving ear will hear a click, pop, or distortion.
What application or test are you using?
Try it with several stations at one end talking to one station at the other, and use TCP-based applications.
If you have only one pair of endpoints, then use something like FileZilla FTP and tell it to transfer a directory of several files.
Filezilla will send multiple streams at once and can pretty much fill the pipe all by itself (and give pretty good stats).
Good Luck
Scott
