Question Will a transmit buffer below 128 result in packetloss ?

Sep 27, 2022
Hey everyone !
I got a few questions regarding transmit and receive buffers on my Realtek Onboard NIC that came paired with my Gigabyte b550m Ds3h motherboard
As far as I can find the specification it runs a realtek 8118(a)(s) chip

I have been plagued with some inconsistencys in my connection since I changed boards ( former board had a killer ((qualcom atheros )) onboard NIC ) now the only visible difference for me was the amount of allocatable transmit and receive buffers , the former NIC had a max. TX buffer of 1024 and a RX buffer of 2048 , now I have tried to google on how those values can impact the connection /connection reliability
Some sources suggest that a transmit buffer below 256 will result in dropped packets , and some sources even say that the TX buffer should be set to x2 the receive buffer , this cant be achieved with my current NIC as it only supports RX 512 and TX128 values

I even tried to find a way to maybe artificialy increase those buffer values and found the registry key :

But im fairly certain that this only changes the display value and not the actual buffer size ( is the onboard buffer size linked to RAM or does the chip itself have a hard set buffer limit ? )

Additional info to my system
Win 10
vega 56 GPU
ryzen 5 g5600
2x8GB Kingston ram with CL 16 (xmp)

No switches present in network , Router is an AVM 7630 AX , all cables are cat5e

so my question in short : does a transmit buffer size below 256 really result in dropped packets , does this affect UDP packets aswell and should I be investing into an intel PCIe NIC instead of using the onboard one ?
This is one of those things that you are better off leaving all at default and hope microsoft knows what they are doing.

The only time the data is placed in buffers is when something is attempting to exceed the port speed. In addition that is a huge amount of data. Most times those are 1500 byte buffers so even 100 is a huge amount of pending data.

Having lots of buffers actually can cause a new problem called bufferbloat. This is delay caused by all this data being kept in buffers. This only affects games. Games would rather have the traffic discarded rather than have the data delayed.

These buffers are for burst condition where you get a large burst of data in a short time. Both these buffers in a pc mean you have software issues. For receive buffers means the application software is not reading the data as fast as it is coming in and it can only come in at 1gbit.
For transmit it the software would be attempting to send over the port speed.
Sep 27, 2022
when you say that this would only apply in burst conditions , would this potentialy also include UDP applications like games ? as far as I understand UDP are by design smaller packets without retransmission and thus packetloss is expected to some degree since those packets are put out a lot faster , wouldnt that mean that a lot of data is pumped out in a short amount of time or are we speaking about bandwidth ?

My concern is primarily to keep the UDP transmission as loss less as possible

( also I didnt modify any registry values yet , im kinda hesitant with changing registry changes as they are often snakeoil solutions presented in ominous guides )

Also I heard that bufferbloat is really only a concern if there is another source taking up bandwidth at the same time ( say another device on the network streaming or downloading something ) is bufferbloat something I have to worry about on an unused connection ?


Indeed: stay out of the registry and do not apply any tools or utilities that offer to make registry modifications.

Registry editing is a last resort and should only be attempted after full system, data, and registry backups are in place. And known to be recoverable and readable.
You never get loss unless you max the buffer and that would mean some application was attempting to send at over 1gbit.

You are greatly over thinking this. Games use maybe 1mbit/sec of bandwidth.

In this case the bufferbloat is between application on the machine. If you were of those stupid people that runs torrents while they tried to get high performance out of a game you could have bufferbloat issues.
Sep 27, 2022
hence why I said I dont modify the registry :)
but what better way to learn then to ask ? especialy when the source material seems to be conflicting like with the transmit buffers

anyways , now that I know that I probably wont run into problems with low transmit buffers and dont have to upgrade hardware I think my questions are mostly answered
Thanks !


By design it's meant to buffer and drop. I would not recommend playing with your buffer size. I can dig up the buffer calculation if you really want but it's not going to be some magic fix. it can get you a few % extra throughput on a 24/7 congested pipe.

You can manage it with QoS. fq_codel and cake are designed to help. I wouldn't consider any other QoS besides just manually limiting traffic if you know it comes from a specific source. You would have to buy hardware specific for this. I wouldn't recommend this unless you share a low bandwidth connection with many people. Out of the box routers that have support will vary widely on throughput with QoS. I run openwrt with cake (piece of cake config) in a virtual machine on x86 cpu.

If your internet is 300+ Mbs you probably don't need QoS and you should trouble shoot other issues before spending anything. In order to manage your buffer you will lose 10-20% of your total throughput. It depends on the tradeoff for you and if your connection isn't very consistent it's not going to be shapeable. For me I don't want any of my low latency apps buffering so I use it.