OpenWrt Forum Archive

Topic: should SQM be set to manage eth0 with this config?

The content of this topic has been archived on 20 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

The default SQM "basic settings" have SQM Interface name set to "eth0." But looking at the following screenshot, I see as much TX traffic on eth0 as on lan.

http://i.imgur.com/C5QdMFW.png

My config has all LAN traffic routed through tun0 (it's an OpenVPN client as gateway setup), which in turn goes over wwan (I'm tunneling to the OpenVPN server over wifi, which acts as the WAN in my case).

Should I set SQM to handle some other interface than eth0?

Thanks much for any advice.

normblop wrote:

The default SQM "basic settings" have SQM Interface name set to "eth0." But looking at the following screenshot, I see as much TX traffic on eth0 as on lan.

http://i.imgur.com/C5QdMFW.png

My config has all LAN traffic routed through tun0 (it's an OpenVPN client as gateway setup), which in turn goes over wwan (I'm tunneling to the OpenVPN server over wifi, which acts as the WAN in my case).

Should I set SQM to handle some other interface than eth0?

Thanks much for any advice.

You should select the real "wan interface", preferably the deepest one, so wwan. Please try wwan anf tun0 and report back whether it works or not. SQM will also work on the outer interfaces, but the DSCP logic probably will not find the markings of encapsulated packets, so it will effectively work as 1-tier shaper (same as simplest.qos).

Best Regards
        M.

I'll try them both - right now, with simple.qos and running on eth0, it does limit bandwidth to the up/down rates I specify.

Part of my question is, depending on what interface I set, will SQM "see" the actual flows, or just the one giant flow of UDP packets for tun0? I don't understand SQM well enough to have more than a guess at the proper interface, but I would guess tun0, since by the time anything hits wwan, it's already encapsulated.

Setting SQM to operate on tun0 drastically improved bufferbloat readings on the DSLReports speed test...

normblop wrote:

Setting SQM to operate on tun0 drastically improved bufferbloat readings on the DSLReports speed test...

Okay, I guess I am a bit daft today, but your intuition seems about right, before all SQM saw was the outer UDP packets all directed to the same IP address and port, so effectively you have been running with pure codel as the fq bit in fq_codel, the fair queueing part works by spreading out the flows by src/dest IP and port/protocol information all packets have been sharing one queue. Now with SQM active on an interface where it sees the real IP headers things work better. I believe you will need to make sure that you set the correct overhead to account for the added IP/UDP headers (so probably 20+20+14 bytes, assuming IPv4), might be worthwhile to play around/test a few different overhead values and see whether it affects bufferbloat...

Best Regards
        M.

Right now I have link layer adaptation set to 'none' - how important is it to get this figure exactly right? Although I haven't tested under varying traffic conditions yet, my bufferbloat "grade" from DSLReports increased from a range of "C" to "F" to an "A" after I changed SQM to manage tun0.

normblop wrote:

Right now I have link layer adaptation set to 'none' - how important is it to get this figure exactly right? Although I haven't tested under varying traffic conditions yet, my bufferbloat "grade" from DSLReports increased from a range of "C" to "F" to an "A" after I changed SQM to manage tun0.

Each packet carries some overhead that needs to be acccounted for so that the bandwidth shaping can work well. For bulk transfers you can "emulate" that by simply reducing the shaped bandwidth, but if you then actually have say 100 Packets/second of 900 bytes each with 100 bytes per packet overhead (I am making these numbers up while I write so there are just exemplary) you end up with (900+100)*100 = 100000 bytes/second with an overhead-ignoring shaper set to 900*100 = 90000 so 10% slack. Normaly the kernel tries to be helpful and adds the per packet overhead it knows of automatically, but let's pretend it does not and see what happens when we take really small packets (say 100 bytes) and try to saturate the shaper:
90000 / 100 = 900 packets of 100 bytes each, now add the overhead to calculate the on the wire size:
900 * (100 + 100) = 180000, this is twice what the shaper was configured to so this shaper will probably not work well against bufferbloat in up- downstream devices....
       But as I said typically the kernel tries to account for that, and typically knows about the inner tcp/udp/icmp headers and yje IP header, but with your configuration I am not sure whether the shaper takes the full outer header (ethernet, IP & UDP ) into account or not...

Best Regards
        M.

Ah, I bet I know why it's working as-is - I'm sharing a link and thus have set my upstream and downstream bandwidth considerably lower than what's available, so I'm guessing any effect like you're mentioning is hidden.

normblop wrote:

Ah, I bet I know why it's working as-is - I'm sharing a link and thus have set my upstream and downstream bandwidth considerably lower than what's available, so I'm guessing any effect like you're mentioning is hidden.

Hi normblop,

most people completely ignore this issue; and probably for a reason, most real loads that saturate a link tend to use large (full MTU sized) packets and typically the un-accounted overhead is in the range between 0 and 48 bytes so the static "discounting" by simply reducing the shaper rate, by say an additional 5% probably works mostly okay as 100*48/1500 = 3.2%. Personally I dislike this as it leaves a non-obvious failure mode lurking that will be hard to debug once it triggers (with a load with lots of small packets). Figuring out which overhead to actually account for is unfortunately not straight forward...

Best Regards
        M.

The discussion might have continued from here.