Wi-Fi 802.11ac 1.7 Gbps (160MHz channels) advisory

Discussion in 'Networking and Wireless' started by downloads, May 1, 2018.

  1. Starlight5

    Starlight5 W I N T E R B O R N

    Reputations:
    556
    Messages:
    2,919
    Likes Received:
    1,381
    Trophy Points:
    181
    Reading all this, I'm glad to be still using good ol' 18260 and simple yet stable 2x2 802.11ac wave 1 router. What a disappointment! Hope Intel, QCA & others won't mess up 802.11ax the same way!
     
  2. Aivxtla

    Aivxtla Notebook Evangelist

    Reputations:
    333
    Messages:
    426
    Likes Received:
    565
    Trophy Points:
    106
    I mean it works fine on the Netgear R7800, Synology RT2600AC and Asus BRTAC828 all of which use the trusty QCA9984 chipset. Other than not supporting 80+80 split bonding it’s reliable and provides decent boost for me at least over the 8265 by about 60-100 Mbps DL and a 100+ Mbps increase on DL basically 550-600 Mbps Down / 440-480 UP in transfers between NAS and laptop in my testing environment.

    HT160 and MU-MIMO are two things that not all chipsets as created equal in. Qualcomm seems to be the best at the moment in terms of a fully functional WiFi router chipset.
     
    Maleko48 and Starlight5 like this.
  3. downloads

    downloads Super Moderator Super Moderator

    Reputations:
    7,648
    Messages:
    8,640
    Likes Received:
    2,009
    Trophy Points:
    331
    That is not related to 7260 though - while it can't connect, neither can Intel 9260 or Broadcom BCM4339.

    I think you're missing the point here. There is nothing wrong with Marvell radio chip - it's doing exactly what it should if radar was detected. 802.11ac specification is poorly thought out and anytime radar detection kicks in on 160MHz channel it's bound to disconnect you immediately and the remain unconnected for a minute. QCA can't be any better i that respect unless it's not DFS complainant.

    That makes me wonder if those radar patterns that are supposed to be detected are specified by Wi-Fi alliance or are hardware manufacturers able to define them as they wish. Because if it's the latter than it one hell of an incentive to do a bad job and make your clients stay connected.

    I am going to do some more testing (it's not like I have a choice in the matter) but I'm inclined to agree with @Starlight5 that VHT160 is not a good idea - it's expensive, effective range will be worse and thanks to DFS being unavoidable, there is a real chance of it being unreliable.

    Side note: I will reset the router to factory settings and re-test. I did play with the config a bit under the hood and while I think I left it at default when I was done, I should make sure about that.

    On another note - Intel 9260is unreliable as well. I made multiple tests transferring a 6GB file to and from NAS testing different channels and so on and I have noticed that in time transfer speeds drop significantly. Worst case scenario to mid 40s.
    This is unfortunately easy to recreate so I've been able to isolate the culprit - if I disable the card in device Manager and re-enable it speeds go back to normal. So it's not the router, it's not Windows, not AV software and not NAS.
     
    Starlight5 likes this.
  4. Aivxtla

    Aivxtla Notebook Evangelist

    Reputations:
    333
    Messages:
    426
    Likes Received:
    565
    Trophy Points:
    106

    Yeah my apologies seems I glossed over your previous post too quickly. Thought it was the 7260ac only with the issue. If your on HT160 on lower channels it should drop down to HT80 as the 36-48 range is still non DFS, not sure why it would disconnect entirely. So HT160 should be more like a bonus rather than a loss over HT80 when available. However yes range in HT160 will be less as you are spreading the legally available power over greater amount of spectrum, not sure if I put that in the right terms.

    My 9260ac drops to HT80 occasionally depending on signal conditions like it should but it never just outright drops nor do I face connectivity issues with other laptops or phones, even if a radar were detected as I said before the other half of the 1st 160Mhz band is non DFS for fallback. I still think it’s the Marvell chipset not dealing with the switch from affected DFS channels in a proper manner.

    Feel free to keep correcting me if I missed something as I do that quite often .

    TLDR my view is HT160 if properly implemented is kinda like Turbo Boost, Active under the right signal conditions (and no radar) and falls back to HT80 in the non-DFS section when necessary without issue. At least that’s how the QCA9984 in the R7800 works I believe when using HT160 in UNII-1 and 2A parts of the spectrum.

    I saw a post by Chadster766 on Linksys forums talking about false radar detection and ch36 switchback issue on the WRT3200 on Linksys forums. BrainSlayer of DD-WRT also mentioned a weird issue where clients wouldn’t connect just like you mentioned in your post regarding HT160 on the WRT3200 and channel 36 he was comparing with the QCA9984 which seemed fine.

    Something similar on OpenWRT:
    https://github.com/kaloz/mwlwifi/issues/75
     
    Last edited: May 8, 2018
    Starlight5 likes this.
  5. downloads

    downloads Super Moderator Super Moderator

    Reputations:
    7,648
    Messages:
    8,640
    Likes Received:
    2,009
    Trophy Points:
    331
    @Aivxtla Judging by the log for my system the procedure for Marvell looks like this - radar is detected on lower 160MHz channel (the one starting with ch 36) and the router attempts to move the circus to the other 160MHz channel available (the 100-and-thereabouts one) and once the radar is detected there, and there are no more 160MHz channels left, it moves back to channel 36 but changes channel width to 80MHz to stay out of DFS zone.

    Whether it's optimal compared to what QCA is doing is up to debate. The obvious downside of making an attempt to keep 160MHz is that Marvell chipset will disconnect all devices when moving between channels, however it makes an attempt to preserve the channel width and therefore performance.

    On the other hand what QCA does seems less obtrusive - if I understand it correctly it will change channel width from 160MHz to 80MHz to stay out of DFS zone first. This is something it can always do only on lower 160MHz channel since the other one is all in DFS zone and simply scaling down to 80MHz might not change anything if radar is detected on more than one of the of 80MHz channels it consists of. Radars do not really work within Wi-Fi channels boundaries, so it's entirely plausible that it might cover more than one channel.

    Also there is another downside of QCA way which is that the channel the radar is detected on gets blacklisted for 30 minutes, so once it scales down to 80MHz it won't be able to scale up for half an hour anyway.

    I would say it's debatable which of these procedures is better but certainly neither is good. The proper way would be to use 80+80 and simply move whichever 80MHz channel is in the way of radar to another channel keeping all devices connected and keeping 160MHz channel width. At least in theory...
     
    alexhawker, Starlight5 and Aivxtla like this.
  6. Aivxtla

    Aivxtla Notebook Evangelist

    Reputations:
    333
    Messages:
    426
    Likes Received:
    565
    Trophy Points:
    106
    Yeah I believe the attempt to keep the channel width is causing the issue. Sad part is it’s actually one of the best performing units despite being a 3x3 unit it competes with many 4x4 routers. HT160 and MU-MIMO are like an after thought for these companies. Decent chipsets but half hazardously implemented extras. These are after all novelty features nice to list on a box as they know most people won’t have supported clients.

    But yeah I prefer stability of the connection which the QCA provides over attempting to maintain width for performance. 80+80 would be awesome but in that respect the 9260ac lacks support while my own router supports it. It’s like a puzzle, I really wish there were standard practices for devices labeled with HT160 support. HT160/MU-MIMO are both a mess... Hopefully ax has actual consistent standards implemented for these.

    Well whatever the case I learn a lot from these discussions with people like you and the others here. Hopefully you get a fix before the router is not supported anymore lol.
     
    Last edited: May 8, 2018
    Maleko48 likes this.
  7. downloads

    downloads Super Moderator Super Moderator

    Reputations:
    7,648
    Messages:
    8,640
    Likes Received:
    2,009
    Trophy Points:
    331
    @Aivxtla Thanks for the link to github - I do follow mwlwifi development but I didn't go through old closed issues. Apparently I mistook closed for solved - my bad. :rolleyes:
     
    Maleko48 likes this.
  8. downloads

    downloads Super Moderator Super Moderator

    Reputations:
    7,648
    Messages:
    8,640
    Likes Received:
    2,009
    Trophy Points:
    331
    It's somewhat off topic but yet on topic at the same time - and rather funny - so bear with me.

    I have decided to go back to DD-WRT for testing from stock WRT32X firmware that I had cross-flashed on my WRT3200ACM via USB-TTL cable. In order to to that I had to change flash layout and change the bootloder.

    Going back wasn't that smooth though - I can flash any firmware properly WRT3200ACM, OpenWRT or DD-WRT but none of them will boot automatically. Normally u-boot waits 5 seconds and boots from nand but mine does not boot at all unless you connect via USB-TTL and issue"boot" command. From then on everything is fine.

    I haven't been able to figure that out yet and at 3 a.m. I gave up.

    So this is how starting my router looks like now. I had to connect all wired devices and power cable, having placed the router where it normally sits but with front cover not on.
    Then connected USB-TTL to serial port on the router and my notebook via 4 inch cable. Then standing with my notebook in one hand I had to switch on the router with my other hand and only then connect the USB adapter fully to USB and click "connect" in putty.
    Once that was done I issued "boot" command and disconnected the whole circus and reassembled the front of the router as it was going online.

    Let's hope the damn thing is stable because I've made rebooting incredibly complicated :rolleyes:

    EDIT: After three weeks I got back to it and fixed the no-nandboot-issue although I don't know how.
    I used these commands:
    env default -a
    saveenv
    and rebooted the router.

    It did not help. Then I flashed new DD-WRT which again did not boot automatically and because it dropped connections I re-flashed the previous one again and now the router boots automatically.

    No idea how I did it. :rolleyes:
     
    Last edited: Jun 1, 2018
  9. Cool_gole1

    Cool_gole1 Newbie

    Reputations:
    0
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    5
    Hi, this is my first post, i saw the topic about buying notebooks and shipped vua dhl gets stuck for weeks which i currently experience in google, but could not giew anymire after registering because it was under general discusdions and off topic section, can anyone help out to allow ne to post there and eill also use it as basis so that it will ve released immediately, thanks for the help.
     
  10. Charles P. Jefferies

    Charles P. Jefferies TG Lead Moderator Super Moderator

    Reputations:
    21,997
    Messages:
    36,310
    Likes Received:
    4,343
    Trophy Points:
    681
    I moved you into a usergroup that allows you to see OT.

    Charles
     
Loading...

Share This Page