What's the difference between "netstat -s" and "entstat"?

I'm trying to make a general system statistical diagnostic tool, and came across the following output when experimenting with netstat and entstat:

# entstat -r ent0
Device Type: 10/100/1000 Base-TX PCI-X Adapter (14106902)
Hardware Address: 00:14:5e:b7:63:54
Elapsed Time: 0 days 0 hours 0 minutes 24 seconds

Transmit Statistics:                          Receive Statistics:
--------------------                          -------------------
Packets: 39                                   Packets: 75
Bytes: 8382                                   Bytes: 7143
Interrupts: 0                                 Interrupts: 75
Transmit Errors: 0                            Receive Errors: 0
Packets Dropped: 0                            Packets Dropped: 0
                                              Bad Packets: 0
Max Packets on S/W Transmit Queue: 3         
S/W Transmit Queue Overflow: 0
Current S/W+H/W Transmit Queue Length: 1

Broadcast Packets: 0                          Broadcast Packets: 11
Multicast Packets: 0                          Multicast Packets: 1
No Carrier Sense: 0                           CRC Errors: 0
DMA Underrun: 0                               DMA Overrun: 0
Lost CTS Errors: 0                            Alignment Errors: 0
Max Collision Errors: 0                       No Resource Errors: 0
Late Collision Errors: 0                      Receive Collision Errors: 0
Deferred: 0                                   Packet Too Short Errors: 0
SQE Test: 0                                   Packet Too Long Errors: 0
Timeout Errors: 0                             Packets Discarded by Adapter: 0
Single Collision Count: 0                     Receiver Start Count: 0
Multiple Collision Count: 0
Current HW Transmit Queue Length: 1

General Statistics:
No mbuf Errors: 0
Adapter Reset Count: 0
Adapter Data Rate: 2000
Driver Flags: Up Broadcast Running 
	Simplex 64BitSupport ChecksumOffload 
	PrivateSegment LargeSend DataRateSet 

# netstat -s -f inet
	324 total packets received
	0 bad header checksums
	0 with size smaller than minimum
	0 with data size < data length
	0 with header length < data size
	0 with data length < header length
	0 with bad options
	0 with incorrect version number
	0 fragments received
	0 fragments dropped (dup or out of space)
	0 fragments dropped after timeout
	0 packets reassembled ok
	324 packets for this host
	0 packets for unknown/unsupported protocol
	0 packets forwarded
	0 packets not forwardable
	0 redirects sent
	309 packets sent from this host
	0 packets sent with fabricated ip header
	0 output packets dropped due to no bufs, etc.
	0 output packets discarded due to no route
	0 output datagrams fragmented
	0 fragments created
	0 datagrams that can't be fragmented
	0 IP Multicast packets dropped due to no receiver
	0 successful path MTU discovery cycles
	0 path MTU rediscovery cycles attempted
	0 path MTU discovery no-response estimates
	0 path MTU discovery response timeouts
	0 path MTU discovery decreases detected
	0 path MTU discovery packets sent
	0 path MTU discovery memory allocation failures
	0 ipintrq overflows
	0 with illegal source
	0 packets processed by threads
	0 packets dropped by threads
	0 packets dropped due to the full socket receive buffer
	0 dead gateway detection packets sent
	0 dead gateway detection packet allocation failures
	0 dead gateway detection gateway allocation failures
	0 calls to icmp_error
	0 errors not generated because old message was icmp
	0 messages with bad code fields
	0 messages < minimum length
	0 bad checksums
	0 messages with bad length
	0 message responses generated
	0 messages received
	0 messages received with too few bytes
	0 messages received with bad checksum
	0 membership queries received
	0 membership queries received with invalid field(s)
	0 membership reports received
	0 membership reports received with invalid field(s)
	0 membership reports received for groups to which we belong
	0 membership reports sent
	226 packets sent
		179 data packets (20299 bytes)
		0 data packets (0 bytes) retransmitted
		41 ack-only packets (34 delayed)
		0 URG only packets
		0 window probe packets
		0 window update packets
		6 control packets
		1 large send
		1636 bytes sent using largesend
		1636 bytes is the biggest largesend
	244 packets received
		169 acks (for 20153 bytes)
		2 duplicate acks
		0 acks for unsent data
		178 packets (16645 bytes) received in-sequence
		0 completely duplicate packets (0 bytes)
		0 old duplicate packets
		0 packets with some dup. data (0 bytes duped)
		1 out-of-order packets (0 byte)
		0 packets (0 bytes) of data after window
		0 window probes
		0 window update packets
		1 packet received after close
		0 packets with bad hardware assisted checksum
		0 discarded for bad checksums
		0 discarded for bad header offset fields
		0 discarded because packet too short
		0 discarded by listeners
		0 discarded due to listener's queue full
		29 ack packet headers correctly predicted
		62 data packet headers correctly predicted
	4 connection requests
	2 connection accepts
	4 connections established (including accepts)
	7 connection closed (including 1 drops)
	0 connections with ECN capability
	0 times responded to ECN
	2 embryonic connections dropped
	169 segments updated rtt (of 172 attempts)
	0 segments with congestion window reduced bit set
	0 segments with congestion experienced bit set
	0 resends due to path MTU discovery
	0 path MTU discovery terminations due to retransmits
	0 retransmit timeouts
		0 connections dropped by rexmit timeout
	0 fast retransmits
		0 when congestion window less than 4 segments
	0 newreno retransmits
	0 times avoided false fast retransmits
	0 persist timeouts
		0 connections dropped due to persist timeout
	0 keepalive timeouts
		0 keepalive probes sent
		0 connections dropped by keepalive
	0 times SACK blocks array is extended
	0 times SACK holes array is extended
	0 packets dropped due to memory allocation failure
	0 connections in timewait reused
	0 delayed ACKs for SYN
	0 delayed ACKs for FIN
	0 send_and_disconnects
	0 spliced connections
	0 spliced connections closed
	0 spliced connections reset
	0 spliced connections timeout
	0 spliced connections persist timeout
	0 spliced connections keepalive timeout
	80 datagrams received
	0 incomplete headers
	0 bad data length fields
	0 bad checksums
	0 dropped due to no socket
	0 broadcast/multicast datagrams dropped due to no socket
	0 socket buffer overflows
	80 delivered
	80 datagrams output

Open in new window

Just looking at the number of packets received for each command, I can see a huge discrepancy between the two. Can anybody tell me why this is?
Who is Participating?
woolmilkporcConnect With a Mentor Commented:
According to IBM's docs the counters are reset to some "initial value", whatever "initial" could mean here.

And given the tiny number of packets in your example the thus tiny difference might well result from the delay between issuing the two commands.

That's because you issued entstat with the "-r" flag!
This flag resets all the statistics back to their initial values.

So it's not really surprising that the values shown by entstat are much lower than the ones shown by netstat.

The equivalent flag for netstat is  -Z...,   by the way.


rudolphmAuthor Commented:
That's what I thought at first, so I ran both reset commands before trying this experiment, and I still got those numbers.
rudolphmAuthor Commented:
Ah, ok, I see now. My problem was not considering the difference between 75 and 324 packets as "tiny." After running entstat without the -r flag repeatedly for a few seconds, I see how quickly this number can grow on our servers. Thanks!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.