Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a question regarding packet drops.

I am running a test to determine when packet drops occur. I'm using a Spirent TestCenter through a switch (necessary to aggregate Ethernet traffic from 5 ports to one optical link) to a server using a Myricom card.

While running my test, if the input rate is below a certain value, ethtool does not report any drop (except dropped_multicast_filtered which is incrementing at a very slow rate). However, tcpdump reports X number of packets "dropped by kernel". Then if I increase the input rate, ethtool reports drops but "ifconfig eth2" does not. In fact, ifconfig doesn't seem to report any packet drops at all. Do they all measure packet drops at different "levels", i.e. ethtool at the NIC level, tcpdump at the kernel level etc?

And am I right to say that in the journey of an incoming packet, the NIC level is the "so-called" first level, then the kernel, then the user application? So any packet drop is likely to happen first at the NIC, then the kernel, then the user application? So if there is no packet drop at the NIC, but packet drop at the kernel, then the bottleneck is not at the NIC?

Thank you.

Regards, Rayne

share|improve this question
Beware that in real-world usage, tcpdump's most common reason for reporting packets "dropped by kernel" is because you forgot to specify the -n option, and tcpdump is getting backlogged trying to do name lookups. It might be interesting to see if that makes a difference with your Spirent test. –  Spiff May 21 '10 at 6:18
Thanks! Adding a -n option does increase the rate by 100 Mbps. I also realized that increasing the net.core.netdev_max_backlog value can significantly increase the rate at which tcpdump can capture without dropping packets. –  Rayne May 24 '10 at 2:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.