Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

More of an issue when your phone's wifi or your partner watching a show while you game is eating into that one channel in bursts, particularly since the dedicated fob means that it's essentially another network conflicting with the regular WiFI rather than deeply collaborating for better real time guarantees (not that arbitrary wifi routers would even support real time scheduling).

MIMO helps here to separate the spectrum use by targeted physical location, but it's not perfect by any means.



IMO there is not much reason to use WiFi 6 for almost anything else. I have a WiFi 6 router set up for my Quest 3 for PC streaming, and everything else sits on its 5GHz network. And since it doesn't really go through walls, I think this is a non-issue?

The Frame itself here is a good example actually - using 6GHz for video streaming and 5GHz for wifi, on separate radios.

My main issue with the Quest in practice was that when I started moving my head quickly (which happens when playing faster-paced games) I would get lag spikes. I did some tuning on the bitrate / beam-forming / router positioning to get to an acceptable place, but I expect / hope that here the foveated streaming will solve these issues easily.


The thing is that I'd expect foveated rendering to increase latency issues, not help them like it does for bandwidth concerns. During a lag spike you're now looking at an extremely down sampled image instead of what in non foveated rendering had been just as high quality.

Now I also wonder if an ML model could also work to help predict fovea location based on screen content and recent eye trackng data. If the eyes are reading a paragraph, you have a pretty good idea where they're going to go next for instance. That way a latency spike that delays eye tracking updates can be hidden too.


My understanding is that the foveated rendering would reduce bandwidth requirements enough that latency spikes become effectively non-existent.

We’ll see in practice - so far all hands-on reviewers said the foveated rendering worked great, with one trying to break it (move eyes quickly left right up down from edge to edge) and not being able to - the foveated rendering always being faster.

I agree latency spikes would be really annoying if they end up being like you suggest.


Enough bandwidth to absolve any latency issues over a wireless connection is not really a thing for a low latency use case like foveated rendering.

What do you do when another device on the main wifi network decides to eat 50ms of time in the channel you use for the eye tracking data return path?


I believe all communication with the dongle is on 6GHz - both the video and the return metadata.

So again, you just make sure the 6GHz band in the room is dedicated to the Frame and its dongle.

The 5GHz is for WiFi.


On the LTT video he also said that Valve had claimed to have tested with a small number of devices in the same room, but hadn’t tried out larger scenarios like tens of devices.

My guess based on that is you likely dont need to totally clear 6GHz in the room the Frame is in, but rather just make sure its relatively clear.

We’ll know more once it ships and we can see people try it out and try and abuse the radio a bit.


Pretty funny to me that you're backseat engineering Valve on this one. If it didn't have a net benefit they wouldn't have announced it as a feature yet lmao


I'm not saying it doesn't work; I'm asking what special sauce they've added to make it work, and noting that despite the replies I've gotten, foveated streaming doesn't help latency, and in fact makes the effects of latency spikes worse.


Why are you assuming the fob would use the same WiFi channel as your regular 6GHz network? That would be extremely poor channel selection.


MU-MIMO is very nice.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: