3 ms·
I fully expect the results would make anyone with deep knowledge of PTP laugh at loud at how inaccurate/imprecise it is, but I still love for wifi to get a PTP.
by jauntywundrkind 2y ago
I fully expect the results would make anyone with deep knowledge of PTP laugh at loud at how inaccurate/imprecise it is, but I still love for wifi to get a PTP.
There's so much audio and video stuff that works so much better with ptp. Even if it's vastly less good, its still gotta be some way to keep systems running on the same time, and that's a huge win. I'd love to see wifi PTP happen.
There's some really incredible research work a team did a while back, hacking their own PTP implementation stop a specific driver (adding timestamps to ath9k). https://github.com/zlab-pub/wifi-ptp https://github.com/zlab-pub/wifi-ptp
- deleted 2y ago[deleted]
- geerlingguy 2y agoI'm guessing you're referring to: https://github.com/zlab-pub/wifi-ptp https://github.com/zlab-pub/wifi-ptp But I remember reading somewhere (maybe it was in an OCP-TAP session, which they publish every month or so) that there was a serious effort to make hardware timestamping work in WiFi 7 or 6E, maybe? Can't find the reference.
- wcunning 2y agoThat's been a big deal in industrial automation spaces. To have safety critical distributed applications, you need a way to say that a message is stale or something you can't respond to since the state of world might have changed since the data was acquired. As a result, there is a heavy need for some bound on time accuracy from wireless nodes, even if it's a bad bound (several ms instead of single digit us or similar), that still lets you do safety case decomposition. This is one of the core pieces of tech in automotive for distributed safety cases, think sensors on different time scales with sync'd local clocks allowing for timestamping for staleness/aliveness.