Guarda un po 'più in basso per le mie domande, ma sarei molto interessato a sentire ciò che vedi con questo monitor in esecuzione. Abbiamo tutti questi errori?
Sto davvero avendo il 65% di errori UDP o semplicemente l'incomprensione dell'output di netstat?
Ho un monitor che rileva le modifiche negli errori di netstat -s.
Ecco un blocco tipico, mostra
protocollo: #packets previous_count > now_count error_message:
Mon 30 May 2016 12:04:32 BST
udp:81339 59930 > 59949 dropped due to full socket buffers
ip:843492 36814 > 36816 with data size > data length
ip:843492 9995 > 9996 packets for unknown/unsupported protocol
ip:843492 37390 > 37399 packets received for unknown multicast group
.
tcp:555120 1082 > 1085 times recovered from bad retransmission using DSACK
udp:81359 59949 > 59964 dropped due to full socket buffers
ip:843710 36816 > 36846 with data size > data length
ip:843710 9996 > 9998 packets for unknown/unsupported protocol
ip:843710 37399 > 37406 packets received for unknown multicast group
ip6:24635 12993 > 12999 message too big failures
.
tcp:555389 1085 > 1087 times recovered from bad retransmission using DSACK
udp:81458 59964 > 60059 dropped due to full socket buffers
ip:844048 36846 > 36854 with data size > data length
ip:844048 37406 > 37412 packets received for unknown multicast group
ip6:24647 12999 > 13070 message too big failures
.
tcp:555490 951 > 952 connections dropped by rexmit timeout
tcp:555490 1087 > 1088 times recovered from bad retransmission using DSACK
udp:81473 60059 > 60069 dropped due to full socket buffers
ip:844147 36854 > 36872 with data size > data length
ip:844147 9998 > 10002 packets for unknown/unsupported protocol
ip:844147 37412 > 37420 packets received for unknown multicast group
ip6:24651 13070 > 13072 message too big failures
.
The. nella lista qui sopra mostra la pausa tra ogni iterazione, una corsa al minuto. L'ho fatto funzionare per alcuni giorni e ho fatto un bel po 'di cambiare canale, router, posizione, riavvio ecc. E sembra molto costante. Dopo il riavvio, il "drop dovuto a buffer di socket completi" era tornato prima che arrivassi persino al terminale, sebbene i contatori si fossero riavviati molto più in basso.
La mia rete è la modalità 5Ghz, quindi nessuno sembra essere su questo, il mio rapporto s / n è abbastanza buono e sto ottenendo una buona velocità (fino al mio limite di banda larga 60Mb). Ci sono pochi computer in giro che sono accesi, e il mio telefono (che ho spento senza modifiche osservate al modello).
Ho anche una MB Air qui sulla stessa rete che vede alcuni di questi (troppo grande, sconosciuto multicast, dimensione dei dati > lunghezza dei dati, protocollo sconosciuto non supportato) altrettanto regolare ma MAI qualsiasi dropped due to full socket buffers e il mio tasso per loro è abbastanza alto 20k di queste gocce in pacchetti 377k tcp, circa il 6%.
On my MBPro 11,5: netstat -m
620/1327 mbufs in use:
339 mbufs allocated to data
13 mbufs allocated to socket names and addresses
268 mbufs allocated to packet tags
707 mbufs allocated to caches
302/682 mbuf 2KB clusters in use
0/637 mbuf 4KB clusters in use
0/12 mbuf 16KB clusters in use
4566 KB allocated to network (16.7% in use)
0 KB returned to the system
0 requests for memory denied
0 requests for memory delayed
0 calls to drain routines
Questo è molto simile a quello che c'è sulla MB Air, ma che ha OSX 10.10.5 e chip wifi presumibilmente diverso. Entrambi eseguiamo Dropbox, ho LittleSnitch solo su MBPro. Nessun firewall. Entrambe le macchine risparmiano il 90% in meno di traffico di rete. Ultimi firmware di Virgin Media Superhub - So che non è grandioso, ma ...
Quello che ho cercato di scoprire è:
Sono questi errori "normali" / quanto dovrei essere preoccupato?
Come posso scoprire da dove vengono / causati?
Dove si verificano esattamente questi "buffer full socket" - in chip, kernel, ecc. Ecc. E come interpretarli?
Quanto vicino posso vedere questo tipo di dati (TCPDUMP ecc. O è non è già lì da quel momento?)
Che cosa dovrei fare dopo e quali strumenti usare?
Sono appena stato in esecuzione senza Wi-Fi ma Bluetooth al mio telefono su 3G, ottenendo ancora gli stessi schemi (piuttosto sorprendentemente!)
Il mio script mon è (anche se mi piacerebbe migliorarlo):
echo showing changes in detected network issues
while [ 0 ]
do
cp IPEnow IPElast
netstat -s | awk '/error|length|bad|overflow|failure|dropped|loss|unknown|detect/ { if ($1+0 > 0) { $1 = pre " " $1; print} }; {if (NF==1) { pre = $1 ;getline ; print pre $1}}' >IPEnow
#get changes, just list new changed values
diff --suppress-common-lines -y IPElast IPEnow | awk '{if (NF==3) {pre = $3} else {was = $2; for (i=1;$i!="|";i++) {$i = ""}; $i=was;i++;$i=">";print pre $0}}'
echo .
sleep 60
done
Miglioramenti:
ip: 23000 (+23) 6.7% di pacchetti persi
Anche la linea netstat -s dopo flag (ip: etc) è di solito, ma non in tutti i casi, utile per ridimensionare il volume del traffico; guarda kctl: sezione