Stock Wi-Fi maxes out at 250 with hardware NAT.
Both FWs drop to ~200Mbit when using channels <149 for an odd reason but that's for another topic.
850-900Mbit wired both (10ms smooth average stock, 10-25ms spikey with SFE)
Will definitely run slower with background apps like adblockers/others, change your router/AP for double the headroom.
Yes with balenaEtcher to SDcard, and factory image.
Ad blockers are domain name based, they don't block IP...
You can force your clients to use the adblocker DNS address and even rewrite IP addresses when clients insist on using popular DNS servers (hijacking) assuming that they're unencrypted.
Thanks for your detailed explanation, I appreciate it.
You say I shouldn't expect ~270Mbps from OpenWrt on this device. Yet I can get it with the stock firmware. Why do you think the stock firmware can get 270Mbps but OpenWrt can't?
So far I've heard "because stock firmware is optimized" and that "OpenWrt is general purpose software" and that it is a "CPU power issue" - but those replies doesn't answer the actual question. Nobody seems to know exactly how the stock firmware is "optimized" or how OpenWrt being "general purpose" results in slower speeds. Why aren't there some efficiency optimizations by the OpenWrt developers for the Archer C7 (there apparently are for mt7621 devices)? The answer that "the hardware is the bottleneck" just isn't true since the stock firmware can get these higher speeds.
Something is obviously different in the OpenWrt code.
The closest answer so far seems to be this:
Maybe the question should be, what in the proprietary drivers has not been emulated in OpenWrt to allow the C7 to achieve the higher speeds? It appears that nobody knows or will share. If the proprietary drivers are closed source, cannot be reverse engineered and/or are intellectual property and OpenWrt just can't figure out what they're doing - then that's fair enough - but if that's the answer, then that's the answer. Again, no offense, you guys have been tremendously helpful and insightful, and I've learned a lot. I hope you don't mind me asking.
Thanks to slh for unwinding a lot of what needed unwinding in this thread...
There is a kind of offloading of some network handling tasks. This is used in the stock firmware. OWT has some similar capabilities in can access method to do that, in SOME routers.
This is what enables a processor that gets overloaded at 400-500mbits to handle a full GB.
Long time OWT and C7/A7 user, I can offer what I've been experiencinng:
On OpenWrt...
I routinely get 250-280mb over the 5ghz radio. Have seen 300 with a newer Apple phone. This was with basic firewall and NAT routing, no SQM.
I used to get my full 300mb of the cable service that I used to have over the eth connection, no problem. Never tested it faster, have heard the CPU runs out about 400mb or so as stated, if you have no SW or HW acceleration on.
I came to OpenWrt for the SQM abilities, to lower pretty bad latency on my cable net connection. Running SQM though is more work though, the C7 could only do 100-120mbit thru the wifi while also doing SQM. I think I remember 140-150mbit thru the ethernet, wifi adds overhead. You can't do SQM and use the SW/HW acceleration.
I've since gone to a tiny x86 box on OpenWrt, doing all the routing, and my C7 and A7 are dumb AP's. And I have a 940/30mbit connection now. X86 router has the horsepower to rout and SQM that fast... and the C7 is just handling wifi, but with OpenWrt with the benefit of queue management and airtime fairness improvements in the wifi. I still get a max on wifi of 250-280mb.
So thats what I'd expect you to be seeing. I'd like to know about the others faster claimed wifi speeds, like what kind of device they are connecting to. Might be I only have 1x1 and 2x2 radio interfaces, and they have a 3x3 to better utilize a C7?
Other note on the CPU speed governor comments, note sure but I believe the C7/A7 gets set to "performance" by default. You can check. If so, it runs full speed all the time, rather than slowing down when its not busy. That might make a slight difference.
I've since gone to a tiny x86 box on OpenWrt, doing all the routing, and my C7 and A7 are dumb AP's. And I have a 940/30mbit connection now. X86 router has the horsepower to rout and SQM that fast... and the C7 is just handling wifi, but with OpenWrt with the benefit of queue management and airtime fairness improvements in the wifi. I still get a max on wifi of 250-280mb.
Sorry, are you saying that you currently use the x86 box as router (running OpenWrt with SQM but no offloading) connected to a C7 for wifi as a dumb AP and you get around 940Mbps on wifi, but if you use your Archer as OpenWrt router and wifi combo you get 250-280 on wifi? Am I following correctly?
If so that's amazing and I will try setting that up. If you don't mind, what is your config like in OpenWrt? (I'm new so I'm not sure what all the settings do yet - and there are lots, as I'm finding out)
I hooked up a TP-Link RE450v2 to check it routing performance. It's running Snapshot from last week. This has the same radio as the C7v2 but slighty faster cpu (qca9563 @ 750mhz vs qca9558 @ 720mhz). Since it only has 64MB ram it's configured to use the ath10k ct-small-buffers driver. It also uses the non-ct firmware. (the CT firmware might be slightly faster but doesn't support mesh). The C7v2 ofc has better antenna and more ram, and by default is using the ct driver and ct firmware, both might be a little bit faster (or slower for that matter). It's not apples to apples but it should be close and you might find it interesting.
It's only connected to my PC at 2x2 @ 866mbit so not using the theorethical 3x3 bandwith either.
Used as an AP: About 52MBs, 416mbits
Used as a Router, software offload: About 29-30MBs, 232-240mbits.
What weird is that the second time I tested, I get only about 27MBs as AP, while still getting 29-30MBs as Router. I can't for the sake of my life hit 52MBs like I did the first time. (Even when restoring with the restore file before I started messing about). Granted , mine is on Snapshot so issues are bound to arise, but I do think the first result is what should be expected on a stable release.
For the shizzles, I also tested a RE-650v1 (M7621, dual core - 4 thread I think) I had laying around, also running snapshot, and that got avg around 60MBs in AP mode. some peaks up to 65MBs. irqbalance had a slight effect. but one core goes to 100% when approaching 60MBs. No difference between software/hardware offload. However no offload is about 5MB faster @ 65MBs (lol) ..approaching the mighty Netgear R7800 which hits 70MBs.
In Router mode it's about a steady 36-37MBs with hardware offloading, limited by one core that goes to 100% With software offloading it goes to about 50MBs. No offload @28-29MBs.
Lol, that was not expected. Hope they fix it before the next major version.
Interesting. Yeah, I noticed some weirdness yesterday as I spent a lot of time messing with my setup. I forgot we had a double NAT setup so changed the modem from router mode to bridge mode, then speeds went down from 210Mbps to around 60-80Mbps...
A hard wired connection to the modem yields around 330Mbp (our internet ISP plan is a 300Mbps connection, so this is really good). Wifi from the OpenWrt Archer was still 60-80Mbps at that point.
I had downgraded to OpenWrt v21.02.5 (because of the potential issues 22.03.4 might have with the Archer C7, as per earlier in this thread), but since then, out of curiosity, and since that report cited PPoE and I'm not using PPoE, I thought I'd go back to 22.03.4 and test the speeds. They remained a decent 210, so I stuck with 22.03.4.
I factory reset the modem and went back to router mode on it. But speeds still remained around 80 from the OpenWrt Archer.
Switching the modem to bridge mode and back seems to have messed something up.
So I downgraded back to 21.02.5 again. Wifi speeds were still 80... Hard wired ethernet to the OpenWrt router gets around 320.
Then I reset the OpenWrt config back to default (stayed on 21.02.5) which allowed me to go through and re-set the settings and test as I went. I kept packet steering off this time and chose channel 153 for wifi (was previously on 157, and saw a neighbor on 157, so chose to avoid it this time). I tested again and got around 150. Then I enabled software offloading and got 220, so I'm back to where I started, and still with double NAT. And now, for some reason, I'm seeing around 245-250Mbps!
Upgraded back to 22.03.4 and the speeds are still up around 250... No idea why, but I guess the new channel (153) and turning off packet steering helped. Not going to touch anything now since it seems good.
I guess the sum total of the changes and tweaks that resulted in the higher, 250Mbps speeds, are: channel 153 for 5ghz, packet steering off (which had previously been on throughout this entire thread), software offloading on (which had also previously been on), and v22.03.4 (with reset config back to default), factory reset the modem, behind a double NAT...
I have a cable modem connection that is 940/35mbit.
Thru my x86 router, I see just about that speed over ethernet, not wifi. And, I see about 800-850/30 when Im using SQM, which is my preference. The x86 box is doing all the routing and SQM work.
The A7/C7's are hooked thru the router, and dont have any routing load. That said, back before my x86 box, when the C7 was doing everything, I would also see up to 280mbit on wifi. I only had a 300/35 mbit connection back then, so it wasnt a good test of how much faster the ethernet out of the C7 only would be. So, routing and wifi, a C7 should be able to do 280mbit over the ac, 5ghz wifi radio.
Routing and doing Cake SQM, then a C7 can only do 100-115mbit, due to the extra work load of SQM. (actually, you can see faster, but when the CPU runs out, Cake will start skipping managing things and not do much)
No problem, @JonP, I think I finally got the config right and am happy with the 230-250 speeds now.
This sounds like around the fastest speed possible out of OpenWrt on this router. The stock TP-Link firmware clearly has some proprietary optimizations that OpenWrt does not, but that's okay, because I think the other features like being able to easily connect it to a Raspberry Pi running Pi-hole and Unbound and the ability to install a firewall such as the Banip package makes it all worthwhile.
For truly faster speeds I'll simply have to buy new hardware at some point in the future, perhaps.
After noticing some odd errors in the syslog, I turned off IPv6 and the speed has returned to the previously elusive and TP-Link exclusive realm of 270Mbps.
Who knows if it's related, but I can't say it ain't.
There was some mention of playing with the packet steering option in this thread. Would packet steering even have an effect on a single core router like the Archer C7 v2? My limited understanding of packet steering is that it works by assigning functionality to specific cores. Since the C7 only has one core, I'm not understanding how this setting could affect anything -- except by making things slower due to the extra overhead.
Sorry that thread went south, sounded like some misunderstandings got in the way there.
One thing, when I used to use my C7 as a router/wifi AP, I would see up to 280mbit wifi downloads, with IPv6 enabled. So, I think it could be likely that something got changed, to inadvertently misconfig your IPv6 setup. The odd errors in the log suggest this as well. I'd try reloading the firmware, not saving any settings to make sure there isn't some odd version to version config change and trying again.
Other thing, I would and do see speeds of 280mbit and sometimes more, without enabling the software offloading. I probably will try to see if my AP mode C7 will do better with it on, since it could lower the load on the ethernet side of things. But, probably shouldn't be a bottleneck for that level of speed, especially when it's just an AP and not routing. Or, maybe its why some say they get magic speeds way above 280? I'd like to try and figure that out, from those who are honestly seeing more...
My impression about the hardware/software offloading that is proprietary in the manufacturer's FW, is that it's mostly so the ethernet can actually hit 1Gbit like it should. How much it helps on the wifi side, not sure. I'll probably give it a benchmarking, soon.
Thanks, Jon, yeah, it was a shame about that other thread, it was exhausting, I felt attacked and vilified simply for seeking help. The speed increases I observed with my Archer C7 v2 all resulted from a few changes over time, which included, but were not limited to (and including potential misconfigurations of), packet steering, software offloading, wifi settings and channel changes, networking interface changes, and IPv6. Now, to say those changes were not responsible for the speed changes I observed are simply not true in my case. The config changes I made directly influenced the speed change each time, and reliably so. I'm not saying they will, or should, work for everybody, but they worked for me. Can I explain why my double NAT setup suddenly went from ~200Mbps to around 80 by simply turning my modem from being a router into a bridge? No, I can't. But it happened. It shouldn't have (the 'theory') but it did (the 'evidence'). I spent an entire day working on it, with three phone calls to my ISP. Was it the modem itself or OpenWrt? I still don't know. But I'm not an expert at this, just like many casual OpenWrt users.
There are lots of theories, in this thread and others, but often no actual repeatable evidence. Each situation is different, owing to the complexity (and strength) of OpenWrt. Yes, packet steering shouldn't help, but someone early in this thread suggested it and I tried it and I saw faster speeds. Coincidence? Better net connection resulting in a faster speedtest.net result that time? I don't know. Maybe it was, but the speed increase seemed to stick, so I kept packet steering on for awhile.
Based on the many threads here and on other websites about people struggling with speed issues, they also make similar changes and see results (software offloading being the most cited), but some don't.
The one thing that is consistent is that theory and experiences do not always add up - which I find surprising. One person in this thread told me he was getting "2x that speed (my 123Mbps at the time) compared to stock":
Well, his experience was partially repeatable, because software offloading helped me, but staying at v21.02.5 did not (I'm now on 22.03.4 and seeing 270Mbps again, for example). But I'm not using PPPoE, which that bug seems related to. See how one little detail can skew results? But if he went up to v22.03.4 would he see 250-270 speeds? Who knows, maybe he would, maybe he wouldn't. But he's implying he wouldn't. I can't tell him he's wrong.
I think that one of the real problems in all of this might simply be complexity, and bugs, as there are a vast number of complex settings in OpenWrt, a result of which can be bugs. To switch on and off all the settings in OpenWrt and test them all in every possible combination is obviously time consuming and cumbersome. To run a proper and conclusive test across the many different routers and different versions of OpenWrt would be beyond the scope of most casual users and project volunteers. Theory and hypothesis cannot overrule evidence and experimentation. I'm not saying OpenWrt is buggy, I'm just saying based on my experiences so far with OpenWrt, it would appear that bugs cannot be entirely ruled out. Heck, a bug was cited as a reason for me to downgrade within the first 3 posts of this thread!
The fact that you get those speeds with your settings, Jon, might have something to do with another setting change somewhere (potentially even forgotten about, like I'd done), a wifi channel change, local interference, local building materials the wifi passes through, distance from router, amount of root beer on laptop, installed packages, ethernet cable quality, or any other opaque and vague settings that may be on or off (and there are many). It may even have to do with what is communicating on a network in the background (or not). With networking there are many factors that can contribute, not just OpenWrt's config and setup. So, getting a consistent and reliable basis for comparing each other's installations has proven to be virtually impossible, because anecdotally, this should be reliable and repeatable, but in many cases here, that doesn't appear to be the case.
And speed test numbers go up and down because speed tests are not 100% reliable nor are they always concrete evidence of throughput. I understand this. I just did two tests back-to-back and saw 249 and then 278. But I'm happy with the setup now, as it generally stays over 240 now and even gets as high as 280.
One last note about the stock TP-Link firmware. I've never had anywhere near these variations in speed with it (stock is consistently very fast) and it's related to not having anywhere near as many config settings and options as there are in OpenWrt, as well as any proprietary optimizations there might be in the stock firmware. This is one of the stock firmware's strengths, but also one of OpenWrt's strengths, because, as one of the first posters in this thread pointed out, OpenWrt is more "general purpose". That implies OpenWrt has more settings, features, and functionality, but it also implies more complexity, which can result in it being harder to diagnose (and more potential bugs).
I appreciate everyone's input and observations, but, quite frankly, I don't want to change any more settings!
This is especially true of an internet-based speed test. But one can achieve a more consistent benchmarking standard by using iPerf3 from a client against a well-connected (1Gb+) host connected through the router.
Hmmm.... you know, there's a lot to learn with this stuff, and it can take time. Also, there are many, very knowledgeable and helpful people on here, you have to learn who is and who isn't. That also takes time. And, you have to be somewhat willing to read and research, both forums and documentation... to find out info and solutions. This thread, unusually, gathered a lot of inaccurate comments. Not normally how it goes. A lot of questions on why something is, or how to do something, are already out there, and can be found or asked where to look.
Testing can be tough, I've had "results" that have turned out to be my test setup (depending on internet connection) give me false or placebo results, due to variations in speed, etc. Got to have a good enough test, and do it enough times to be sure random effects aren't showing you things that aren't really there.
Yup, agreed. I did read many posts both in this forum and elsewhere online before even starting this thread. I tried different settings, as well, before posting here. And regarding testing, yes, it is important to use as consistent of a system as possible, which is what I did, even though it was just speedtest.net. Our connection is stable and consistent and worked well with that as the measurement tool. I factored all of that in and speedtest was still reliable enough to count on for these tests. The changes made were reproducible, often doing them more than once, and the results are still the same, so I'm not worried that any testing that I did was inaccurate or unreliable. But, as I've mentioned, I'm happy with the setup now and speeds are fine.
Thanks again, I do appreciate all the feedback. Even the comments that might not have been totally accurate led me down paths that I ended up learning something from.
Following up on this, here is some context in addition to @JonP's response. The packet_steering service calls this shell file: /usr/libexec/network/packet-steering.sh
Within said file, the first check is to find the number of procs in the host: NPROCS="$(grep -c "^processor.*:" /proc/cpuinfo)"
Immediately following that check is this evaluation: [ "$NPROCS" -gt 1 ] || exit
So in other words, if there are not 2 or more processors in the host, the script will literally just exit and not attempt any other actions.