Find the answer to your Linux question:
Results 1 to 7 of 7
I have an application that is receiving UDP (datagram) packets. I have a socket and have specified some (512K) size for its receive buffer. I am receiving the packets at ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Oct 2009
    Posts
    4

    Question C: How to tell whether kernel is dropping UDP packets (or size of used recv buffer)?


    I have an application that is receiving UDP (datagram) packets. I have a socket and have specified some (512K) size for its receive buffer.

    I am receiving the packets at some rate, but I want to know whether I am catching up or not. Hence, I would like to find out, from which the application, either whether the kernel is dropping incoming UDP packets (due to me not catching up) or at least the size of the receive buffer used/free (I understand that my receive buffer can be used by multiple backloged UDP packets, is that correct?).

    If it matters, I can arrange for my application to run as root.

    Thanks,

    - Igor

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,525
    There is no guarantee of delivery for UDP packets. They can be dropped anywhere between the sender and receiver. It is up to your application to request retransmission of packets you don't get. This is why there is usually some sort of sequence number or correlation id in a UDP packet so you can determine which you need to get resent. Running as root won't change this (dropping of packets) since it is part of the UDP protocol.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Oct 2009
    Posts
    4
    Rubberman, thank you for your reply. I know what level kind of service UDP provides. My question is not about that, though.

    The question is whether I can tell that my application is not catching up with the UDP packet rate that did make it to the Linux kernel. In other words, does the kernel drop UDP packets (due to insuffecient socket receive buffer) that were successfully received and DMA-transfered by NIC to a kernel buffer?

    I can live with either a counter, maintained by the kernel, of such dropped packets. Or, I can live with the amount of the receive buffer still available for incoming packets. While I do not know whether the kernel maintains the former counter, it MUST have the later value somewhere. Do you know if there is a way to access these values?

    If I cannot find either values, my alternative is not too pretty. I can only think of a periodic probing test -- sending a probe UDP packet to myself and seeing if I receive it within a reasonable amount of time (<1 sec). The theory is that once the UDP receive queue is full, a kernel will discard incoming UDP packets no matter what source they came from, until some UDP packets are received. Does that make sense?

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,525
    If the receive queue is full, then I'm sure it will start to drop packets. By a sequence number or counter, I was refering to one maintained by the application, not the kernel. TCP/IP drivers often use a circular buffer to handle packets that are received on a connection, and in the case of UDP connections additional incoming packets will definitely be dropped if there is not enough space on the buffer to put them. Remember that ethernet packets/frames are up to about 1500 bytes in size (unless you are using non-standard jumbo frames), so the circular buffer(s) will be some multiple of the maximum frame size. When you read from a connection and specify the maximum size to read, if the size is greater than a single frame, then it will pull off as many frames as are available to fill the receive buffer up to the specified size. In any case, I don't think there is such a thing as a frame counter for UDP connections. TCP protocol connections do have some sort of counter/sequence number and it will internally request a resend of a packet if one is missing, taking into account that packets can (and often do) arrive out of order.

    Note that the original NFS protocol is a UDP-based protocol. It has some sort of sequencing scheme so that the NFS client and/or server can request a resend of a missing or broken packet. The network driver has nothing to do with this.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  5. #5
    Just Joined!
    Join Date
    Oct 2009
    Posts
    4
    When you read from a connection and specify the maximum size to read, if the size is greater than a single frame, then it will pull off as many frames as are available to fill the receive buffer up to the specified size.
    When you say "When you read from a connection", do you mean the application receiving data from the kernel, or the kernel receiving data from NIC? If you mean "application receiving data from the kernel", are you sure you mean that one a single recvfrom call will get data from multiple UDP packets? My understanding of what recvfrom does it the oposite (ie it would only give you the contents of a single UDP packet), unless, of course, are you talking about IP frames and fragment reassembly.

    Another question. If a "large" UDP packet is discarded by the kernel due to insuffecient space in the socket receive buffer, would a subsequent "small" UDP packet be discarded, too, even if there is suffecient space in the buffer for it? Let's assume that NO recv/recvfrom is made by the application for this socket between the arrival of the "large" and "small" UDP packets.

  6. #6
    Just Joined!
    Join Date
    Nov 2009
    Posts
    1
    igorlord - I've written a slew of applications that recv udp traffic (market data multicast from various stock exchanes) and I initially had the same questions you pose in this thread.

    Here is what you are garunteed by the kernel / udp protocol.

    1. udp delivery is never garunteed (you knew this already)
    2. you can configure the udp buffer on your host system wide by adjusting the parameters in sysctl - specifically net.core.rmem_default,net.core.wmem_default,
    net.core.rmem_max,net.core.wmem_max (r for read, w for write buffers). Keep in mind that larger buffers mean larger potential latency as you queue traffic.
    3. You are garunteed data completness between your application and kernel...there is zero chance of data loss here unless something corrupts some serious parts of system memory

    4. the kernel maintains error counters in procfs for kerenel <-> NIC drops/errors. Depending on your kernel version/modules you will be able to see these counters per process but at the very least system wide. /proc/net/snmp (system wide) or /proc/<pid>/net/snmp for process specific values. The file is self explanatory and is updated in realtime by the kernel.

    5. the NIC maintains counters of physical network level errors that can cause data to be lost but this usually only happens in high throughput senarios that approach full line rate (usually 1Gb/s). these counters can be seen in /proc/net/dev or /proc/<pid>/net/dev


    depending on your data rates you probably dont have either of these problems. If you communicating over the internet using UDP you almost certainly lossing data in the carier networks not on your box.

  7. #7
    Just Joined!
    Join Date
    Oct 2009
    Posts
    4
    Thanks! This is great info!

    4. I have two machines. uname -a is reporting on them:
    2.6.22-6.4.5.2-smp-4g-5651944 (a cusom build)
    2.6.24-25-generic (a stock kernel)

    I do not see /proc/<pid>/net on either of them, though.

    I did find /proc/net/udp, which is reporting used rcv buffer sizes, though.

    Unfortunately, /proc/net/snmp is not too useful for me -- there are many other apps running on the box, some of which may be not listening to their incoming UDP traffic.

    I did find /proc/net/dev. Thanks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •