Hi everyone. I've been using OpenWRT for about 6 months on an Archer C7 v5. I got it because this seemed the best way to address bufferbloat and other latency issues on my 50 mbs DLS connection that my then-ISP reps were unable or unwilling to help address.
I applied one of the SQM scripts along with the interface and all was good; bufferbloat was gone. Thanks OpenWRT!
But then fiber came to my area with a different ISP and I took the opportunity to upgrade to 120 mbs fiber. Unfortunately my speed barely budged. Download speeds never approached 120 (maybe 70-80 max, occasionally) and usually much much less: 50, 40, even 20.
When I test wired in to the modem I get around the advertised 120 mbps. Seems like the slow speed has something to do with the router then.
Yes I did make sure I disabled the SQM profile, but otherwise I really don't know where to go.
I thought I should try to just restore the stock firmware but then thought I'd hail mary here to see if I can get some tips here first.
If any of you have any advice for what I should be looking at or tweaking it would be very much appreciated.
A few possibly important points:
- Router is Archer C7 V5
- OpenWRT version is 19.07.5 r11257-5090152ae3
- We occasionally have multiple devices connected though rarely all at the same time. And we aren't heavy users when it comes to bandwidth (no streaming for the most part).
Without SQM (and without software flow-offloading <-- test it, w/o SQM), the c7-v5 should be capable of roughly 175-200 MBit/s (more in speedtests, but then latencies go down the drain). With SQM enabled, this hardware can't quite keep up (and ~80 MBit/s would sound reasonable for that).
The figures above do not account for the (signficant) overhead PPPoE would induce, should you need that for your connection.
Do anyone have a fiber connection that doesn’t have a DHCP server at the ISP side?
The easiest way to see what the router can handle must be to reset the OpenWRT firmware to default settings. And then do a test run, faster than that you will never go with that router.
But to be honest, you will highly probably need a “bigger” router to handle fiber speeds with all add ons fiber speed comes with in the long run.
Thanks for your reply,
Yes I did make sure that SQM was off.
I had software flow-offloading enabled (and not hardware) and got the result below
[screenshot was not allowed a new user]
Then I turned all flow-offloading off and got this:
[screenshot was not allowed a new user]
Then I tried just wired in to the modem and got this:
It's a pretty massive difference and it seems to have something to do with the router/configuration. But I'm not sure what.
I'm not sure if PPoE would be a factor here. The modem (supplied by the ISP) has an internet out, and that's what I was plugging in to when testing "wired". The router should be receiving this and there are only a few other devices connected (currently one is watching video; everything else is basically idle)
[I had screenshots of the other speed tests but they were blocked as I'm a new user]
120 mbps seems pretty modest compared to what the router is claimed to support. And the Archer C7 is a fairly standard and well used router, which is why I got it, not knowing all that much about networking myself. It would seem strange that such a commonly used router can hardly top 30-40 mbps on a 120 mbs connection.
But maybe I'm missing something! I really don't know all that much about this and was able to get to near zero latency on my previous connection (for online guitar playing) by following instructions.
Maybe I've inadvertently set something up wrong?
The interesting question would be what your c7-v5 can achieve in that dslreports test (also always do a sanity check using at least two other/ different speedtest sites, their actual measurements don't matter, as long as they're in the same ballpark), with sqm off and software flow-offloading enabled/ disabled.
Just for reference, I own a relatively similar tl-wdr4300 (only 802.11n WLAN, only 560 MHz instead of your 750 MHz), it can achieve very choppy 175 MBit/s with software flow-offloading disabled (latencies to the hilt, so that is too much for it, but that's the figure) - enabling flow-offloading takes it to my line speed (430/220 MBit/s). While I don't want to rely on software flow-offloading and the caveats it brings, this device can take over as emergency fallback. Your 750 MHz c7-v5 should exceed those values, probably okay'ish up to 200 MBit/s (sqm will take it down to 75-80 MBit/s though). So yes, it's not fast enough for your connection with sqm - but it shouldn't be as bad as your figures suggest.
And that is why you should take the “bad setup” out of the picture and make a reset and also a clean install if you have some custom made image.
And then what speed do you get?
I doubt you get 0 latency. That is a measuring fault or not measuring at all or measuring value below lowest showable value. A really good connection to the world would be around 10-20ms latency for fiber connections.
If your computer works by connecting it to the media converter (fiber doesn’t have old analogue modem technology!) you are connected to a DHCP server at ISP. Turn of any old technology ppoe and set wan to dhcp.
That solely depends on the ISP, there are fibre ISPs which do require PPPoE even for 1 GBit/s links (yes, that's insane, but it happens).
Ok so I reset the router using the button method and re-enabled / named the WiFi networks. The interfaces were all still there. Is that typical?
Then I did the test again and got this below.
I tried on the 5GHz and 2.4 GHz network, and on Ookla speed test and got similar numbers.
I get around 115 Mbs (the advertised speed) when connected via Ethernet cable either directly from the modem or to the router.
So it seems WiFi related, but what.
Any suggestions for things I could try, or look for, would be appreciated!
I just tried now (after resetting the router) and got around 115 Mbs, the advertised speed, when wired to either the modem (I mean media converter!) directly, or to the router.
Also confirmed that PPoE is off and the WAN protocol is DHCP.
So it seems that the issue only affects WiFi, and often results in speeds that are lower than what I had previously!
Any tips on other avenues of investigation would be very appreciated!
Check WiFi speed by measuring speed from your wireless device to some local wired device - if that maxes out at the low speed then the issue is either with the routers WiFi, or the wireless devices WiFi
Have you mentioned what wireless device you are using for your testing?
Have you checked how crowded the wifi channel(s) you're using are?
WiFi speeds can be affected by many variables
Well I restored the stock TP-Link firmware and I'm consistently getting the advertised speeds over WiFi. So it was not the router, but OpenWRT, or rather something to do with how I configured it.
Well at least I have proper speeds again!
I run SQM on a C7 v2 with ingress and egress set at 98% of advertised speed.
Cake and Piece of Cake for the queue.
Link Layer Adaption turned off (Had it turned on when I was on DSL)
I get 94% of advertised speed using various speed tests (Ookla Speedtest Desktop App, DSLReports HTTP test, Waveform).
Bufferbloat score is A to A+ (5 ms or less).
Which will account for the kernel's built-in value of 14 bytes per packet overhead, which even for a cable/docsis link is wrong (should be 18 bytes). Now for a given, fixed packet size both increasing the per-packet-overhead or decreasing the shaper rate will result in less bufferbloat (while decreasing the overhead and increasing the shaper rate will result in more bufferbloat*) so if the accounted overhead is set too low it can be countered by simply selecting a smaller shaper rate.... but once the link is saturated with smaller packets this might not be true any more, see the SQM details page for numerical examples for this relationship between shaper rate and overhead.
So for maximal robustness it seems a good idea to set the per-packet-overhead >= the true per-packet-overhead on the relevant bottleneck... even though for most use cases link saturation will only happen with large packets anyway so the failure modes described above are not very likely... Personally, I prefer reliability and robustness, but that is a policy question each network admin needs to decide on...
*) This is not unconditionally true, as long as the effective rate stays below the true bottleneck rate no bufferbloat should show up, and once the effective rate is larger bufferbloat will appear, but increasing the overhead and decreasing the shaper rate results in lowering the effective rate....