# 10min\_fifo\_errors

**URL:** <https://community.netdata.cloud/t/10min-fifo-errors/1814>\
**Category:** Alerts\
**Created:** [October 8, 2021, 4:17pm UTC](https://community.netdata.cloud/t/10min-fifo-errors/1814 "2021-10-08T16:17:58Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tasos\_Katsoulas](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/tasos_katsoulas/32/1344_2.png) [@Tasos\_Katsoulas](https://community.netdata.cloud/u/Tasos_Katsoulas)\
**Post date:** [October 8, 2021, 4:17pm UTC](https://community.netdata.cloud/t/10min-fifo-errors/1814/1 "2021-10-08T16:17:58Z")

</div>

# 10min\_fifo\_errors

## OS: Linux

Between the IP stack and the Network Interface Controller (NIC) lies the driver queue. This queue is typically  
implemented as a FIFO ring buffer into the memory space allocated by the driver. The NIC receive frames and place them into memory as `skb_buff` data structures (Socket Buffer). We can have queues for receiving (ingress queues) and transmitting (egress queues) but these queues do not contain any actual packet data. Each queue has a pointer to the devices associated with it, and to the `skb_buff` data structures that store the ingress/egress packets. The number of frames this queue can handle is limited. Queues fill up when an interface receives packets faster than kernel can process them.

The Netdata agent monitors the number of FIFO errors (number of times an overflow occurs in the ring buffer) for a specific network interface in the last 10 minutes. This alarm is triggered when the NIC is not able to handle the peak load of incoming/outgoing packets with the current ring buffer size.

Not all NICs support FIFO queue operations.

> **See more on SKB**
>
> The SocKet Buffer (SKB), is the most fundamental data structure in the Linux networking code. Every packet sent or received is handled using this data structure. This is a large struct containing all the control information required for the packet (datagram, cell, etc).
> 
> The struct sk\_buff has the following fields to point to the specific network layer headers:
> 
> - transport\_header (previously called h) – This field points to layer 4, the transport layer (and can include tcpheader or udp header or icmp header, and more)
> 
> - network\_header (previously called nh) – This field points to layer 3, the network layer (and can include ip header or ipv6 header or arp header).
> 
> - mac\_header (previously called mac) – This field points to layer 2, the link layer.
> 
> - skb\_network\_header(skb), skb\_transport\_header(skb) and skb\_mac\_header(skb) - These return pointer to the header.

### Troubleshooting section:

> **Update the ring buffer size**
>
> 1. To view the maximum RX ring buffer size:
> 
> 2. If the values in the Pre-set maximums section are higher than in the Current hardware settings section, increase RX (or TX) ring buffer:
> 
> 3. Verify the change to make sure that you no longer receive the alarm when running the same workload. To make this permanent, you must consult your OS distribution guides.

---

<div class="post-metadata">

**Author:** ![ben](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/ben/32/2493_2.png) [@ben](https://community.netdata.cloud/u/ben)\
**Post date:** [September 27, 2023, 11:08am UTC](https://community.netdata.cloud/t/10min-fifo-errors/1814/2 "2023-09-27T11:08:49Z")

</div>

Thank you for this suggestion. I’ve maxed out to 4096 (olded network cards)

Any other tips and tricks to not get “Interface FIFO Buffer Errors”?

 ![image](https://canada1.discourse-cdn.com/flex029/uploads/netdata2/original/2X/7/7ffd9d40fd917392a32c370845cecd41cfa592c9.png)

---

<div class="post-metadata">

**Author:** ![luckman212](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/luckman212/32/3726_2.png) [@luckman212](https://community.netdata.cloud/u/luckman212)\
**Post date:** [September 3, 2025, 11:23am UTC](https://community.netdata.cloud/t/10min-fifo-errors/1814/3 "2025-09-03T11:23:42Z")

</div>

I have a Proxmox node (PVE 8.x/Debian 12) with I-226V and am getting frequent alarms about this. Not sure what to do. I just tried adjusting my TX/RX buffer size up to 1024 from the default which was 256. Will see if that helps.

```bash
ethtool -G en0 rx 1024
ethtool -G en0 tx 1024

```

Since this thread is from 2021, I tought I’d ask, has nything changed here? Any new troubleshooting steps we can take or tweaks we can try? I haven’t tried Debian 13 (Proxmox 9) yet…

---

<div class="post-metadata">

**Author:** ![luckman212](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/luckman212/32/3726_2.png) [@luckman212](https://community.netdata.cloud/u/luckman212)\
**Post date:** [September 5, 2025, 12:04pm UTC](https://community.netdata.cloud/t/10min-fifo-errors/1814/4 "2025-09-05T12:04:12Z")

</div>

I fixed my issue by disabling PCIe ASPM– adding `pcie_aspm.policy=performance` to the `GRUB_CMDLINE_LINUX_DEFAULT` boot args:

```ini
GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm.policy=performance"

```

The problem has not returned since. Hope this helps someone else!
