1

I was recently introduced to concepts like sqm, bufferbloat and network schedulers or queueing disclipines like cake, fq_codel etc.

# tc -d qdisc

qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 0: dev eth0 root
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
qdisc mq 0: dev eth1 root
qdisc fq_codel 0: dev eth1 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
qdisc noqueue 0: dev eth0.11 root refcnt 2
qdisc ingress ffff: dev eth0.11 parent ffff:fff1 ----------------
qdisc noqueue 0: dev wlan1 root refcnt 2
qdisc noqueue 0: dev wlan0 root refcnt 2
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc noqueue 0: dev eth1.1 root refcnt 2
qdisc cake 8063: dev ifb4eth0.11 root refcnt 2 bandwidth 214Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms raw overhead 0

I found out my ISP uses non-status reporting dynamic bandwidth allocation on GPON fiber, and I suspect this causes issues when specifying a bandwidth rate on upstream/upload for a qdisc on my router that is connected via the WAN port to the ONT.

Because rates drop significantly and the under load latency is worse, than unlimited rate. I think this is because the ONT (my ISP modem) is traffic monitored by the OLT and then the rate is scaled up as it is used. I have tried very low rates like 70-90mbps out of 200mbps subscription and have tried 300mbps (a significant overhead) and got similar results to unlimited, but the latency under load was significantly worsened - And I think this is due to the rate not being "fixed"

The setup by the ISP seems unusual to me since this doesn't seem like a common issue people have with the schedulers, and I guess this setup will follow me with any provider - since if any equipment, only my ONT modem will be replaced. If I am not in control of the queue essentially, there is not much I can do to improve stability and latency under load, right?

Is it not possible to use a scheduler with a ratelimited upstream on a non-status reporting bandwidth allocated network like this one?

dza
  • 232
  • 1
  • 2
  • 16
  • 1
    Are you trying to do this from the host OS? Or is this your router output that I am looking at? – Tim_Stewart Oct 22 '20 at 19:32
  • That is the router NETGEAR R7800 with OpenWrt 19.07.4 after setting up the working download rate limit. Any attempt at limiting upload rate makes it more unstable, more ping under load and less download/upload overall. – dza Oct 22 '20 at 21:39
  • Try doing a speed test while disconnecting all other users. Make sure it is somewhat accurate to what you know the total up/down of the connection to be. Now remove 10% off of both up/down and program that into your total limit in the router for them. Let me know how that works out. – Tim_Stewart Oct 22 '20 at 22:06
  • I know. I have done all this and wired too. The problem is not configuring it. The problem is that whatever you set the upload rate to it gets worse and seems I'm battling more than one layer of QoS. ISP tells me the bursting upload is due to non-status reporting bandwidth allocation. Thats why I reach out for help they of course claim it should still be possible, but I am not convinced. If I am not in control of the queue and the ONT reprioritizes it, it seems like a lost cause. The symptoms are simply that no matter 10-30% above or below upload rate even 50% of upload rate it always worsens. – dza Oct 22 '20 at 23:01
  • It should **always be under the actual rate from the isp**. the point of creating this bottleneck is so that your router, not the ISP upstream router has control over the traffic. You can use jperf to test this device, you will need two PC's for this. Use jperf to simulate the qos traffic, the wan side will need static IP's. I gotta say though being a openwrt user myself, have you tried going back a release etc, it's not rare to have bugs in releases. – Tim_Stewart Oct 22 '20 at 23:10
  • We are on the same page. I know. But the ping under load, should be better as a result, which doesn't happen. And limiting the upload rate just slightly severely impacts both download and upload. – dza Oct 22 '20 at 23:27
  • Just a shot in the dark here, but in your qos adventure did you install multiple qos tools? It can cause issues. – Tim_Stewart Oct 22 '20 at 23:56
  • Definetily not. It's openwrt/sqm-scripts package and it's as simple as `config queue 'eth0vlan' option enabled '1' option interface 'eth0.11' option download '214000' option upload '0' option qdisc 'cake' option script 'piece_of_cake.qos' ` which translates roughly to the output above. And the effects are all lifted when disabled and equal to raw WAN network experience. – dza Oct 23 '20 at 00:03
  • https://forum.openwrt.org/t/sqm-any-other-than-upload-0-worsens-on-tagged-vlan-fiber-wan here is more info. – dza Oct 23 '20 at 00:09

0 Answers0