Paket drop diukur dengan ethtool, tcpdump dan ifconfig

Saya punya pertanyaan tentang penurunan paket.

Saya menjalankan tes untuk menentukan kapan paket drop terjadi. Saya menggunakan Spirent TestCenter melalui sakelar (diperlukan untuk mengumpulkan lalu lintas Ethernet dari 5 port ke satu tautan optik) ke server menggunakan kartu Myricom.

Saat menjalankan pengujian saya, jika laju input di bawah nilai tertentu, ethtool tidak melaporkan penurunan apa pun (kecuali drop_multicast_filtered yang bertambah pada laju yang sangat lambat). Namun, tcpdump melaporkan sejumlah paket X "dijatuhkan oleh kernel". Kemudian jika saya meningkatkan laju input, laporan ethtool turun tetapi "ifconfig eth2" tidak. Bahkan, ifconfig tampaknya tidak melaporkan penurunan paket sama sekali. Apakah mereka semua mengukur penurunan paket pada "level" yang berbeda, mis. Ethtool di level NIC, tcpdump di level kernel, dll?

Dan apakah saya benar untuk mengatakan bahwa dalam perjalanan paket yang masuk, level NIC adalah "yang disebut" tingkat pertama, kemudian kernel, kemudian aplikasi pengguna? Jadi, apakah ada penurunan paket yang kemungkinan terjadi pertama kali di NIC, lalu kernel, lalu aplikasi pengguna? Jadi jika tidak ada paket drop di NIC, tetapi paket drop di kernel, maka bottleneck bukan di NIC?

Terima kasih.

Salam, Rayne

kernel packet-loss

— Rayne
sumber

Berhati-hatilah bahwa dalam penggunaan di dunia nyata, alasan paling umum tcpdump untuk melaporkan paket "dijatuhkan oleh kernel" adalah karena Anda lupa menentukan opsi -n, dan tcpdump menjadi backlog ketika mencoba melakukan pencarian nama. Mungkin menarik untuk melihat apakah itu membuat perbedaan dengan tes Spirent Anda.

— Spiff

Terima kasih! Menambahkan opsi -n akan meningkatkan kecepatan hingga 100 Mbps. Saya juga menyadari bahwa meningkatkan nilai net.core.netdev_max_backlog dapat secara signifikan meningkatkan tingkat di mana tcpdump dapat ditangkap tanpa menjatuhkan paket.

— Rayne