it has become a real problem. There's several technologies in development here that Astaro and others in the networking community should be looking at.
So, this problem persisted through multiple upgrades within 9.5. The QoS would never work properly or produce good grades for bufferbloat. I ended up calling my ISP and there was an issue on my account with certain provisions being screwed up. I fixed these issues and then completely factory reset all settings after backing up my config. I now can get an A when enabling the QoS management. I now have some other concerns that I'll list below:
My cable service is capable of 380 Mbit / 25 Mbit speeds. When I set the bandwidth limiters in the router configuration...I set them to 90% of these values. So around 340 for d/l and 22 for u/l. When I test my speed with dslresports' speed test and check bufferbloat scores...I'm getting A's, but I'm also only achieving speeds of around 270 d/l at best and this occurs when I set the download limiter to 320. If I want to sacrifice some bufferbloat score and get a B, I can set my download limiter to 340 or so and I'll actually pull 297 d/l. Confused as to why I'm dropping from 380 without QoS to 270 with QoS when I have so much extra room. Is this a limit of the fq_codel algorithm at these speeds? My CPU usage and RAM usage are very low, so I don't think this is a processing issue.
Does anyone know if Sophos XG will get codel support?
Does anyone else have an example of connection as fast or faster than mine that they can vouch codel is working on? If so...what was the performance hit to your network when enabling the QoS. Were the drops as significant as mine?
Verizon has a "Fios Optimizer" which will set registry keys to take advantage of optimizations suggested by the RFC, but it does not tell you what it does, and obviously it cannot set parameters in UTM. My guess is that similar parameters can be set in UTM, but they would have to be done in the Linux shell, and I cannot tell you what values to use.
My summary of what I gained from the document: Delayed ACKs cause the sending system to back up and retransmit, causing performance loss that may be significant.
I learned all this the hard way, when I tried to establish a site-to-site tunnel between two sites that were both asymmetric.
Keep in mind that speed tests are short, and most cable networks permit peak bursts, so test rates and sustained rates may be different.
