Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
1–10 of 24 posts
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#2[deleted]
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#3Thanks for the link, really interesting!
We have a distributed system (clouds & cars) that message events which need to be processed in order. However, the clock of some system participants (cars) are drifting quite often. We plan to use a logical clock for the ordering instead soon.
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#4Thanks for the link, really interesting! We have a distributed system (clouds & cars) that message events which need to be processed in order. However, the clock of some system participants (cars) are drifting quite often. We plan to use a logical clock for the ordering instead soon.
No way of accessing your cars' GPS receivers' 100-nanosecond-precise time signal, huh?
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#5Thanks for the link, really interesting! We have a distributed system (clouds & cars) that message events which need to be processed in order. However, the clock of some system participants (cars) are drifting quite often. We plan to use a logical clock for the ordering instead soon.
No way of accessing your cars' GPS receivers' 100-nanosecond-precise time signal, huh?
Yea I always liked the way Spanner solved this. Let's not bother with any of the distributed system theory and just use that Google money to build in to the system extremely precise clocks :-D.
(Obv I know it's more complicated than that, but where else can you be reductionist if not the internet)
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#6Thanks for the link, really interesting! We have a distributed system (clouds & cars) that message events which need to be processed in order. However, the clock of some system participants (cars) are drifting quite often. We plan to use a logical clock for the ordering instead soon.
No way of accessing your cars' GPS receivers' 100-nanosecond-precise time signal, huh?
That's what I asked them as well and apparently... no.
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#7Thanks for the link, really interesting! We have a distributed system (clouds & cars) that message events which need to be processed in order. However, the clock of some system participants (cars) are drifting quite often. We plan to use a logical clock for the ordering instead soon.
No way of accessing your cars' GPS receivers' 100-nanosecond-precise time signal, huh?
It probably won't be 100 ns accurate in motion, but still quite accurate. Practically speaking you won't get better than ~1 s unless you connect the PPS pin to an interrupt or PLL.
With a bare minimum implementation you should be able to get the GPS time from the NMEA strings. You just need to guarantee you'll have GPS lock at least intermittently, which is probably true for a fleet of monitored cars in nearly all situations.
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#8this is great! very clever logic model.
I wrote something I think is highly relevant about a distributed L1 for time, that you might enjoy, OP?
[oc] https://www.seanmcdonald.xyz/p/the-clockchain-protocol-the-l...
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#9Earlier quoted context omitted.
No way of accessing your cars' GPS receivers' 100-nanosecond-precise time signal, huh?
It probably won't be 100 ns accurate in motion, but still quite accurate. Practically speaking you won't get better than ~1 s unless you connect the PPS pin to an interrupt or PLL. With a bare minimum implementation you should be able to get the GPS time from the NMEA strings. You just need to guarantee you'll have GPS lock at least intermittently, which is probably true for a fleet of monitored cars in nearly all si…
Urban canyons aside, the GNSS receiver itself should almost always have better than 100 ns accuracy, even when moving. After all, 100 ns at the speed of light is ~30 meters. At 200 ns you're on the wrong city block.
As for bringing that into a computer, I'm having a hard time imagining a hardware setup where a software PLL won't give you millisecond-level accuracy (assuming you have an internal clock with at least that much precision). 1 second accuracy implies just using the timestamp from the last NEMA string with no further processing...
Re: Time, Clocks, and the Ordering of Events in a Distributed System – Paper Review
#10Earlier quoted context omitted.
No way of accessing your cars' GPS receivers' 100-nanosecond-precise time signal, huh?
That's what I asked them as well and apparently... no.
As someone who's worked on some very similar problems, fix it properly on the vehicle side. Lamport/vector clocks are not a silver bullet here. They can be very difficult for end users to handle properly, and don't necessarily scale well in large fleets with unbounded drift. The vehicle network has a synchronized notion of time already. If the vehicles were designed properly, that's hooked into GNSS already. Even if they aren't (e.g. because it would impose unacceptably high uptime requirements), you have another system to bound drift already because various systems are required to stay within a small margin of "true" time (certificate validation comes to mind).
This is a fundamental system for the company, so it's worth cracking a few heads over the issue.