linux-os (Dick Johnson) wrote:
I seem to be running into a limit of 64 queued datagrams. This isn't a data buffer size; varying the size of the datagram makes no difference in the observed queue size. If more datagrams are sent before some are read, they are silently dropped. (By "silently," I mean, "tcpdump doesn't record these as dropped packets.")
Your datagram receiver isn't keeping up with your datagram transmitter. If you increase the number of datagrams that are being queued, you will still encounter the same problem, but after more datagrams are stored.
Right -- except that my consumer is quite fast enough in the average case; it's only the worst case where it can't keep up. Extending the queue would allow it to catch up with such bursts of activity without dropping requests. The low- and mid- hanging fruit has already been picked as far as consumer optimization goes; anything remaining is quite high indeed.
In your test code, you deliberately don't receive anything for 5 seconds. What do you expect?
I expected to demonstrate the problem. :) -Jonathan - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
