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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |