IdeaWell

Project ideas from Hacker News discussions.

Clock synchronization is a nightmare

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

1. PTP Achieves Sub-Microsecond Precision Without Extensive Network/CPU Support

Debate centers on PTP outperforming NTP using hardware timestamping on commodity NICs, even across mixed networks and with CPU sleep states enabled.
"DannyBee: PTP does not require support on your network beyond standard ethernet packet forwarding... I have used both ethernet and multicast PTP across a complete mishmash of brands and types... with no issues... maintaining time +-35ns of the grandmaster."
"Here is the stats from a random embedded device... 0.000000029 seconds slow of NTP time."

2. Relativity Imposes Fundamental Limits on Clock Synchronization

Inspired by Feynman, users discuss special relativity's relativity of simultaneity, causality via light cones, and why perfect global sync is impossible.
"emptybits: synchronizing two clocks is ... meaningless?"
"ianburrell: In special relativity, time is relative... Casually linked events are always really in the same order. But disconnected events can be seen in different orders depending on speed of observer."

3. Logical Clocks and TrueTime Preferable for Distributed Systems Over Perfect Physical Sync

TrueTime handles bounded uncertainty for consistency (e.g., Spanner); logical clocks avoid wall-clock issues entirely.
"josephg: swap to a logical clock - which doesn’t care about wall time... event A happened before event B iff A ... was observed by the node that generated B before B was generated."
"kccqzy: Spanner... assign a timestamp to T2 that is higher than T1's timestamp... That’s the radical developer simplicity promised by TrueTime."

🚀 Project Ideas

PTP Hardware Validator

Summary

  • An open-source automated testing suite and community database for benchmarking PTP performance across NICs, switches, drivers, and OS configs.
  • Solves validation pains at scale by providing plug-and-play tests and crowdsourced compatibility lists, reducing reliance on vendor labs.

Details

Key Value
Target Audience Sysadmins, timing server vendors, HFT/audio/robotics engineers deploying PTP
Core Feature Run standardized PTP sync tests (offset, jitter, holdover); upload results to public db with search/filter by hardware
Tech Stack Linux (ptp4l/linuxptp), Python/Docker for tests, PostgreSQL + web UI (React) for db
Difficulty Medium
Monetization Revenue-ready: Freemium SaaS for enterprise test reports

Notes

  • "being able to validate things like switches and network card drivers is useful too! ... vendors have their own test labs where they have to validate network gear and then publish lists" (geerlingguy).
  • HN would love the crowdsourced db for practical "recommended configs"; sparks discussions on quirks.

Robotics SteadyClock Library

Summary

  • A C++/ROS2 library enforcing monotonic "steady time" from boot, with optional safe sync to external sources (PTP/GPS/NTP) that never jumps backward, logging offsets for post-analysis.
  • Addresses robotics crashes from OS time skew/jumps, enabling reliable event ordering without global wall time.

Details

Key Value
Target Audience Robotics developers (ROS users, autonomous vehicles, drones)
Core Feature Boot-time epoch anchor; drift-corrected sync with jump detection/prevention; ROS topic for offset-corrected timestamps
Tech Stack C++20 (std::steady_clock), ROS2, linuxptp integration
Difficulty Medium
Monetization Hobby

Notes

  • "Clock sync is such a nightmare in robotics. Most OSes happily will skew/jump to get the time correct. Time jumps (especially backwards) will crash most robotics stacks" (a_t48); "time from startup only!".
  • High utility for robotics HN crowd; fosters debates on logical vs physical clocks.

DNS-Resilient NTP Manager

Summary

  • A drop-in NTP daemon replacement/configurator using static IP lists (e.g., NIST), auto-retries on DNS failure, holdover monitoring, and multi-source fallback (PPS/PTP).
  • Fixes bootstrap loops from DNSSEC/NTP pool, ntpsec retry bugs, and intermittent connectivity for edge/IoT/datacenter reboots.

Details

Key Value
Target Audience DevOps, IoT/router devs, datacenter ops avoiding DNS pitfalls
Core Feature Static IP pools; exponential-backoff DNS retries; holdover alerts; systemd integration for post-boot sync
Tech Stack Go/Rust (ntpd fork), systemd unit, Prometheus metrics
Difficulty Low
Monetization Revenue-ready: Open core + paid cloud dashboard

Notes

  • "NTP pool server usage requires using DNS * people have DNSSEC setup, which requires accurate time or it fails ... ntpsec has a horrible bug where ... pool server addresses are never retried" (b112).
  • Practical fix for common outages; HN would share war stories and configs.

Read Later