Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 963429 [details] Set qlen on an interface according to NM's CAPABILITIES.SPEED value Description of problem: Interfaces are created with transmit queues of 1000 packets. This is queue length perhaps is appropriate for high speed >gigabit interfaces, but not so much for lower speed interfaces, such as wifi. For wifi, such high levels of queueing can make it difficult for Upper-Layer-Protocols to detect congestion in a timely manner, and make it difficult for ULPs to properly respond with congestion avoidance algorithms. This is also known as "buffer bloat". This is a kernel default which apparently kernel devs believe they can not change, because it might cause someone's throughput somewhere to regress a little if they did. Instead, everyone else and the Internet gets to suffer. Version-Release number of selected component (if applicable): All kernels in the last decade or so. How reproducible: 100% Steps to Reproduce: 1. Ensure your Fedora Linux computer is connected and configured to connect to a wifi network. 2. Turn your Fedora Linux computer on, if it is not already on, e.g. by supplying the requisite amount of force to its power button. Actual results: The wifi network has a txqlen of 1000 configured. Expected results: Wifi interfaces should not have such ridiculously high txqlens. A NetworkManager dispatcher script might allow the problem to be alleviated somewhat by configuring the txqueuelen according to the bitrate. Though, of course, with wifi, the link bitrate tends to vary dynamically after this point, which such a script couldn't take into account. However, it would likely always give a better ball-park value for today's wifi than the hard-coded default of 1000. Perhaps something like the attached script would work?
Netdev discussion where default txqueuelen was changed: http://thread.gmane.org/gmane.linux.network/6366/focus=11785
Um, er, ah... no. While setting the txqueuelen lower does help a lot, particularly with wifi, a saner approach is to use a qdisc that auto-adjusts its limit to the available bandwidth, such as fq_codel. It is certainly my hope that one day wifi's device drivers will stop being overbuffered, AND then appropriately managed at some layer or another for the available bandwidth... at which point adjusting the txqueuelen would become pointless because stuff like fq_codel ignores it. (Admittedly 100 was a good size for 100mbit ethernet at the time, and I would support reducing it where you could reliably deduce that more queuing exists for a given device driver, or it is running at less than gigE rates) More effective than setting the txqueuelen today (on wifi specifically) is to reduce the excessive buffering in device driver AND using fq_codel (usually with a larger target (25ms) and interval (250), but the defaults for fq_codel are ok). For example the ath9k has all its queues defaulting to 123. in /sys/kernel/debug/ieee80211/phy0/ath9k# qlen_be qlen_bk qlen_vi qlen_vo vo can safely go to 2, vi, 12, be and bk 20 at a little cost in throughput at typical distances and rates but a large gain in manageable latency. And it still sucks pretty badly for a variety of other reasons. http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf https://www.youtube.com/watch?v=Wksh2DPHCDI The easy way to try fq_codel instead of pfifo_fast: do a sane benchmark like rrul_be which measures latency and throughput at the same time. sysctl -w net.core.default_qdisc = fq_codel down and up your device do a sane benchmark again. systemd is making fq_codel the default....
root@ganesha:~/git/netperf# nmcli -f CAPABILITIES dev list iface wlan0 CAPABILITIES.CARRIER-DETECT: no CAPABILITIES.SPEED: unknown I would be reluctant to ever have a txqueuelen less than 50 based on an unknown lookup.
Oops, I'd meant to have it bale out if CAPABILITIES.SPEED was not a number. Yes, fq_codel would be better.
Created attachment 963617 [details] Set qlen on an interface according to NM's CAPABILITIES.SPEED value Fix the script to check CAPABILITIES.SPEED value is a number and greater than 0 before trying to use it to calculate a txqueuelen
Created attachment 963619 [details] Set qlen on an interface according to NM's CAPABILITIES.SPEED value Set qlen on an interface according to NM's CAPABILITIES.SPEED value. Updates: Make it check CAPABILITIES.SPEED is a number and not 0. Fix an editing error in the previously submitted version.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm running Fedora 21 now, and it seems *still* to be using a FIFO by default and still to be setting an arbitrary high default qlength which is insanely high for non-high-speed links. # cat /proc/sys/net/core/default_qdisc pfifo_fast # ip link show dev wlan0 4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 00:1a:70:3b:d9:98 brd ff:ff:ff:ff:ff:ff # tc qdisc … qdisc mq 0: dev wlan0 root qdisc pfifo_fast 0: dev wlan0 parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev wlan0 parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev wlan0 parent :3 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev wlan0 parent :4 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Also, I noticed this because my qlengths went back up to 1000. When I noticed this and dug it it was because nmcli had been changed to stop accepting 'nmcli -f CAPABILITIES dev list iface <interface>'. Instead it seems the argument syntax to 'nmcli -f CAPABILITIES dev show <interface>'. That was, perhaps, a bit of a gratuitous change to make to nmcli. Anyway, either Fedora should switch to fq_codel by default, or else it should at least the qlengths to something that is not insanely high even by the standards of the local interface - as the attached NM dispatcher script does. For the love of network buffers, please do something. :)
Created attachment 1033509 [details] Set qlen on an interface according to NM's CAPABILITIES.SPEED value
So far as I know, fedora 22 switched to fq_codel throughout.
Great! It'd be nice to fix this in an update for 21 too, which will still be around a while. Was that a systemd fix?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.