Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
ykpark
Contributor
Jump to solution

About ethtool statistics

 

Dear all,

I have a question about ethtool statistics.

Below are the ethtool stats from Security Gateway.

The value of rx_long_byte_count continues to increase.

I want to know what these counts mean and what problems may arise.

 
 

ethtool.PNG

Thanks

0 Kudos
1 Solution

Accepted Solutions
Timothy_Hall
Legend Legend
Legend

No, rx_long_length_errors indicate the receipt of an overly large frame in excess of the MTU (this used to be called a "jabber" long ago, along with "runts" for frames that were too short) but it is 0 in this case.  I'm not completely sure what rx_long_byte_count is trying to indicate, but it always seems to match rx_bytes precisely on every system I've seen.  Unfortunately these counter names are not standardized between NIC vendors and can mean just about anything.

If I had to take a wild guess, perhaps rx_bytes indicates the number of payload/data (i.e. non-header) bytes received at the hardware NIC level off the wire, while rx_long_byte_count reports the number of payload/data bytes that actually made it up into the receive socket buffer (referenced by a ring buffer descriptor), after the DMA transfer from the NIC hardware buffer into Gaia's memory.  Perhaps "long" in this context indicates a frame that has a nonzero number of payload/data bytes. 

Obviously these two counter values should always match, and if they don't that indicates some kind of bug in the NIC driver or SoftIRQ routine that a coder would need to address.  Just a guess though...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

6 Replies
Chris_Atkinson
Employee Employee
Employee

Believe it's a somewhat redundant counter covered by rx_bytes (third row from the top).

Whereas if it were rx_long_length_errors then you'd be looking at a potential MTU issue (refer: sk115357).

CCSM R77/R80/ELITE
Hasnain_Ansari
Contributor

Seems like connected interface is getting jumbo-frame packets (A packet size more than 1500-1522 bytes) and if MTU is not set accordingly then these packets will keep dropping until the MTU is not properly configured to accept the jumbo-frames.
I don't think it's going to create an issue but it's wasting the resources.

Regards,
Hasnain Ansari

Chris_Atkinson
Employee Employee
Employee

This is incorrect in my opinion, you'll note the count of rx_bytes & rx_long_byte_count is the same value.

 

CCSM R77/R80/ELITE
Hasnain_Ansari
Contributor

As per my understanding rx_bytes is the total (good data/frames) received at the interface and rx_long_byte_count means count of jumbo frame that hit at this interface.
Why these 2 things are showing same value ? Any difference ?
Correct me if i missed something.

the_rock
Legend
Legend

I tend to agree with your assessment, as I had seen this before and thats exactly what the issue was.

Timothy_Hall
Legend Legend
Legend

No, rx_long_length_errors indicate the receipt of an overly large frame in excess of the MTU (this used to be called a "jabber" long ago, along with "runts" for frames that were too short) but it is 0 in this case.  I'm not completely sure what rx_long_byte_count is trying to indicate, but it always seems to match rx_bytes precisely on every system I've seen.  Unfortunately these counter names are not standardized between NIC vendors and can mean just about anything.

If I had to take a wild guess, perhaps rx_bytes indicates the number of payload/data (i.e. non-header) bytes received at the hardware NIC level off the wire, while rx_long_byte_count reports the number of payload/data bytes that actually made it up into the receive socket buffer (referenced by a ring buffer descriptor), after the DMA transfer from the NIC hardware buffer into Gaia's memory.  Perhaps "long" in this context indicates a frame that has a nonzero number of payload/data bytes. 

Obviously these two counter values should always match, and if they don't that indicates some kind of bug in the NIC driver or SoftIRQ routine that a coder would need to address.  Just a guess though...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events