TL WR1043ND V3 - Fast Path and SQM

Is there any way to get the TL WR1043ND V3 working with both Fast Path and SQM yet? I tried the September 2017 build of it and still had problems on the ingress with SQM. I was using cake and piece-of-cake with 'nat dual-srchost' and 'nat dual-dsthost' on the egress and ingress respectively, with the bandwidth set to around 85% on each. If there's not currently a way, are there plans in the future to allow them to both work together?

I believe that fast path gets fast by avoiding linux kernel infrastructure, unfortunately also those parts that sqm scripts seems to require. So while not completely impossible I would not hold my breath for concurrently functioning fast path and sqm on the same interface.

Damn, I was hoping for a fix on this. :frowning:

Thank you for the reply. I was hoping for a fix for it as well, as it would make the performance and features amazing for such an economically priced router.

1 Like

I've tested SQM with Fast Path and no matter what people say it doesn't work properly. I got rid of Fast Path and everything is working fine now.

I got SFE and SQM working on the TL WR1043ND V3. I used gwlim's September 2017 SFE build. Instead of putting SQM on eth0 I put it on eth1 and switched the roles of ingress and egress. This reduces the latency to all machines connected via ethernet and provides fairness. I have not tried adding another instance for wlan0 yet to include Wi-Fi, but in theory it should work as well. However, this will reduce LAN to LAN transfers if the instance for eth1 is enabled, but it's easy to disable when doing a large transfer. In my case I do not do many large transfers and mainly just use LAN to LAN for a media server. So for me it is not an issue.

I am currently hitting 185-190 Mbps down and 18.5-19 Mbps up with SQM and SFE. Bufferbloat is at an A on dslreports.com. I have also done downloads on multiple devices at once and fairness is there. I have also ran ping tests during the downloads and during speed tests to google.com and latency remains low. I must say I am pretty satisfied thus far.

2 Likes

What do you mean by switching ingress/egress roles?

Let me offer a guess: he means to specify the desired download speed from the internet into luci-app-sqm's upload field and the desired internet upload speed into the download field (to account for that fact that on inward facing interfaces the ingress direction is now used for data egressing to the internet).

Are we talking about asynchronus DSL ? Because there is a huge gap between Up an Down speeds in aDSL.

In a short version, on a WAN instance ingress is your downstream and egress is your upstream. On a LAN instance ingress becomes your upstream and egress becomes your downstream.

If SQM is on the WAN instance (eth0) the ingress is the incoming traffic from your ISP to the WAN and egress is the outbound traffic of from the WAN to your ISP. If SQM is on the LAN instance (eth1) the ingress is the incoming traffic from your devices to the LAN and the egress is the outgoing traffic from LAN to your devices.

eth0:
ingress -
ISP->WAN (SQM)->LAN->Device
egress -
Device->LAN->WAN (SQM)->ISP

eth1:
ingress -
Device->LAN (SQM)->WAN->ISP
egress -
ISP->WAN->LAN (SQM)->Device

1 Like

Thanks for the info. Very interesting. I'd like to try it.
Can you pls upload your cat etc/config/sqm and your network configuration ?
You can PM me if you want.