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

How Precision Time Protocol is being deployed at Meta

engineering.fb.com

Post reply on HN
Print view View original

51–60 of 104 posts

Re: How Precision Time Protocol is being deployed at Meta

#51

Post by capableweb »

elcomet wrote: post #47
epgui wrote: post #35

Earlier quoted context omitted.

Yeah that's exactly my concern! I want to contribute to building cool things, and building a really cool component becomes much less inspiring if it's only used to steer nuclear missiles. (dramatic but not unreasonable example)

You could apply to work on the research infrastructure (for instance for AI)

And instead of writing infrastructure for the developers who write code for ads, you now write AI software/do AI research for a company in order to attract enough talent so they can hire developers to write infrastructure for the developers who write code for ads?

Or you know, just don't work for companies who tend to collect as much user data as they can?

Re: How Precision Time Protocol is being deployed at Meta

#53

Post by m463 »

CapmCrackaWaka wrote: post #6

Why do so many tech companies seem to be releasing “secret sauce” for free lately? I see a lot of posts lately detailing how inner production systems work at large companies, and while I’m grateful, I’m curious why the higher ups think it’s worthwhile to release this information.

I suspect performance metrics

Many higher-level engineering positions have performance reviews with metrics that include some sort of industry expertise or external collaboration.

Re: How Precision Time Protocol is being deployed at Meta

#54

Post by SpaceManNabs »

foobiekr wrote: post #18
CapmCrackaWaka wrote: post #6

Why do so many tech companies seem to be releasing “secret sauce” for free lately? I see a lot of posts lately detailing how inner production systems work at large companies, and while I’m grateful, I’m curious why the higher ups think it’s worthwhile to release this information.

PTP isn’t secret sauce. Routers I worked on were doing PTP in like 2009. 1588 was standardized in 2002.

> 1588 was standardized in 2002.

offtopic but this sentence is beautiful to me.

Re: How Precision Time Protocol is being deployed at Meta

#56

Post by [deleted] »

throw0101a wrote: post #7

So they state: > One could argue that we don’t really need PTP for that. NTP will do just fine. Well, we thought that too. But experiments we ran comparing our state-of-the-art NTP implementation and an early version of PTP showed a roughly 100x performance difference: While I'm not necessarily against more accuracy/precision, what problems specifically are experiencing? They do mention some use cases of course: > Th…

[deleted]

Re: How Precision Time Protocol is being deployed at Meta

#57

Post by s1mon »

It's interesting that Meta is doing such serious low level R&D like this, but it's funny because they can't even keep their notifications in sync with their web site. I get a notification (from the mobile app, I think) that Joe has a birthday today, I go to the web page to wish them a happy birthday, and despite reloading, the web site still shows the birthdays from the previous day. Then I have to dig around more to find Joe's page to post a HBD.

So as user, this level of time synchronization seems to be many orders of magnitude of over kill. I'm sure at some level it is actually important, but it seems like the database sync or whatever is going on with notifications is woefully lagging.

Re: How Precision Time Protocol is being deployed at Meta

#58

Post by zie »

willis936 wrote: post #26
kazinator wrote: post #3

It is not accurate to say that PTP is a predecessor to NTP. You need both. PTP synchronizes clocks to a ridiculous precision, like down to nanoseconds. To do that, it uses support in the ethernet hardware. Hardware adds precision stamps to the PTP-related ethernet frames, so that the time calculations are free of jitters induced by the higher network stacks. A cool thing is that PTP-aware routers/switches can actuall…

Just because high precision tasks don't care about time of day as much, PTP still uses TAI timestamps. The only time of day information missing is leap seconds, and those were a mistake that is being corrected. You don't need NTP for time of day when PTP is used.

The point being you need a source of truth for PTP to figure out what the current date and time are. You won't be pushing PTP over the public internet, that's ridiculous. You can use a GPS/sat sync or atomic clock or NTP, doesn't matter, but something has to tell PTP what time it is. If you don't, then you will be subject to quartz crystal drift. It may or may not matter to your application(s), but for most people that care about time, they want the TAI timestamps to be at least reasonably accurate.

Re: How Precision Time Protocol is being deployed at Meta

#59

Post by amluto »

I’m wondering whether the extremely careful GNSS part is really needed. A microsecond of offset between two servers in the same datacenter could easily matter, but I suspect that, if an entire datacenter were off by a microsecond, everything would be fine — communicating from that datacenter to anywhere else will take well over a microsecond, so an offset of this type would be a bit like the datacenter wiggling around in space a bit.

On a different note, there’s an Intel feature called the Always Running Timer. In theory one ought to be able to directly determine the TSC NIC clock offset using the ART. I’m not sure anyone has gotten this to work, though.

Re: How Precision Time Protocol is being deployed at Meta

#60

Post by walrus01 »

amluto wrote: post #59

I’m wondering whether the extremely careful GNSS part is really needed. A microsecond of offset between two servers in the same datacenter could easily matter, but I suspect that, if an entire datacenter were off by a microsecond, everything would be fine — communicating from that datacenter to anywhere else will take well over a microsecond, so an offset of this type would be a bit like the datacenter wiggling aroun…

Having rooftop mounted GNSS receive antennas for GPS+GLONASS is extremely common in telecom and ISP infrastructure applications. It's sort of a belt and suspenders approach to obtaining time from low stratum NTP sources and also having a local GNSS timing source to reference from.

Or for use in a case where the network has a total absence of connectivity to any internet-based NTP sources (maybe because your management network doesn't talk to the internet at all, for many good reasons), and in the event of loss of transport connectivity to your own somewhere-in-the-region NTP servers in your management system, you want to be absolutely sure the system clocks on your local radio transport equipment, DWDM equipment, metro ethernet stuff are all precise.

Using receive-only GPS data as a master time reference source is effectively saying "we think that getting the time as it's set by the USAF/Space Force people at Schriever AFB, who run the GPS system, should be treated as our master point of reference and all other clocks should derive from that". It's not a bad policy, as such things go, because GPS maintaining extremely accurate time is of great interest to the US federal government as a whole.

Even a fairly small LTE cellular rooftop site, monopole or tower often has a similar receiver. It doesn't add a lot of cost.

Post reply on HN