<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: rx_fw_discards in ethtool -S in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641598#M80931</link>
    <description>A small number of discards should not be harmful.&lt;BR /&gt;&lt;BR /&gt;Currently, the number of discards is less than 0.07 % of your incoming traffic.&lt;BR /&gt;&lt;BR /&gt;Discarded packets should never cause any hardware-level issues or instability - if they do, the hardware designer has made a **major** blunder.&lt;BR /&gt;&lt;BR /&gt;The same is true at the OS level.&lt;BR /&gt;&lt;BR /&gt;At the application level, it depends on the network protocols used. A programmer can certainly write a network protocol that assumes everything is always perfect. Such a protocol would be extremely "fragile" and hard to use outside artificially perfect laboratory networks.&lt;BR /&gt;&lt;BR /&gt;The TCP protocol contains a re-transmission feature. If the application protocol is layered on top of TCP (as most are today), then from the viewpoint of the application, a discarded and re-transmitted packet would be detectable only as a slight pause in incoming data flow.&lt;BR /&gt;&lt;BR /&gt;MK</description>
    <pubDate>Thu, 03 Jun 2010 12:37:57 GMT</pubDate>
    <dc:creator>Matti_Kurkela</dc:creator>
    <dc:date>2010-06-03T12:37:57Z</dc:date>
    <item>
      <title>rx_fw_discards in ethtool -S</title>
      <link>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641597#M80930</link>
      <description>&lt;!--!*#--&gt;We are seeing (what appears to be) a server hang. A bit of investigation reveals dropped packets on the switch confirmed by netstat -i output and ethtool -S eth3 output. &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;NIC statistics:&lt;BR /&gt;     rx_bytes: 2698325014&lt;BR /&gt;     rx_error_bytes: 0&lt;BR /&gt;     tx_bytes: 165856997359&lt;BR /&gt;     tx_error_bytes: 0&lt;BR /&gt;     rx_ucast_packets: 35847530&lt;BR /&gt;     rx_mcast_packets: 1668&lt;BR /&gt;     rx_bcast_packets: 1115967&lt;BR /&gt;     tx_ucast_packets: 109345583&lt;BR /&gt;     tx_mcast_packets: 392908&lt;BR /&gt;     tx_bcast_packets: 437&lt;BR /&gt;     tx_mac_errors: 0&lt;BR /&gt;     tx_carrier_errors: 0&lt;BR /&gt;     rx_crc_errors: 0&lt;BR /&gt;     rx_align_errors: 0&lt;BR /&gt;     tx_single_collisions: 0&lt;BR /&gt;     tx_multi_collisions: 0&lt;BR /&gt;     tx_deferred: 0&lt;BR /&gt;     tx_excess_collisions: 0&lt;BR /&gt;     tx_late_collisions: 0&lt;BR /&gt;     tx_total_collisions: 0&lt;BR /&gt;     rx_fragments: 0&lt;BR /&gt;     rx_jabbers: 0&lt;BR /&gt;     rx_undersize_packets: 0&lt;BR /&gt;     rx_oversize_packets: 0&lt;BR /&gt;     rx_64_byte_packets: 157258&lt;BR /&gt;     rx_65_to_127_byte_packets: 36778216&lt;BR /&gt;     rx_128_to_255_byte_packets: 24878&lt;BR /&gt;     rx_256_to_511_byte_packets: 4795&lt;BR /&gt;     rx_512_to_1023_byte_packets: 18&lt;BR /&gt;     rx_1024_to_1522_byte_packets: 0&lt;BR /&gt;     rx_1523_to_9022_byte_packets: 0&lt;BR /&gt;     tx_64_byte_packets: 955&lt;BR /&gt;     tx_65_to_127_byte_packets: 446187&lt;BR /&gt;     tx_128_to_255_byte_packets: 51731&lt;BR /&gt;     tx_256_to_511_byte_packets: 4189&lt;BR /&gt;     tx_512_to_1023_byte_packets: 4237&lt;BR /&gt;     tx_1024_to_1522_byte_packets: 109231629&lt;BR /&gt;     tx_1523_to_9022_byte_packets: 0&lt;BR /&gt;     rx_xon_frames: 0&lt;BR /&gt;     rx_xoff_frames: 0&lt;BR /&gt;     tx_xon_frames: 0&lt;BR /&gt;     tx_xoff_frames: 0&lt;BR /&gt;     rx_mac_ctrl_frames: 0&lt;BR /&gt;     rx_filtered_packets: 581446&lt;BR /&gt;     rx_discards: 0&lt;BR /&gt;     rx_fw_discards: 24168&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;The last line rx_fw_discards corresponds to the dropped packets shown in netstat -i.&lt;BR /&gt;&lt;BR /&gt;This is a Broadcom NetXtreme II BCM5709 Gigabit Ethernet card.&lt;BR /&gt;&lt;BR /&gt;Also, I see iptables reject/drop packets (as expected), but the numbers don't match. &lt;BR /&gt;&lt;BR /&gt;Are rx_fw_discards harmful? Would they cause server/application/process issues/instability?</description>
      <pubDate>Wed, 02 Jun 2010 20:32:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641597#M80930</guid>
      <dc:creator>Utsav_1</dc:creator>
      <dc:date>2010-06-02T20:32:47Z</dc:date>
    </item>
    <item>
      <title>Re: rx_fw_discards in ethtool -S</title>
      <link>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641598#M80931</link>
      <description>A small number of discards should not be harmful.&lt;BR /&gt;&lt;BR /&gt;Currently, the number of discards is less than 0.07 % of your incoming traffic.&lt;BR /&gt;&lt;BR /&gt;Discarded packets should never cause any hardware-level issues or instability - if they do, the hardware designer has made a **major** blunder.&lt;BR /&gt;&lt;BR /&gt;The same is true at the OS level.&lt;BR /&gt;&lt;BR /&gt;At the application level, it depends on the network protocols used. A programmer can certainly write a network protocol that assumes everything is always perfect. Such a protocol would be extremely "fragile" and hard to use outside artificially perfect laboratory networks.&lt;BR /&gt;&lt;BR /&gt;The TCP protocol contains a re-transmission feature. If the application protocol is layered on top of TCP (as most are today), then from the viewpoint of the application, a discarded and re-transmitted packet would be detectable only as a slight pause in incoming data flow.&lt;BR /&gt;&lt;BR /&gt;MK</description>
      <pubDate>Thu, 03 Jun 2010 12:37:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641598#M80931</guid>
      <dc:creator>Matti_Kurkela</dc:creator>
      <dc:date>2010-06-03T12:37:57Z</dc:date>
    </item>
    <item>
      <title>Re: rx_fw_discards in ethtool -S</title>
      <link>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641599#M80932</link>
      <description>The rx_fw_discards counter means that firmware is dropping rx packets because the driver is not fast enough to retrieve these rx packets and post new buffers.  The default rx ring size is 255 and you can increase it with ethtool -G to a bigger size (1020 for example).  This usually will help.  If flow control is not already enabled, enabling it in the NIC and switch will also help.  Check with ethtool -a eth3.</description>
      <pubDate>Tue, 08 Jun 2010 06:45:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/rx-fw-discards-in-ethtool-s/m-p/4641599#M80932</guid>
      <dc:creator>michael chan_4</dc:creator>
      <dc:date>2010-06-08T06:45:04Z</dc:date>
    </item>
  </channel>
</rss>

