4 ms·

IEEE 1588 (Precision Time Protocol) has already solved this problem for every use case that matters and offers microsecond precision. https://www.eecis.udel.ed

IEEE 1588 (Precision Time Protocol) has already solved this problem for every use case that matters and offers microsecond precision. https://www.eecis.udel.edu/~mills/ptp.html https://www.eecis.udel.edu/~mills/ptp.html PTP takes advantage of special Ethernet switches and other devices which can decode or manipulate the time tags in hardware because yes your switches add latency. This just sounds like more horseshit out of SV. I applaud them for convincing someone to give them money for this snake oil.

paxys 5y ago
Applications like Spanner work with nanosecond-level time difference between datacenters. PTP works in microseconds and can even go up to a few milliseconds, making it useless for actual time sensitive use cases.
- pclmulqdq 5y ago
  Spanner works fine with millisecond-level timestamps. Spanner needs accuracy, not precision: it relies on knowing the bounds on the the current time, which may be wide.
- welterde 5y ago
  I think you are confusing PTP and NTP. NTP is in the range of low microseconds to a few milliseconds (with hardware time-stamping can actually do much better than that though), while PTP can synchronize time to better than 100ns.
jeffwheeler 5y ago
Their website links [1] to a presentation at Stanford [2]. Mendel Rosenblum briefly compares their concept with PTP at about 45:54. He says: > Those people [fintech, etc.] are interested in our stuff, so obviously [that] means that thing [PTP] is not perfect for them. Part of the problem is, you’re trying to measure individual packets that are going through and get times. It means you have some clock there that you’re reading, and when it goes into the switch, and when it comes out, like, what is that clock doing in terms of its varying in frequency, and stuff like that. And then you get one sample and try to make things of it. It sorta pales in comparison to this big data approach we’re looking about. This seems like a mischaracterization of PTP (802.1AS), which does use multiple samples to syntonize. [1] https://www.clockwork.io/resource/ https://www.clockwork.io/resource/ [2] https://www.youtube.com/watch?v=Opf9CBwP5R8 https://www.youtube.com/watch?v=Opf9CBwP5R8
- assttoasstmgr 5y ago
  Not just that, but PTP switches modify the frame header to take into account the delta of the propagation delay through the switch. Everything is synced to the GM clock which is typically sync'd to GPS and your GM clock can itself be designed to ensure stability (e.g. temperature controlled oscillator). Furthermore, if reading the incoming data using a specialized NIC (they do this in finance, high speed trading for example) the timestamps are decoded in hardware. All this is done at the layer 2 level.
SeasonalEnnui 5y ago
From the standpoint of having used 1588, I agree. I assume the greyed out nature of your post means it isn’t popular which is a little baffling given the truth in it.
lrhegeba 5y ago
A very good overview of the different solutions can be found here: https://ying-zhang.github.io/time/2021-02-revisiting-sync/ https://ying-zhang.github.io/time/2021-02-revisiting-sync/ seems to be more of a pushing the envelope than snake oil to me, but what do i know

paxys 5y ago

Applications like Spanner work with nanosecond-level time difference between datacenters. PTP works in microseconds and can even go up to a few milliseconds, making it useless for actual time sensitive use cases.

pclmulqdq 5y ago
Spanner works fine with millisecond-level timestamps. Spanner needs accuracy, not precision: it relies on knowing the bounds on the the current time, which may be wide.
welterde 5y ago
I think you are confusing PTP and NTP. NTP is in the range of low microseconds to a few milliseconds (with hardware time-stamping can actually do much better than that though), while PTP can synchronize time to better than 100ns.

jeffwheeler 5y ago

Their website links [1] to a presentation at Stanford [2]. Mendel Rosenblum briefly compares their concept with PTP at about 45:54. He says: > Those people [fintech, etc.] are interested in our stuff, so obviously [that] means that thing [PTP] is not perfect for them. Part of the problem is, you’re trying to measure individual packets that are going through and get times. It means you have some clock there that you’re reading, and when it goes into the switch, and when it comes out, like, what is that clock doing in terms of its varying in frequency, and stuff like that. And then you get one sample and try to make things of it. It sorta pales in comparison to this big data approach we’re looking about. This seems like a mischaracterization of PTP (802.1AS), which does use multiple samples to syntonize. [1] https://www.clockwork.io/resource/ https://www.clockwork.io/resource/ [2] https://www.youtube.com/watch?v=Opf9CBwP5R8 https://www.youtube.com/watch?v=Opf9CBwP5R8

assttoasstmgr 5y ago
Not just that, but PTP switches modify the frame header to take into account the delta of the propagation delay through the switch. Everything is synced to the GM clock which is typically sync'd to GPS and your GM clock can itself be designed to ensure stability (e.g. temperature controlled oscillator). Furthermore, if reading the incoming data using a specialized NIC (they do this in finance, high speed trading for example) the timestamps are decoded in hardware. All this is done at the layer 2 level.

SeasonalEnnui 5y ago

From the standpoint of having used 1588, I agree. I assume the greyed out nature of your post means it isn’t popular which is a little baffling given the truth in it.

lrhegeba 5y ago

A very good overview of the different solutions can be found here: https://ying-zhang.github.io/time/2021-02-revisiting-sync/ https://ying-zhang.github.io/time/2021-02-revisiting-sync/ seems to be more of a pushing the envelope than snake oil to me, but what do i know