Huygens: Scalable, Fine-grained Clock Synchronization [pdf] | Hacker News Reader

Huygens: Scalable, Fine-grained Clock Synchronization [pdf]

usenix.org

70 pointsotterley9 comments

I like the topic of clock synchronization, so I read the paper. It's about three ideas:

1. "Coded probes," or a group of temporally structured packets that are robust against random queuing delays and timestamping noise. The paper proposes that the sender sends two packets with a fixed time interval so if the receiver gets some other interval this data pair must have been corrupted. I didn't find any argument on why the scheme is good at identifying noise points besides a note about a 4-5x improvement. I don't think this scheme necessarily identifies all noise points but it should be able to eliminate some of the true positive noise points because of the temporal constraint. More temporally sophisicated structures may have even better performance at this task.

2. So they collected a bunch of the coded probes and plotted them and found out it somehow looked like the classic plot of the linear SVM, or actually the error model of the measurement scheme being a stable lower bound of transmission time plus a positive somewhat exponentially distributed error. They use a SVM to identify the lower bound because the data fits the SVM perfectly. I think more sophisticated models can also apply here given proper probabilistic accounting of the error model.

3. Cooperative network synchronization. In essence getting better accuracy by averaging several clocks but in a network you can't average them directly so it becomes message-passing on a probabilistic graphical model. As an analogy think of a network of springs, and the network is optimized/converged when all springs are at their lowest energy levels.

I guess hardware-based techniques like 1588 and SyncE will come down in price in a few years. It seems natural that consumer-premises equipment will start offering 1588 in, say, 2 years. Cheap 1588 can get you within 3ns, fancy switches can get you to within .3ns.

Won’t it be hard for 1588 hardware to compete on price with a pure software solution?

1588 isn't just used for clock synchronization. A software solution will never allow you to know when a packet leaves/enters your network PHY, which enables some of it's other use cases.

Hrmm yes a fair point. Also I see this paper suggests burning half a percent of your CPU resources for time synchronization which they wave away but I find to be quite substantial.

> half a percent of your CPU resources for time synchronization

Why do you find that to be substantial? Given most machines are at least 50% idle, I find 0.5% to be acceptable.

It's actually quite difficult to get utilization up past about 60% on average at a large scale, and when utilization increases efficiency decreases (from missed clock turbo opportunities and other microarchitectural feedback). So if you are using half a percent of your nominal capacity that's 1% of your total CPU usage. 1% is a lot at scale. For example at Google's scale that would be enough to justify a team of several full-time engineers to find a more efficient way to do it. Even saving 0.01% of CPU time is considered a pretty good outcome at large companies (Amazon, Microsoft, Facebook, ...).

Many (all?) Intel network adapters from the last decade have support for ieee1588; that includes embedded options like the i219-LM (and earlier models in that family): https://ark.intel.com/products/82185/Intel-Ethernet-Connecti...

ethtool -T eth0

will show if you have a PTP support for your NIC.

Reply on news.ycombinator.com