Has anyone else seen a performance difference in Upper/Lower 5GHz bands?

[ATLga]

Is there a reason you are using Auto 20/40/80 setting in the first place??

In my experience, I set it to 80mhz and forget it. It worked well for me for many years with no issues. If a device is too far away from a router, then connection speed will drop do to distance, but I don't have to worry about speed step down if a device is close to a router and I don't have to worry about router choosing speed connection based on a channel.

So why are you using Auto setting in the first place?

There was a post awhile back by @Grisu where he tested the individual settings and auto and a lot of them weren’t actually doing what they were set for. Auto 20/40/80 was actually working correct vs the others. Maybe he can clarify that since I can’t find that thread now

 

[Grisu]

It has been about other wifi settings, cant remember I tested 20/40/80-auto as I allways used 80 fix.
Do you mean this? https://www.snbforums.com/threads/wireless-modes-broken-2g-802-11b-g-n-and-5g-a-n-ac.47783/

 

[ATLga]

It has been about other wifi settings, cant remember I tested 20/40/80-auto as I allways used 80 fix.
Do you mean this? https://www.snbforums.com/threads/wireless-modes-broken-2g-802-11b-g-n-and-5g-a-n-ac.47783/

Yes, that’s the thread.

 

[thiggins]

The 802.11ac spec supports dynamic bandwidth allocation. This means if an AP detects activity (I think management frames) in one of the four channels it is using for 80 MHz, it can reduce the channel size to 40 or 20 MHz.

This reduces channel congestion and should provide more efficient operation for areas with many neighboring networks.

So IF this is the mechanism that the 20/40/80 setting enables, then I'd encourage its use.

Enterprises rarely use even 40 MHz channel bandwidth. 20 MHz is the standard. It provides 8 non-overlapping channels without requiring DFS and enables higher density AP deployment.

Most applications don't require the bandwidth that an 80 MHz channel provides. Lower contention should produce lower latency, which usually is more useful than higher bandwidth.

 

[dlandiss]

Most applications don't require the bandwidth that an 80 MHz channel provides. Lower contention should produce lower latency, which usually is more useful than higher bandwidth.

As I read your very clear description my mind immediately pictured a NASCAR race, with dozens of cars travelling at 200mph fighting for the available track width and frequently crashing; versus an Interstate highway with thousands of cars sharing 4 to 6 lanes at 70 to 80mph and the lowest crash rates in history.

 

[thiggins]

@dlandiss Yup. That's a great analogy. Thanks!

 

[KGB7]

There was a post awhile back by @Grisu where he tested the individual settings and auto and a lot of them weren’t actually doing what they were set for. Auto 20/40/80 was actually working correct vs the others. Maybe he can clarify that since I can’t find that thread now

I looked at the... https://www.snbforums.com/threads/wireless-modes-broken-2g-802-11b-g-n-and-5g-a-n-ac.47783/ ....Link and there isn't much testing. Just bunch of gibberish. Mainly; "I tested some wireless settings and they all buggy in 2G and 5G!"

This tells me nothing. Nothing concrete or relevant to Auto- 20/40/80 or manually setting to 80Mhz.

@Arfyness

Manually set 5Ghz band to 80Mhz and test it with 4x channels and 14x Channels. Also disable beam forming.

 

[Grisu]

Then you shouldn't look at it but read carefully.

 

[thiggins]

Just bunch of gibberish

This is harsh. There a kinder ways to make your point.

 

[doczenith1]

I haven't done any tests with the channel bandwidth set to 80 MHz but I have done hundreds of tests using iPerf3 with the channel bandwidth set to 20/40/80. With the 20/40/80 setting I have routinely achieved throughput in the upper 600's on 2x2 ac devices. So, if there is any benefit to using the manual 80 MHz setting it can't be that much.

 

[juched]

With my RT-AX88U, I noticed that on channel 36 I was seeing poorer performance than when using 153. Performance meaning actual throughput as well as a strength indication. I have stuck with 153 even though it means I cannot use 160Mhz range. That being said, as soon as I hadd my AiMesh nodes, 160Mhz disables anyways, as they are just AC routers.

 

[admiral2145]

With DFS enabled I've seen huge improvement on 5ghz...on channel 116 I get amazing throughput and signal quality.

Sent from my PH-1 using Tapatalk

 

[KGB7]

This is harsh. There a kinder ways to make your point.

You might be right.

How would you say "gibberish" in a kind way? Im honestly curious.

 

[KGB7]

Then you shouldn't look at it but read carefully.

I did, and there is nothing in your post that has any relevance to this topic at hand for 5Ghz band on AC68U router.
Your post is also 2 years old.
Over the course of 2 years, the issues you have brought up, could have been fixed in newer firmwares in AC68U router. Issues that you did not continue to explore, document or report to firmware makers; Asus, Merlin or Fork (at least not that I know of, since that specific post has no such info).
You also did not mention exact firmware/s where you found the issue at the time back in July 2018 5Ghz band on AC68U router. Which is also irrelevant to topic at hand.
You did not mention which firmwares you used for testing and how many versions of each firmware (Asus, Merlin, Fork) versions you have used and tested on AC68U router.
You also did not document your testing methodology on 5Ghz band on AC68U router that is relevant to this topic at hand.

And since you didn't follow through with your findings over the past 2 years and over multiple firmware releases for 5Ghz band on AC68U router for specific issue related to this topic, then in IMHO, your post and findings from July 2018, are moot.

If... i'm wrong. Please take your time and explain to me like i'm a 5 year old and I will gladly listen.

 

[thiggins]

This is harsh. There a kinder ways to make your point.

I would not say it at all. I'd just say that I didn't find any useful information in the post, being specific about my questions.

More like your second post, but without the harsh and dismissive tone.

My general rule is to ask questions, not make accusations.

 

[Grisu]

If you forgot it: I have been mentioned by another member so I replied, I didnt actively post it!

It has been in many firmwares before and after till at least autumn last year when I sold it and probably still the same as there has not been any new wifi driver.
And I reported to Asus, and to Merlin and NOT REACTION from them or someone else in this forum and even no interest to this thread at all.
So I had to think noone else will be of any help.
Shall I write it again and again every month that you would kindly accept it?

It is irrelevant which firmware is used as Merlin doesnt touch wifi parts of stock firmware as you should know very well.
I changed wifi mode of clients and tested if I could connect to the router set to different ones. As well you can see it in different wifi analyzer tools (I even had a paid acrylic).

You have been absent to this forum for very long time and suddenly reappeared some weeks ago and criticise everyone how has problems and tells them to others.
In short: All I can read is from you is pushing Asus as the one and only without faults (they all have to be in front of all monitors).

But as you should know: There has been a big change in Wifi 2.4G and 5G in 2015 when I had this 68U covering my big house without any problems!
And one firmware later I had and hate to buy 2 additional devices, and NOTHING (regulatory) changed in my country - Great for Asus!

 

[thiggins]

Ok folks, the discussion is degrading. Thread done.