Still wonder why NG employes 64 for CTS on Orbi AX Systems.
I'm using 64 for CTS and it's been working well for me. I know the norm for most other GN routers is 2347 and has been historcally for years. I was told my someone at NG is that if you have more wifi nieghors, can impact what the CTS value could be used I think.
Perhaps I read the underlying information incorrectly. The impression I get is that the range of 0-2347octets is part of the 802.11 specification, not a choice made by Netgear. If Packets are shorter than the limit specified, they are sent without using the RTC/CTS mechanism. If packets are larger (even really, enormously larger) then they must use the RTC/CTS mechanism.
It is clearly possible for a packet encrypted with any mechanism to be shorter than the maximum, and thus qualify to be sent without waiting for RTC/CTS. As @FURRYe38 notes, setting the parameter to 64 octets will mean that the vast majority of packets use the RTC/CTS mechanism.
Perhaps newer encryption methods have created a reason for the 802.11 standards committee to revisit the maximum size of a packets to qualify for skipping RTS/CTS, but that does not seem to be a "Netgear issue."
p.s. Thanks for the link to O-Reilly. Fascinating reading!
I agree with you that setting the CTS/RTS to a lower value is irrespective of the encryption method used.
The behaviour I and others are seeing when setting CTS / RTS to the maximum value is the sudden and frequent reboot of the satellite particularly during video calls from a device connected via a satellite.
The 802.11ac specification supports sending very large aggregated frames.
I suspect there maybe some kind of internal buffer overrun when moving data between the client and the backbone 5Ghz radios within the satellite which of course doesn’t happen if the client is connected directly to the router.
I’d be interested to understand if this remains an issue if the satellite uses a wired backbone instead.
Personally I’ve been largely happy with the performance / reliability of the Orbi once I had realised that changing the RTS/CTS from the default of 64 to the maximum appears to be the underlying cause of my satellite reboot issue.
I am almost dizzy trying to comprehend WiFi. (Love that O'Reilly chapter! but, OMG!!!) Switch the radio to 802.11a to send the RTS (on as many channels as are desired), get the CTS responses and then set the radio to the highest speed possible to transmit the data packet on the correct number of channels.
O'Reilly makes it very clear that the RTS/CTS business was created well before 5G WiFi. Would love to know how somebody decided that 2347 was the ideal cutoff point. i.e. For a packet shorter than that, just send the damn thing and retransmit if something goes wrong. If longer, then to a RTS/CTS to get permission to hog the radio for a longer time. Where I was going was changing the RTS/CTS from 2347 to a smaller number increases the number of packets that will require RTS/CTS protocol. When it is set to 2347, than a packet of 2346 octets would ignore the RTS/CTS and just send (as would 2345, 2344, 2343... down to the smallest packet possible). Yes, there are tons of huge packets, but there may be smaller ones as well. (Think of ICMP with 32 octets, ARP broadcasts (28), or DHCP (576).)
It's not clear (to me) what the default value is. To my knowledge, I have never changed mine and it is set to 2347 (on two different Orbis). Perhaps the default is 64 for the AX products, or......??
Another unknown is the setting for the 5G (and the backup 2.4G) backup WiFi channels. I am pretty confident that those advanced WiFi settings (Transmit Power, RTS/CTS) are for the user facing WiFi channels and have no effect on the backhaul channels. On the AX product, for example, there is an option to turn off 'ax' capability on the user facing channels, but I am 100% certain that ax remains on the backhaul channel.
Reading the O'Reilly chapter was a real eye opener.
I consider myself fairly competent in IT having worked In the sector for decades designing complex Global IT solutions.
Regarding the question around NG’s default RTS/CTS values I suspect at some point they set it to 64 in the firmware however it only get configured for new out of the box installations or when you do a factory reset.
I’d be interested to understand if this remains an issue if the satellite uses a wired backbone instead.
I can confirm that this issue definitely did occur with a wired satellite, during long videocalls with the threshold set to 2347. Since I set it to 500 I haven't seen the same behaviour.
I've only seen a reboot problem once on my 7 series however that was with older version of v4 FW. I've always left my Orbis with default CTS values to see how the system and my devices should work with defaut out of the box settings. I only did change the CTS value to max one time while in v3 FW due to troubleshooting NEST controller low battery issues back then. Since v4 has been out, I have not change CTS from 64. Haven't seen any issues since. We are tracking one issue with Whats App and voice calls seem to be problematic on v5 FW. Other then that, been fairl stable. I may need to revisit the Whats app problem and see if CTS maybe involved any.
I usually change my CTS/RTS settings to max (2347) as soon as I get a new NG device. Then, I watch the router statistics closely for a few days/weeks to see if there are any collisions. While I have a fair number of connected devices (35), the majority of them are low traffic devices and I have never had an issue with any collisions so 2347 works fine with me.
From what I've read regarding CTS/RTS settings, as long as you are not getting any collisions, 2347 (basically CTS/RTS OFF) is fine. If you start getting collisions, then you need to adjust.
I have also seen on several places that with such a low value as is set by NG when their Orbi devices are delivered, that you may end up with a latency issue.
I am not a user of ZOOM or other videocall type of software except on very rare occasions. I've not had any drop/reconnect, but then again, I do not have a great number of calls to refer to.
The issue of default RTS value is somewhat of a puzzle to me. I read comments on the forum that Netgear delivers products with the RTS value set to 64, but mine is 2347 and I have no memory of ever changing it. As a check, I just now did a factory reset on an RBR50 and the RTS value came up 2347. Perhaps some Netgear WiFi routers come set to 64 and others come set up 2347?
Further, when I search for "RTS default value", hits come up from Cisco, Linksys, and other vendors stating that the default value is 2347. Articles about "What is the best RTS value?" typically zero in on somewhere in the 500 range after going through a long discussion of the pros and cons of larger vs. smaller RTS values.
CTS and RTS values are only changed to 64 on Orib AX systems. Orbi AC didn't change this by default. It's only seen on Orbi AX systems.
Guess it's time to research RTS and 802.11ax........ (or not) Surely this would not be the result of some engineer saying, "hmmmm. 64 is a cool number. I'll set that as the default." and nobody ever looking at that part of the code again.
CTS and RTS values are only changed to 64 on Orib AX systems. Orbi AC didn't change this by default. It's only seen on Orbi AX systems.
Guess it's time to research RTS and 802.11ax........ (or not) Surely this would not be the result of some engineer saying, "hmmmm. 64 is a cool number. I'll set that as the default." and nobody ever looking at that part of the code again.
I think I asked that question of a NG engineer several years ago.
The reply was that they used that in THEIR testing environment because of the large numbers of devices in play.
Well seems to be the norm now for Orbi AX systems. May never know the real reason why they defaulted it only on Orbi AX systems. Even on RAX CTS is still at 2347. Maybe NG found it works better on Orbi AX systems and all the complexities of MESH, I presume anything may help where it counts.
