Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clock synchronization is a nightmare

arpitbhayani.me

Post reply on HN
Print view View original

131–140 of 165 posts

Re: Clock synchronization is a nightmare

#131

Post by bigfatkitten »

forrestthewoods wrote: post #29

Timesync isn’t a nightmare at all. But it is a deep rabbit hole. The best approach, imho, is to abandon the concept of a global time. All timestamps are wrt a specific clock. That clock will skew at a rate that varies with time. You can, hopefully, rely on any particular clock being monotonous! My mental model is that you form a connected graph of clocks and this allows you to convert arbitrary timestamps from any cl…

> I kinda don’t like PTP. Too complicated and requires specialized hardware.

At this stage, it's difficult to find an half-decent ethernet quality MAC that doesn't have PTP timestamping. It's not a particularly complicated protocol, either.

I needed to distribute PPS and 10MHz into a GNSS-denied environment, so last summer I designed a board to do this using 802.1AS gPTP with a uBlox LEA-M8T GNSS timing receiver, a 10MHz OCXO and an STM32F767 MCU. This took me about four weeks. Software is written in C, and the PTP implementation accounts for 1500 LOC.

Re: Clock synchronization is a nightmare

#132

Post by DannyBee »

jeffbee wrote: post #100
DannyBee wrote: post #87

Earlier quoted context omitted.

"Well, if the goal is for software running on the host CPU to know the time accurately, then it does matter. " I'm sorry, this is just moving the goalposts. You said "It can't achieve better-than-NTP results without disabling PCI power saving features and deep CPU sleep states." This is flat wrong, as pointed out. Now you are pedantically arguing that some NIC's that do PTP hardware timestamping might also use a feat…

I see nothing in your pair of unnecessarily belligerent comments that actually contradicts what I said. There are host-side features that enable the clock discipline you are observing, even if you are apparently not aware of them.

This is a really helpful contribution - if only everyone could be as smart as you.

If mine are somehow too beligerent for you, which is hilarious given how arrogant and beligerent your initial comment and responses come off as (maybe you are not aware?), then perhaps you'd like to actually engage any of the other comments that point out how wrong you are in a meaningful way?

Or are those too beligerent as well?

Because you didn't respond to any of those, either.

Re: Clock synchronization is a nightmare

#133

Post by varjag »

8n4vidtmkvmk wrote: post #118
baby_souffle wrote: post #91

Earlier quoted context omitted.

Not just audio, anybody in the live events / production space needs all equipment marching in lock step.

If it's for an event, can they not bring all the devices together in close proximity and sync them somehow? That at least removes network delays

You can't sync individual oscillators precisely for very long.

Re: Clock synchronization is a nightmare

#134

Post by varjag »

blibble wrote: post #14
maximinus_thrax wrote: post #8

I wouldn't say it's a 'nightmare'. It's just more complicated than what regular folk think computers work when it comes to time sync. There's nothing nightmareish or scary about this, it's just using the best solution for your scenario, understanding limitations and adjusting expectations/requirements accordingly, perhaps relaxing consistency requirements. I worked on the NTP infra for a very large organization some…

PTP isn't even that much more difficult, as long as you planned for it form the start you buy the hardware, plug it all in, and it works

We once spent two weeks identifying a PTP handling bug in a particular Cisco switch firmware on a production site.

Re: Clock synchronization is a nightmare

#135

Post by varjag »

emptybits wrote: post #6

Normally I would nod at the title. Having lived it. But I just watched/listened to a Richard Feynmann talk on the nature of time and clocks and the futility of "synchronizing" clocks. So I'm chuckling a bit. In the general sense, I mean. Yes yes, for practical purposes in the same reference frame on earth, it's difficult but there's hope. Now, in general ... synchronizing two clocks is ... meaningless? https://www.yo…

Feynman was not entirely sincere. The implosion of nuclear device requires precise synchronization of multiple detonations. Basically the more precisely you can trigger the less fissile material you need for the sphere. To the day high accuracy bridgewire/foil bridge designs remain on ITAR.

Re: Clock synchronization is a nightmare

#137

Post by Nextgrid »

Uehreka wrote: post #77
NelsonMinar wrote: post #48

On the flipside, clock sync for civilians has never been easier. Thanks to NTP any device with an Internet connection can pretty easily get time accurate to 1 second, often as little as 10 ms. All major consumer computers are preconfigured to sync time to one of several reliable NTP pools. This post is about more complicated synchronization for more demanding applications. And it's very good. I'm just marveling at ho…

I was doing something at work that involved calculating round trip times from/to Android devices, and learned that although it should be possible for NTP to sync clocks with below-second precision, in practice many of the Android devices I was working with (mostly Pixels 2-7) were off from my server and each other by up to 5 seconds, which blew my mind.

Depending on carrier-specific configuration and firmware phones may be configured to prefer NITZ (time transmitted by the cellular network) instead of NTP. That time is probably what’s off and would explain your observation.

Re: Clock synchronization is a nightmare

#138

Post by glopesdev »

emptybits wrote: post #6

Normally I would nod at the title. Having lived it. But I just watched/listened to a Richard Feynmann talk on the nature of time and clocks and the futility of "synchronizing" clocks. So I'm chuckling a bit. In the general sense, I mean. Yes yes, for practical purposes in the same reference frame on earth, it's difficult but there's hope. Now, in general ... synchronizing two clocks is ... meaningless? https://www.yo…

> But I just watched/listened to a Richard Feynmann talk on the nature of time

I hate to break it to you, but you were fooled by an AI dupe. Also took me a while to realise this. It’s sad we live in this tiring world where we have to fact check every single piece of content for authenticity. It’s just tiring. I’m sure many will reply it doesn’t matter, which of course will be funny to consider given someone went to the work of vocal cloning Feynman to make a channel of content (copyrighted of course) while claiming “no disrespect intended”.

Re: Clock synchronization is a nightmare

#139

Post by [deleted] »

DannyBee wrote: post #132
jeffbee wrote: post #100

Earlier quoted context omitted.

I see nothing in your pair of unnecessarily belligerent comments that actually contradicts what I said. There are host-side features that enable the clock discipline you are observing, even if you are apparently not aware of them.

This is a really helpful contribution - if only everyone could be as smart as you. If mine are somehow too beligerent for you, which is hilarious given how arrogant and beligerent your initial comment and responses come off as (maybe you are not aware?), then perhaps you'd like to actually engage any of the other comments that point out how wrong you are in a meaningful way? Or are those too beligerent as well? Becau…

[deleted]

Re: Clock synchronization is a nightmare

#140

Post by throw0101c »

RossBencina wrote: post #88
throw0101c wrote: post #75

Earlier quoted context omitted.

> Then when someone flies over your datacenter with an GPS jammer (purposeful or accidental), this needs to not be a bad day where suddenly database transactions happen out of order, or you have an outage. Most NTP/PTP appliances have internal clocks that are OCXO or rubidium that have holdover (even for several days). If time is that important to you then you'll have them, plus perhaps some fibre connections to othe…

> fibre connections to other sites that are hopefully out of range of the jamming. I guess it's not inconceivable that eventually there's a global clock network using a White-Rabbit-like protocol over dedicated fibre. But if you have to worry about GPS jamming you probably have to worry about undersea cable cutting too.

> But if you have to worry about GPS jamming you probably have to worry about undersea cable cutting too.

GPS jamming can be done by a random truck driver:

* https://www.cnet.com/culture/truck-driver-has-gps-jammer-acc...

Cutting cables at the bottom of the sea is an entire different class of attack (anchors notwithstanding).

Post reply on HN