What happens in /ax when a client doesn't respond in time ?
Last Post: February 12, 2019:
-
A few manufacturers have a dirty little secret that they have been keeping quiet about since the introduction of /ac.
Some of their client devices are already so slow (CPU starved) that they can't keep up, for example, with the speed requirements of the WFA certification test engine. They are so slow that they can't even count the number of packets being sent to them, much less make any sense of the data within the packets.
One of the effects that is has had on the industry is that there are many clients out there with /ac radios, but they can only qualify for /n WFA certifications.
If they are having this much trouble already, how in the heck are they going to be able to process /ax transmissions ?
Stricter frequency and SNR requirements should be handled by /ax PHY modifications in the radio chipset, but data handling will still be limited by the devices buss/cpu speeds and processes. The control of internal latency is critical, and the effects from bloatware can be disastrous.
Will the Background or Best Effort categories have to be redefined, or restricted, to only this type of device ?
With mains powered clients it is much easier to add more memory, faster CPU's, and add radio streams. Mobile devices don't have that luxury, where battery output/life and unit price are major considerations.
Your thoughts ?
-
I can't find it now, but I have seen a reference to a side-track WFA certification for low powered devices. The certification only requires a single stream, 20MHz channel connection. So WFA is aware of the problem. Their standard test suite is far too demanding for the plethora of devices on the market.
I just can't remember whether the cert is already available, coming soon or waiting for ax.
-
Yes, mobile devices using a single stream are allowed for /ac. It's the (stated) concession for battery powered devices.
However, generalized performance requirements are what are what is causing difficulties. This is exacerbated by PMF (Protected Management Frames), which is now required for certification. (I am not advocating removal of PMF !)
Multiple streams, per se, are not the problem here. It is the lack of horsepower - even for only one stream. Different widths, i.e. 20 or 40 MHz, slightly confuse the issue, but again processing speed is the problem.
Any "physically" constrained device, e.g. a printer, can have these issues.
I am willing to bet that some stationary, mains powered Laser or Ink-jet printers also "hide" their in-ability to pass the /ac cert tests under the guise of providing increased range using slower /b/g/n 2.4 GHz radios too.
- 1