› UKTH forums › π Wireless Routers & Modems › ASUS & Wireless › ASUS New DSL-AX82U Modem Router Combo – Wifi 6 › Reply To: ASUS New DSL-AX82U Modem Router Combo – Wifi 6
I’ve had the ax82u since Sunday, so far very happy, always at least 140mb ram free whatever I have experimented with (currently traditional QoS & app analysis on over the last day to help tune QoS ) so not concerned about memory so far. It does seem to be handling house traffic better than the 88u, but that only allowed for upload limiting and gave so little information that could be used to balance properly.
Plugging it in called for an update to 3.0.0.4.386_42438 as soon as it was online. It’s connecting to the ISP a lot faster than the ac88u which is interesting, but no real change on line stats so far. I’m guilty of hoping it might increase max rate eventually, but the line itself is old and remote so it may be the best it will ever maintain stability on.
For anyone with low latency/low bufferbloat needs : Traditional QoS with few or many rules and manually set bandwidth for the initial QoS setup still seems to win out over Adaptive whether bandwidth is auto or manually set, maintaining lower latency overall when testing UDP games.
Without deeper investigation The Game Gear Accelerator seems to only be a simple UI for adding your systems into Adaptive QoS as highest priority, Adaptive is switched to if you enable Gear Accelerator, it certainly does not appear significantly better than Adaptive enabled via other means, but I did not look into checking the exact config via telnet to see if there were any real configuration differences, maybe another time.
Traditional rules are not deleted so you can swap easily between the two if you wish to test.
Enabling Adaptive (or Gear) from Traditional causes a quick progress bar (<10s) which did not noticeably terminate traffic, going back the other way appears to cause a reboot however, or at least cut traffic for well over a minute. Considering the most valuable use of QoS is managing a multi-user network, I really don’t think it’s acceptable such operations aren’t always proceeded with a clear warning and opportunity to back out, especially as this example shows it’s not entirely predicable, that goes for any operation that will cause a disconnect really, not just QoS changes.
I’m going to pass on installing beta firmware for now unless there is a very compelling reason, and hope some of the new updates hit stable status soon.
You need to login in order to vote
