WRT1900ACS - Still in the game?

I've got this beast on a 950/500 FTTH connection and I am currently running a snapshot of 19.07 (afraid to upgrade due to DSA not supporting multiple CPUs on this router).. and it's doing OK, but at times it feels a bit laggy now with kids' devices online (wired and wireless).

Is this near relic still a feasible player or should I be looking to update my hardware?

If possible (as I hate to throw working tech out), I'd like to squeeze all that I can from this blue-bug so looking for an image, or patch set to enable the following build, please...

  • Latest kernel
  • Multi-CPU support: CPU0 set to WAN; CPU1 set to LAN
  • Wireguard
  • banIP
  • adblock
  • Dynamic DNS
  • SQM Qos
  • Advanced Reboot

I know wifi is OK at best, however I see there's been some progress in this area recently, so any improvements there are a bonus.
NB: I'll likely get a separate AP (but that's 6mth away depending on company bonus).

The community's help and insights would be greatly appreciated.

this might be relevant:

1 Like

it won't do Wireguard at 950/500 FTTH speeds, see A Wireguard comparison DB.

a lot of people don't see any reason for doing SQM at gigabit speeds, it's also a CPU hog.

1 Like

The performance of mvebu is getting a tad marginal for full 1 GBit/s, on top of that you have all the fun with mwlwifi. If you already have it, just test how far you it goes, but it's certainly not a good buy anymore.

And there are better options these days, ranging from filogic 830 (maaaybe ipq8072a, but that's a stretch as well), rockchip, RPi4+ and foremost x86_64.

1 Like


I am familiar with Divested; great build and developer (shout out to @SkewedZeppelin)

I went back to 19.07 as I found with a single CPU running both the hardened security features and SQM pretty much cut my speeds in half, especially the ingress.

Then there was the whole kernel(?) issue that caused all devices to conform to the lowest denominator speed so I stopped playing.

I know I'll never get full 950/500, but I'd like to see how close I can get. And again, this has been an excellent (not-so-) little router so am a little attached.

I only use wireguard as a VPN for my mobile and connecting to public APs so not too worried about speed, but good reference.

may see how I go w/ SQM disabled; something's up with my build anyway as occasionally after a restart (kids messing w/ router) cake is not an optional queue discipline - comes back after a restart (or two). I do find, however, it does help w/ MS Teams quality. Maybe set it for egress only... hmm.

Let me elaborate a bit: the rationale for using AQM/traffic scheduling is IMHO independent of link rate, if your link is experiencing saturation and hence queueing an AQM will help. With higher link capacity link saturation will become (a bit) less likely (but e.g. TCP is designed to fill all pipes so will at least try to saturate any link given large enough data transfers that are not throughput limited otherwise). Also often buffers that are massively oversized for say 50 Mbps will work much better at 1000 Mbps. But in the end this is a policy decision each network admin should take for their network individually.
Whether or not SQM helps depends on the local traffic but is also easy to test... (the biggest cost for SQM is, alas, neither the AQM or the packet scheduling, but the need to use traffic shapers to get control of the bottleneck link... these are single threaded so it is quite easy to to flat out saturate a CPU with a single direction's sqm instance).
Sidenote: the wrt1900acs will not allow reliable and robust traffic shaping at ~900Mbps, last time I tried to measure my mvebu router it topped out at around 500-550 Mbps after some tweaking with packet steering, but that was a few years ago, would not be amazed that with modern OpenWrt and a few additional services the limit might have come down.
Still worth testing whether the link performs better with SQM shaping to ~500 Mbps versus no SQM at 900 Mbps... (while 100 << 1000, with my old MIPS router I shaped my link from 100/40 to ~49/29 as that was the CPU limit, but the link performed better for my use-cases with sqm at 49/29 than without SQM).


As I said try it out for yourself, in the end if you and your users are happy, you found a decent solution and that is what counts here.