[Solved] OpenWrt performance on TP-Link AC1750 Archer C7

Hardware Questions and Recommendations
#1

I have a TP-Link Archer C7 v2.0 (AC1750). I have been using the stock firmware for years and it has worked out fine. I am missing some features I'd like such as OpenVPN support and being able to see more detailed traffic history.

I had used OpenWRT on my previous router and was thinking of installing it on mine.

I am wondering if others have noticed any performance issues with the latest version of OpenWRT on this router?

Normally I would install it and, give it a try, and if the performance is not good I would revert back to the stock firmware but between work and my toddler I don't have a lot of time so I am hoping to leverage the power of the people. :slight_smile:

Any feedback or advice is appreciated.

If the performance is bad I might just buy a router with OpenWRT already on it. Hopefully there are good ones out there for less than 80.

1 Like
#2

"good" and "bad" performance is kind of relative to what you expect or need.
i'd say its good for 200mpbs routing/nat, 100 with sqm or about 20mpbs openvpn.
what kind of connection do you have?

very bad starting conditions for almost any hobby :wink:

#3

The Archer C7 is very reliable and well supported. At a price of US$40 used, it's a value, in my opinion. Like any of the decent, dual-Ethernet, single-core, 500-1000 MHz, MIPS-based routers, it will cap out somewhere around 400-500 Mbps for throughout without SQM/QoS, and somewhere below that with SQM enabled, depending on the algorithm used. It's significantly better on routing than a single-Ethernet device with a similar CPU core.

It's not a "high-end" router by any means, and at $80, there may be dual-core, ARM-based down into that price range. Those devices tend to be in the US $125-175 range, however.

Buying a router that the OEM has installed "OpenWrt" on usually results in a router with some years-old version that the OEM has modified, rather than what you'd find here. With an OEM "OpenWrt" version, you are typically at the whim of the OEM for updates, and typically can neither build nor port their source code in any meaningful way.

Archer A7 - Slower speeds than stock
#4

The 18.06.1 release is quite good on the C7v2, very stable, and performance is good on lines below 300Mbps. QoS (Cake) works very well in this build.

#5

Thanks guys. I will install it this weekend once I figure out how. The documentation is very confusing cause it looks like I have to install DD-WRT first or something. If y'all know of any clearer instructions please do share. Will give it a shot this weekend. Thanks!

#6

https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500#quick_start_guide

You should be able to flash directly to 18.06.1 from OEM firmware. Check your version number before downloading (generally v4 for "new" units, and v2.x for older units). The version is on the label on the bottom of the unit.

#7

Thanks! I will try 18.06.1 straight from OEM firmware. The confusion is because that link you posted still talks about how to install v15. Fingers crossed 18.06.1 for v2.0 from OEM works.

#8

Hello
Do you know if some of the optimizations we can find or alternatives build have already been integrated to snapshot Builds or any specific previous version ? Specifically talking some such as:

  • QoS with SQM
  • Qualcomm FastPath
  • Hardware NAT support added

Also other than the Archer C7 v2 commonly mentioned do you know if they also are available and work for newer versions like v4 and v5

#9

An Archer C7 doesn't have the CPU power to handle more than a couple hundred kbps Mbps through the kinds of SQM that people seem to be looking for.

As far as I know, current release and snapshot builds for the ar71xx platform include hardware NAT acceleration. I might be I am mistaken about but I believe that "Qualcomm FastPath" and hardware NAT acceleration are the same thing, and that you can either have hardware NAT or CPU-managed QoS/SQM, but not both.

(Please correct me if my understanding is inaccurate.)

#10

Hardware NAT and Qualcomm FastPath are not the same, the later is a mostly device independent software implementation to circumvent large parts of the netfilter code for packets it considers trusted (parts of an existing session). This is similar in its idea to flow-offloading in kernel >= 4.16 (4.14 in OpenWrt), although implemented very differently. Flow-offload also comes in two flavours, the software implementation is device agnostic and works on all targets with a recent enough kernel, the hardware implementation only exists for mt7621 so far, but ar8337n (and maybe ar8327n) and lantiq might also be supported one day.

OpenWrt only supports flow-offloading, which depends on your target being ported to kernel >= 4.14, the software based flavour is available for all devices - the hardware variant only for mt7621. Software flow-offloading is "compatible" with SQM, in the sense that you lose any kind of speedup usually expected from flow-offloading (as SQM needs to remain in charge of every packet and when exactly it will be dispatched); hardware flow-offloading can not be used with SQM.

Edit: Don't trust hadware specs (e.g. wikidevi) too much when it comes to the distinction between ar8337 and ar8337n (or ar8327 and ar8327), the difference can currently not be detected from software/ the kernel, so you need to look on the chip markings themselves (either from FCC docs or by opening your device); only the "n" variant of the chipset contains the hardware unit necessary for hardware accelerated flow-offloading (still pending a driver to be written!). E.g. the tl-wdr3600/ tl-wdr4300 do not use the n-variant, the archer c7 rev 2 does (I'm not sure about the newer hardware revisions).

2 Likes
#11

Uh, SQM performance limits are more like 100-120 Mbit- not kilobit, in my and other's experience.

#12

My error in stating "kbps" as you are right in that the Archer C7 can handle somewhere in the 100-200 Mbps range with SQM -- referenced post corrected.

#13

Yesterday I've played a bit with LEDE-Fastpath for C7 and I've got 500 Mbps or even more w/o SQM, so I think with optimal fw / kernel / driver it can be powerfull enough for most of the homes with >100 Mbps connection. Anyone of you run any C7 specific version in this scenario stable enough?

If not, which openwrt supported device can replace my C7 if I don't want to spend hundreds of $?

#14

Experience with Archer C7 covered in the thread above.

To significantly outperform an Archer C7 or devices in its class, you likely need an ARM or x86_64 / AMD64 device, which probably still puts you out of the

class and into the range of

or discrete x86_64 / AMD64 general-purpose unit configured as a router with external AP(s) (for which the Archer C7 is a reasonable option at US $40, used)

#15

We need some attention about this?:

#16

Hi intdev What is the point your making? What is pidstat? I cant be arst to read through all that thred sorry. + it's kind of a pane in the ass with my screen reader. I have the c7-v2 and it does not seem any slower on a snap shot then 18.06.2.

#17

Ok. This is performance issue. [kworker] process consumes too much CPU resource.
Stable release is no problem or okay level. But, recent SNAPSHOT release has definitely big trouble.

You can test:

  1. First install pidstat:

opkg update && opkg install sysstat

  1. Run test:

pidstat -H 2

and wait 10-20 sec... and press Ctrl - C.

Then result displayed. See kworker process % value. It must be 0.25(Very ideal) ~ 5% (actually not good, but not critical yet)

#18

As this thread is marked [Solved] and your observations are new, perhaps a new thread in the For Developers section would attract more attention to the issue. (I also think there is some recent mention of this on the OpenWrt devel mailing list.)

While you're at that, would you include when you believe the problem might have crept back in? Date is OK, as I've got several Archer C7v2 units running ath79 builds that I can test on.

#19

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.