Spadek pakietów mierzony za pomocą ethtool, tcpdump i ifconfig

Mam pytanie dotyczące zrzutów pakietów.

Przeprowadzam test, aby ustalić, kiedy nastąpi spadek pakietu. Używam Spirent TestCenter za pomocą przełącznika (niezbędnego do agregacji ruchu Ethernet z 5 portów do jednego łącza optycznego) do serwera za pomocą karty Myricom.

Podczas uruchamiania mojego testu, jeśli szybkość wejściowa jest niższa niż pewna wartość, ethtool nie zgłasza żadnego spadku (z wyjątkiem dropped_multicast_filtered, który zwiększa się bardzo wolno). Jednak tcpdump zgłasza X liczby pakietów „upuszczonych przez jądro”. Następnie, jeśli zwiększę szybkość wprowadzania, raporty ettool spadną, ale „ifconfig eth2” nie. W rzeczywistości ifconfig wcale nie zgłasza żadnych spadków pakietów. Czy wszystkie mierzą spadki pakietów na różnych „poziomach”, tj. Ethtool na poziomie NIC, tcpdump na poziomie jądra itp.?

Czy mam rację, mówiąc, że w podróży pakietu przychodzącego poziom karty sieciowej to „tak zwany” pierwszy poziom, potem jądro, a następnie aplikacja użytkownika? Czyli jakakolwiek utrata pakietów nastąpi najprawdopodobniej najpierw w NIC, potem w jądrze, a potem w aplikacji użytkownika? Więc jeśli nie ma spadku pakietów w NIC, ale spadek pakietów w jądrze, to wąskiego gardła nie ma w NIC?

Dziękuję Ci.

Pozdrawiam, Rayne

kernel packet-loss

— Rayne
źródło

Uważaj, że w świecie rzeczywistym najczęstszym powodem zgłaszania pakietów „porzuconych przez jądro” przez tcpdump jest to, że zapomniałeś podać opcję -n, a tcpdump jest zalegany podczas próby wyszukiwania nazw. Ciekawe może być sprawdzenie, czy ma to wpływ na test Spirent.

— Spiff

Dzięki! Dodanie opcji -n zwiększa szybkość o 100 Mb / s. Uświadomiłem sobie również, że zwiększenie wartości net.core.netdev_max_backlog może znacznie zwiększyć szybkość, z jaką tcpdump może przechwytywać bez upuszczania pakietów.

— Rayne