[Bloat] Inaccurate rates with HTB/HFSC+fq_codel on router due to VLAN?

[xnor]

Hey,

please reply to the list address so that everyone can see it.


>  Just a guess, but I believe /sys/class/net/eth0.2/statistics/rx_bytes 
>shows the data before HTB/HFSC had a chance to touch the packets.
Of course. So? HTB/HFSC don't shrink packages, and since I'm only doing 
TCP and also use fq_codel it should shape ingress quite nicely to my 
configured rate.

>  it would be interesting to repeat the tests but run tcpdump on the 
>interface that delivers the traffic to the test machine on the internal 
>LAN. My prediction is that on that port you will pretty much see the 
>18000Kbps you expect.
The LAN is connected through eth0.1 which is part of a bridge interface 
br-lan (this bridge is the only other interface with an IP address 
besides eth0.2).

With 160 download connections I've just measured (also included the 
average bytes per packet, short bpp):

eth0.2: 20.3 Mbps download (~1400 bpp)
eth0: 21.6 Mbps download (~800 bpp), 19 Mbps upload (~780 bpp)
eth0.1: 18 Mbps upload (~1490 bpp)
br-lan: 18 Mbps upload (~1490 bpp)

(all numbers approx. accurate to about +/- 0.1 Mbps)

This is completely saturating the 20 Mbps link and ruins performance.

I've tested to decrease the rate to make it work in the above scenario: 
I had to back off with the rate to about 14 Mbps (!) because then, as 
you can guess, measured eth0.2 bandwidth drops to below the 20 Mbps link 
speed.

With less connections the measured eth0.2 bandwidth is closer to the 
configured 18 Mbps and so works fine..


>  This seems old, if your router is supported you might want to try lede 
>(https://lede-project.org/releases/17.01/start#), then you could also 
>use the cake qdisc which has a few new tricks up its sleeve, nicer than 
>HTB and HFSC...
I am planning to upgrade, but I highly doubt it'll help and it also 
doesn't help me clear up the confusion with what is going on here.


It's definitely shaping something. The question is: what?