N66U QOS for wireless Source IP or MAC not working for me.

[Deleted member 27741]

I have been having an odd issue with QOS. In order to get it to "work" I have to enter a very small download speed.

I want to use QOS on my ~150 Mbps down/10 Mbps up connection. Wireless frequency 5.0 Ghz. In order to see low pings while doing anything else, I have to enter my speed in QOS as about 10-20 down/10 up. User-defined priorities does have ack,syn,fin,rst, and icmp checked.

Does anyone use QOS for an interface and it works? Perhaps I am entering something wrong. My only QOS rule is the following:

Service name: wi-fi
Source IP or MAC: selected the ip address of the 5.0 Ghz interface (set as static address in dhcp) I wish to be at the front of the line
Destination port: empty
Protocol: any
Transferred: empty
Priority: Highest

The way I have been testing this is to test speed at speedtest.net and look at my ping to the router during the test. Also tried iperf3 from router to computer I want QOSSED. Both raise the latency of the router by hundreds of milliseconds while the connection is using little of its download capacity. Perhaps this is normal and I'm a dummy.

P.S.- upload QOS seems to function fine. If someone has QOS working on a mac address on an N66U with 374.43_32E4j9527 firmware running, let me know what black magic I am missing.

 

[ColinTaylor]

QoS should work. In fact I helped John with some of the work to get traditional QoS working again back in 2016. I was also testing it over a 5GHz connection. Hopefully something hasn't broken.

Like you, at that time I had 150Mbps download, but as explained here I ended up replacing the N66U because it couldn't do QoS at over 100Mbps. I use QoS to give my wife's laptop highest priority (so she doesn't complain that Netflix is buffering when I'm doing a massive download ).

I don't really understand what latency you're trying to prioritise. But the more traffic you put through the router the more unresponsive the router itself (the GUI, pings, SSH, etc.) will become. This doesn't effect the WAN-LAN or LAN-LAN traffic though.

 

[Deleted member 27741]

Not sure what it is, could be NVRAM corruption I suppose. I will give a clean start a shot and see if it gets better. Right now it's "fine" if I want to limit everything on the LAN to 10/10, which is what I have it at now.

Any amount of WAN traffic through the router = to or greater than about 20 Mbps/second results in wildly fluctuating pings. That cannot be right.

For the time being, the latency I want to prioritize is all traffic from one IP/computer. Similar to what you did for your wife's laptop, I presume. I thought the easiest way to do what was just as you probably did- assign the IP/MAC high priority.

I went back and checked iperf vs. WAN traffic again and the iperf is much better than WAN. My first post was wrong about that.

Should this router increase local ping by 300+ ms from 20 a Mbps WAN speedtest download? I would think even with QOS off I would not see that kind of latency spike.

 

[Deleted member 27741]

Just for funsies- here is pinging to the router from wireless with QOS enabled (20 Mb/s down bandwidth); this particular speedtest was ~10 Mbps down (up latency not shown). This latency spike does not occur (at all, no QOS) with 40 Mbps down from WAN on another LAN computer with an ethernet connection. Yes, I get 40 Mbps down out of 150 today from COX.

time=1ms TTL=64
time<1ms TTL=64
time<1ms TTL=64
time=56ms TTL=64
time=340ms TTL=64
time=424ms TTL=64
time=185ms TTL=64
time=407ms TTL=64
time=433ms TTL=64
time=193ms TTL=64
time=268ms TTL=64
time=323ms TTL=64
time=403ms TTL=64
time=427ms TTL=64
time=542ms TTL=64
time=217ms TTL=64
time=572ms TTL=64
time=526ms TTL=64
time<1ms TTL=64

Good news, however- I did test another computer that uses wireless and it does not have this kind of wild ping. Hopefully comparing the two setups will reveal the issue.

 

[ColinTaylor]

Yes that will happen as I explained above. Changing the QoS settings for things like ICMP (or anything else) will have no effect on the router's response times. QoS only effects WAN to LAN (and vice versa) traffic, not LAN to router. Try pinging something like Google.

 

[Deleted member 27741]

Happens with WAN pings as well, was just using LAN for the consistency. Honestly I think the answer here is wireless is garbage for latency and if you care about it go buy a wire. That is what I am going to do instead of chasing this dragon. Not sure why, but I am getting pretty variable pings whether it be WAN or LAN on different machines over WIFI intermittently. Could boil down to an ISP problem as well, but I have never seen wonky pings from wire. So, there is my answer. Thanks for all your insight as usual, my man!

 

[ColinTaylor]

Could just be a function of your wireless card? But TBH I found that the problem with QoS was the N66U's single processor. Once you start pushing lots of traffic through the router it's CPU usage goes to 100% and all of that is spent servicing irq's for QoS, leaving nothing for anything else. Moving to a dual-core AC68U solved most of my problems.

Here's me pinging my router over 5GHz. In the middle of this I saturate my download link. Spot the difference?

Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64

 

[Deleted member 27741]

Now that is shiny. Damn you and your dual processor goodness. My wife is going to have something to be crabby about when I invariably come home with a new router in the next couple months. Would you buy an ac68u now if you were in the market?

 

[ColinTaylor]

Just say that it's to improve her Netflix/Amazon Video viewing experience .

 

[ColinTaylor]

I'd buy an RT-AC86U because the price differential is so small between it and the RT-AC68U.

Also, I'm now hitting the CPU limit of my current AC68U because my line speed has increased to 380Mbps! (I know, first world problems ). Using Traditional QoS on John's firmware the RT-AC68U can't reliably do QoS above about 220Mbps (depending on the router's CPU speed and the number of QoS rules). What I should probably do is move back to Merlin's firmware so that I can use Adaptive QoS which won't suffer from the CPU issue. .....But I like John's firmware .

I'm still a bit nervous about the RT-AC86U. The hardware is very good but Asus have made some questionable decisions on the firmware side IMHO. Hopefully with the help of Merlin these can be sorted out over time and Asus won't drop it as a "failed experiment".

 

[Deleted member 27741]

Asus has made some questionable decisions about the firmware of the 86U in particular or their routers in general?
If you don't mind indulging me- what are some of those questionable decisions?
All that processor power makes me drool. We (wife included) use vpn quite a bit, so more processor is one thing I can posit to the old lady as a benefit.

Ah, found dem broadcom issues... https://www.snbforums.com/threads/88u-vs-86u.42442/

But I see rmerlin is on the case! Is there any chance broadcom will roll back the dumb on this router or is it probably a foregone conclusion that rmerlin will have to clean up after them?

 

[ColinTaylor]

TBH I haven't been following the fine details about the AC86U but it seems to be a lot better nowadays. The main thing I remembered was the limitations put on the length of NVRAM variables, particularly dhcp_staticlist. This seems to have been addressed by Asus now .

But the thing is, on the old models the small size of NVRAM was becoming a problem. So then they release the AC86U with twice the amount of NVRAM but in some ways there's less usable than the old routers .

There's also been (to my mind) too many reports of the routers crashing for no apparent reason, other than it's something in the closed-source components. I think the solution there might be to install the latest firmware and do a factory reset - and turn off as much of Asus' propriety stuff as possible . Just speculating here.

I'd still buy one though .