“cat / proc / net / dev” e “ip -s link” mostram estatísticas diferentes. Qual deles está mentindo?

Question

Noto que /proc/net/dev diz que o eth3 tem 1753 drop s. ip -s link mostra 0 dropped . Por que existe uma diferença? De onde vêm os diferentes dados? Qual deles está correto?

Eu tirei os dados extras.

# uname -a
Linux example09 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux

# lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.4 (squeeze)
Release:        6.0.4
Codename:       squeeze

# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth3:1258629839430 12545003042    0 1753    0     0          0  10594858 6666255952912 10026428444    0    0    0     0       0          0

# ip -s link
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:17:96:0b:61 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    244248462  3955476484 0       0       0       10595400
    TX: bytes  packets  errors  dropped carrier collsns
    683632524  1436809416 0       0       0       0

    

Answer 1

Em uma máquina do Squeeze, confie em /proc/net/dev . É uma maneira mais direta e confiável de analisar os mesmos dados.

Para o caso específico da contagem ignorada, não consigo explicar o problema exato, mas posso observá-lo em outras caixas do Squeeze. Se eu me importasse, eu reportaria isso como um bug para o Debian (e sugiro que alguém faça e relate isso aqui).

Ambos usam o número do campo tx_dropped de net_device_stats . Em /proc/net/dev , a linha é gerada por dev_seq_printf_stats de net/core/dev.c .

ip , como sempre, passa pelo netlink e, mais precisamente, pelas estatísticas de dispositivos de rede, o rtnetlink. A estrutura passada para userspace, rtnl_link_stats .

A estrutura nativa usa unsigned long s, rtnetlink usa __u32 , uma conversão mais ou menos implícita é feita em copy_rtnl_link_stats .

É muito fácil pegar a versão de 32 bits sendo usada desde o início da estrutura, rx_packets: enquanto /proc/net/dev mostra 1258629839430, ip mostra 244248462, que corresponde aproximadamente aos últimos 32 bits (mais alguns mais bytes entre os comandos); mesma coisa com a contagem de pacotes.

Aqui está o processamento de números para esses dois primeiros campos:

% echo '1258629839430 % (2^32)'|bc; echo 244248462
204421702
244248462
% echo '12545003042 % (2^32)'|bc; echo 3955476484 
3955068450
3955476484

As coisas melhoraram com a introdução de IFLA_STATS64 :

• no kernel (do commit 10708f37ae729baba9b67bd134c3720709d4ae62, disponível no upstream na v2.6.35 e posterior)
• no iproute2 (do commit 8864ac9dc5bd5ce049280337deb21191673a02d0, disponível no upstream em v2.6.33-36 e posterior).

Answer 2

Na maioria dos dispositivos, / proc / net / dev é lido nos contadores de hardware. Outras estatísticas são atualizadas a partir da pilha de rede nas estruturas do dispositivo.

As quedas são mais propensas a não corresponder, pois podem ser feitas pelo hardware: o destino do pacote MAC não é nem dispositivo nem multicast, e o dispositivo não está promíscuo: o hardware descarta diretamente o pacote, a pilha nunca saberá que existia .

Finalmente, você pode estar se perguntando por que não sincronizá-los ou sempre usar as estatísticas de hardware? Quando a pilha descarta um pacote por qualquer motivo, ele não pode atualizar o contador de hardware e, para a depuração, é útil saber que você pode encontrar cada um para rastrear onde o pacote foi descartado.

Espero que isso ajude