Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Is that really useful though? As soon as you need to synchronize your dataset beyond the local PTP network NTP-based timestamping becomes useless. You need a local GPS-based time reference backing PTP.


Most clients won't speak PTP or know how to deal with it.

But NTP is something that many can deal with.

So, use PTP as a refclock for your NTP service, and then let the clients deal with an interface they already know and understand.

Those clients that really care can deal with the additional complexities of PTP, if you want to let them.


It totally depends on your use case, and what you actually need in reality.

In general, once you need/want anything past what NTP can deliver for you, you really, really need to understand your use case and then design your time services to meet your specific needs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: