What's the exact meaning of Send Buffer byte count in the extended netstat statistics, and why is it always bigger than Send-Q?
In other words, what's counted against the S-BCNT that's not counted against the Send-Q?
Is S-BCNT a better number to use to figure the cost to the system of a particular connection?
I run the systat -tcp command on a moderately loaded system and see something like this for a 5 second window:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average ||||||||||||
TCP Connections TCP Packets
0 connections initiated 21062 total packets sent
153 connections accepted 16291 - data
153 connections established 125 - data (retransmit by dupack)
11 connections dropped 1 - data (retransmit by sack)
0 - in embryonic state 4271 - ack-only
5 - on retransmit timeout 0 - window probes
0 - by keepalive 217 - window updates
0 - from listen queue 0 - urgent data only
148 - control
0 - resends by PMTU discovery
TCP Timers 21057 total packets received
9752 potential rtt updates 13471 - in sequence
12437 - successful 49 - completely duplicate
763 delayed acks sent 11 - with some duplicate data
140 retransmit timeouts 14 - out-of-order
0 persist timeouts 225 - duplicate acks
0 keepalive probes 12535 - acks
0 - timeouts 0 - window probes
80 - window updates
0 - bad checksum
Why is the sent ack-only number so much higher than the "delayed acks sent" number plus the dup data received numbers? What situations generate ack-only packets besides incoming data (which should go through delayed ack timer) and received dupes (immediate ack). Keepalive, I guess. But this box has no long-lived idle connections. Everything is short and furious. And there's a keepalive line item there too that says zero...
What am I missing about the tcp machine here?
I'm seeing an ICMP storm from a mobile phone netblocks belonging to "TELEFONICA MOVILES". Periodically we will get upwards of 5 million in a few seconds, all something like this:
08:12:05.740781 IP (tos 0x0, ttl 112, id 40224, offset 0, flags [none], proto ICMP (1), length 56) 200.76.88.6 > A.B.C.D: ICMP 200.39.21.96 unreachable - need to frag (mtu 250), length 36
("A.B.C.D" is my ip)
Is an mtu of 250 even possible or legal? 68? These ICMPs are connected with larger problems on our end, but I can't tell if they're a symptom, cause or just coincidence.
What does the path MTU discovery algorithm do in this case? The server is FreeBSD 7.