4 ms·

FCC greenlights superfast Wi-Fi tethering for AR and VR headsets

62 points by CharlesW 3y ago

crooked-v 3y ago
Virtual Desktop already does extremely well with Wifi 6/6e (with a nearby router, I only get 5-15 ms network latency even with settings all the way up, though encoding and decoding does add another 15-20 ms to that), so I'd be curious to see what or how much this adds. Is the idea to remove compression/decompression entirely by just blasting the full uncompressed bitrate with a 30-foot range?
- hifipotato 3y ago
  I see it as a way to move compute off a device to a nearby source using low energy.
  - hightrix 3y ago
    Exactly what I was thinking. This could make room for vastly improved accuracy in tracking due to being able to use off device compute power. Reducing latency such that an AR app could get frame data or other communication from an external device opens up many doors that are currently either closed or just cracked open. Shared experiences, extremely high precision, large data compute, etc… there are a ton of opportunities here.
  - deleted 3y ago
    [deleted]
  - fatnoah 3y ago
    I don't anymore, but I previously worked thr AR org for one of the named companies. Getting compute moved off of the device is a major goal, especially for any sort of all-day wearable AR device.
- rowanG077 3y ago
  20ms is no joke though in VR.
  - LanternLight83 3y ago
    Here's a post with some reference points, for scale. https://danluu.com/term-latency/ https://danluu.com/term-latency/
    - 4death4 3y ago
      This link is totally wrong. At least 50 ms counted is unnecessary. For instance, one frame usually takes 16 ms in a 60 fps game, but the link somehow stretched this out to 48 ms. This is trivially easy to verify. Open up a profiler and measure the time between the start of a game loop and the end of a draw call for that loop. Even in a browser it’s way faster. You can use the profiler to verify that the time between the start of input handling and render is less than 8 ms in Chrome. Sure, there is some time for the input to be handled, but nowhere near the level this link is suggesting.
      - kimixa 3y ago
        Yes - that latency measurement is extremely pessimistic, and would be an example of a "badly written" game at best. For example, it's normal for both the input processing and GPU submission to be completed within one frame time - delaying it by a frame adds complexity for no benefit, if anything (as it's presumably pipelined in a thread while the next frame input is processed and gamestate updated) - that requires the entire gamestate used for rendering to be copied to ensure there aren't conflicting concurrent updates to it by the update thread. And the GPU hardware itself being (over) 2 frames behind is unusual too - many apps are only double buffered, so while one is being scanned out to display you only have one framebuffer to be looking at. That means in the example shown, the gpu is sat on it's command buffers for at least one more frame for... no reason? Triple buffering is possible, but often not the default (and there's more presentation modes like mailboxes etc. but they tend to mean you're hanging onto otherwise complete frames for less time, not more). Compositors make this a bit more complex, but they're normally very carefully designed to reduce their impact - as they're relatively predictable workloads too they are good candidates for the "delaying" mentioned above. In most "real" apps it's normal for the processing of a frame on the GPU to start concurrently with GPU command submission. Most apps do multiple render passes, and there's no reason not to start rendering those passes as soon as they're submitted. Even on deferred tiling architectures it is common to have multiple separated passes through the hardware per frame - as there's no advantage to batching them if there's no overlap and they output to different buffers. And there's also the ability to do more clever things with timing submission - working on mobile devices I know it's pretty normal in Android for the compositor to /intentionally/ delay releasing a new buffer to an app until closer to the next vsync (and scanout) depending on estimated time of render. The apps themselves can easily (Well, easily if you can have a good estimate of how long the render themselves) do this even more accurately - modern render APIs allow precise timestamps, and direct synchronization between the rendering and present queue to reduce this latency further. This is exactly the sort of thing that would be a focus for VR apps, due to them tending to be more sensitive to latency. And my understanding is that for monitors it's pretty rare for the panel to wait for the entire frame to start changing pixels - if only because it increases the BOM of the panel controller to have multiple frames in a buffer - high res 4k+ 12bit-per-channel is actually quite a bit of storage. I've seen it in some panels that try to do post processing, think TVs with "smooth motion" interpolation, but rarely on PC monitors. Some HDR variable backlight implementations also sometimes do something similar, but again tend not to be the default mode (especially on VR headset displays). And even then they probably don't take 2 whole frames to actually process then change the pixels accordingly, as many of the things actually happen concurrently.
sand500 3y ago
How is this different from the existing spectrum allocation for wifi on 6GHz?
- throw0101c 3y ago
  There are all sorts of pre-existing users in the 6 GHz, so when the FCC (for one) approved its use for Wifi, it included restrictions. Some already-licensed stuff: * Sub-band U-NII-5, 5.925-6.425: Fixed Microwave, FSS (uplinks) * U-NII-6, 6.425-6.525: Broadcast Auxiliary Service, Cable Television Relay Service, FSS (uplinks) * etc Via: https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf Some details for approval: > Standard Power is the only access class that supports Wi-Fi 6E AP operations outdoors. Standard Power may also be used indoors as long as all requirements are met. Power is limited to a maximum of 36 dB Effective Isotropic Radiated Power (EIRP), and APs must be coordinated through an Automatic Frequency Coordination (AFC) service. Standard Power is also the only access class limited to operations in U-NII-5 and 7 in the U.S, and as a result gets a total of 850 MHz access. […] > Interference with these users must be strictly avoided. U-NII-6 and 8 are used for mobile operators and would be difficult to coordinate through an AFC. The equipment used is also very sensitive; satellites are a long way away, and the Received Signal Strength Indicator (RSSI) is not nearly as robust as a local Wi-Fi signal would be. Restricting Standard Power access to the U-NII–6 and 8 bands avoids any chance that there will be a problem. * https://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/802-11ax-solution/nb-06-wi-fi-6e-wp-cte-en.html https://www.cisco.com/c/en/us/solutions/collateral/enterpris... Power details: > Standard power can operate only in a subset of the 6 GHz band (the UNII5 and UNII7 bands). Standard power operates most like the existing FCC rules for 5-GHz spectrum. Effective Isotropic Radiated Power (EIRP) is the amount of power transmitted by the antenna of a device. The maximum EIRP possible is 36 dBm for either band (6 GHz adds a maximum power spectral density [PSD] of 23 dBm/MHz, which limits power for narrower band applications). However, to use these higher power levels in the 6 GHz band (UNII5 and UNII7), there must be governance to protect incumbents, as previously discussed. […] > The defining condition of the low power mode is a constant PSD of 5 dBm/MHz. The maximum power level for a chosen bandwidth can then be calculated as 5(dBm/MHz) + 10log(B(MHz)). This means that allowed EIRP will range from 18 to 27 dBm based on the amount of bandwidth used (20 MHz to 160 MHz). When using the higher bandwidth, this allowed transmitted power is very similar to the actual maximum transmitted power in the 5-GHz spectrum. * https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/ghz-unlicensed-spectrum-reg-wp.html https://www.cisco.com/c/en/us/products/collateral/wireless/c... Some handy charts with frequencies and channels at: * https://www.linkedin.com/pulse/updated-unlicensed-spectrum-charts-keith-parsons https://www.linkedin.com/pulse/updated-unlicensed-spectrum-c... A good presentation by David Coleman from the Wireless LAN Professionals Prague 2022 conference, "Wi-Fi 6E, Wi-Fi 7 and beyond - All about the spectrum": * https://www.youtube.com/watch?v=HbpD4BRdNvI https://www.youtube.com/watch?v=HbpD4BRdNvI From their Phoenix 2023 conference, "Wi-Fi 6E Update: Standard Power & AFC" about how loudly things can be broadcast in various situations: * https://www.youtube.com/watch?v=F7oovRprO40 https://www.youtube.com/watch?v=F7oovRprO40 The new FCC rules talks about "very low power (VLP) operations in the U-NII-5 and U-NII-7 portions of the 6 GHz band": it's about being mindful of introducing more 'noise' in the spectrum, specifically "power levels up to -5 dBm/MHz could occur anywhere, indoors or outdoors, without any need for a frequency coordination system." * https://docs.fcc.gov/public/attachments/DOC-397285A1.pdf https://docs.fcc.gov/public/attachments/DOC-397285A1.pdf

62 points by CharlesW 3y ago

Virtual Desktop already does extremely well with Wifi 6/6e (with a nearby router, I only get 5-15 ms network latency even with settings all the way up, though encoding and decoding does add another 15-20 ms to that), so I'd be curious to see what or how much this adds. Is the idea to remove compression/decompression entirely by just blasting the full uncompressed bitrate with a 30-foot range?

hifipotato 3y ago
I see it as a way to move compute off a device to a nearby source using low energy.
- hightrix 3y ago
  Exactly what I was thinking. This could make room for vastly improved accuracy in tracking due to being able to use off device compute power. Reducing latency such that an AR app could get frame data or other communication from an external device opens up many doors that are currently either closed or just cracked open. Shared experiences, extremely high precision, large data compute, etc… there are a ton of opportunities here.
- deleted 3y ago
  [deleted]
- fatnoah 3y ago
  I don't anymore, but I previously worked thr AR org for one of the named companies. Getting compute moved off of the device is a major goal, especially for any sort of all-day wearable AR device.
rowanG077 3y ago
20ms is no joke though in VR.
- LanternLight83 3y ago
  Here's a post with some reference points, for scale. https://danluu.com/term-latency/ https://danluu.com/term-latency/
  - 4death4 3y ago
    This link is totally wrong. At least 50 ms counted is unnecessary. For instance, one frame usually takes 16 ms in a 60 fps game, but the link somehow stretched this out to 48 ms. This is trivially easy to verify. Open up a profiler and measure the time between the start of a game loop and the end of a draw call for that loop. Even in a browser it’s way faster. You can use the profiler to verify that the time between the start of input handling and render is less than 8 ms in Chrome. Sure, there is some time for the input to be handled, but nowhere near the level this link is suggesting.
    - kimixa 3y ago
      Yes - that latency measurement is extremely pessimistic, and would be an example of a "badly written" game at best. For example, it's normal for both the input processing and GPU submission to be completed within one frame time - delaying it by a frame adds complexity for no benefit, if anything (as it's presumably pipelined in a thread while the next frame input is processed and gamestate updated) - that requires the entire gamestate used for rendering to be copied to ensure there aren't conflicting concurrent updates to it by the update thread. And the GPU hardware itself being (over) 2 frames behind is unusual too - many apps are only double buffered, so while one is being scanned out to display you only have one framebuffer to be looking at. That means in the example shown, the gpu is sat on it's command buffers for at least one more frame for... no reason? Triple buffering is possible, but often not the default (and there's more presentation modes like mailboxes etc. but they tend to mean you're hanging onto otherwise complete frames for less time, not more). Compositors make this a bit more complex, but they're normally very carefully designed to reduce their impact - as they're relatively predictable workloads too they are good candidates for the "delaying" mentioned above. In most "real" apps it's normal for the processing of a frame on the GPU to start concurrently with GPU command submission. Most apps do multiple render passes, and there's no reason not to start rendering those passes as soon as they're submitted. Even on deferred tiling architectures it is common to have multiple separated passes through the hardware per frame - as there's no advantage to batching them if there's no overlap and they output to different buffers. And there's also the ability to do more clever things with timing submission - working on mobile devices I know it's pretty normal in Android for the compositor to /intentionally/ delay releasing a new buffer to an app until closer to the next vsync (and scanout) depending on estimated time of render. The apps themselves can easily (Well, easily if you can have a good estimate of how long the render themselves) do this even more accurately - modern render APIs allow precise timestamps, and direct synchronization between the rendering and present queue to reduce this latency further. This is exactly the sort of thing that would be a focus for VR apps, due to them tending to be more sensitive to latency. And my understanding is that for monitors it's pretty rare for the panel to wait for the entire frame to start changing pixels - if only because it increases the BOM of the panel controller to have multiple frames in a buffer - high res 4k+ 12bit-per-channel is actually quite a bit of storage. I've seen it in some panels that try to do post processing, think TVs with "smooth motion" interpolation, but rarely on PC monitors. Some HDR variable backlight implementations also sometimes do something similar, but again tend not to be the default mode (especially on VR headset displays). And even then they probably don't take 2 whole frames to actually process then change the pixels accordingly, as many of the things actually happen concurrently.

sand500 3y ago

How is this different from the existing spectrum allocation for wifi on 6GHz?

throw0101c 3y ago
There are all sorts of pre-existing users in the 6 GHz, so when the FCC (for one) approved its use for Wifi, it included restrictions. Some already-licensed stuff: * Sub-band U-NII-5, 5.925-6.425: Fixed Microwave, FSS (uplinks) * U-NII-6, 6.425-6.525: Broadcast Auxiliary Service, Cable Television Relay Service, FSS (uplinks) * etc Via: https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf Some details for approval: > Standard Power is the only access class that supports Wi-Fi 6E AP operations outdoors. Standard Power may also be used indoors as long as all requirements are met. Power is limited to a maximum of 36 dB Effective Isotropic Radiated Power (EIRP), and APs must be coordinated through an Automatic Frequency Coordination (AFC) service. Standard Power is also the only access class limited to operations in U-NII-5 and 7 in the U.S, and as a result gets a total of 850 MHz access. […] > Interference with these users must be strictly avoided. U-NII-6 and 8 are used for mobile operators and would be difficult to coordinate through an AFC. The equipment used is also very sensitive; satellites are a long way away, and the Received Signal Strength Indicator (RSSI) is not nearly as robust as a local Wi-Fi signal would be. Restricting Standard Power access to the U-NII–6 and 8 bands avoids any chance that there will be a problem. * https://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/802-11ax-solution/nb-06-wi-fi-6e-wp-cte-en.html https://www.cisco.com/c/en/us/solutions/collateral/enterpris... Power details: > Standard power can operate only in a subset of the 6 GHz band (the UNII5 and UNII7 bands). Standard power operates most like the existing FCC rules for 5-GHz spectrum. Effective Isotropic Radiated Power (EIRP) is the amount of power transmitted by the antenna of a device. The maximum EIRP possible is 36 dBm for either band (6 GHz adds a maximum power spectral density [PSD] of 23 dBm/MHz, which limits power for narrower band applications). However, to use these higher power levels in the 6 GHz band (UNII5 and UNII7), there must be governance to protect incumbents, as previously discussed. […] > The defining condition of the low power mode is a constant PSD of 5 dBm/MHz. The maximum power level for a chosen bandwidth can then be calculated as 5(dBm/MHz) + 10log(B(MHz)). This means that allowed EIRP will range from 18 to 27 dBm based on the amount of bandwidth used (20 MHz to 160 MHz). When using the higher bandwidth, this allowed transmitted power is very similar to the actual maximum transmitted power in the 5-GHz spectrum. * https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/ghz-unlicensed-spectrum-reg-wp.html https://www.cisco.com/c/en/us/products/collateral/wireless/c... Some handy charts with frequencies and channels at: * https://www.linkedin.com/pulse/updated-unlicensed-spectrum-charts-keith-parsons https://www.linkedin.com/pulse/updated-unlicensed-spectrum-c... A good presentation by David Coleman from the Wireless LAN Professionals Prague 2022 conference, "Wi-Fi 6E, Wi-Fi 7 and beyond - All about the spectrum": * https://www.youtube.com/watch?v=HbpD4BRdNvI https://www.youtube.com/watch?v=HbpD4BRdNvI From their Phoenix 2023 conference, "Wi-Fi 6E Update: Standard Power & AFC" about how loudly things can be broadcast in various situations: * https://www.youtube.com/watch?v=F7oovRprO40 https://www.youtube.com/watch?v=F7oovRprO40 The new FCC rules talks about "very low power (VLP) operations in the U-NII-5 and U-NII-7 portions of the 6 GHz band": it's about being mindful of introducing more 'noise' in the spectrum, specifically "power levels up to -5 dBm/MHz could occur anywhere, indoors or outdoors, without any need for a frequency coordination system." * https://docs.fcc.gov/public/attachments/DOC-397285A1.pdf https://docs.fcc.gov/public/attachments/DOC-397285A1.pdf