4 ms·

Smearing is alluring as a concept right up until you try and implement it in the real world. If you control all the computers that all your other computers tal

by growse 2y ago

Smearing is alluring as a concept right up until you try and implement it in the real world. If you control all the computers that all your other computers talk to (and also their time sync sources), then smearing works great. You're effectively investing your own standard to make Unix time monatomic. If, however, your computers need to talk to someone else's computers and have some sort of consensus about what time it is, then the chances are your smearing policy won't match theirs, and you'll disagree on _what time it is_. Sometimes these effects are harmless. Sometimes they're unforseen. If mysterious, infrequent buggy behaviour is your kink, then go for it!

ratorx 2y ago
Using time to sync between computers is one of the classic distributed systems problems. It is explicitly recommended against. The amount of errors in the regular time stack mean that you can’t really rely on time being accurate, regardless of leap seconds. Computer clock speeds are not really that consistent, so “dead reckoning” style approaches don’t work. NTP can only really sync to ~millisecond precision at best. I’m not aware of the state-of-the-art, but NTP errors and smearing errors in the worst case are probably quite similar. If you need more precise synchronisation, you need to implement it differently. If you want 2 different computers to have the same time, you either have to solve it at a higher layer up by introducing an ordering to events (or equivalent) or use something like atomic clocks.
- growse 2y ago
  Fair, it's often one of those hidden, implicit design assumptions. Google explicitly built spanner (?) around the idea that you can get distributed consistency and availability iff you control All The Clocks. Smearing is fine, as long as it's interaction with other systems is thought about (and tested!). Nobody wants a surprise (yet actually inevitable) outage at midnight on New year's day.
- gpderetta 2y ago
  In practice with GPS clocks and OTP you can get very good precision in the microseconds
  - withinboredom 2y ago
    Throw in chrony and you can get nanoseconds.

by growse 2y ago

ratorx 2y ago

Using time to sync between computers is one of the classic distributed systems problems. It is explicitly recommended against. The amount of errors in the regular time stack mean that you can’t really rely on time being accurate, regardless of leap seconds. Computer clock speeds are not really that consistent, so “dead reckoning” style approaches don’t work. NTP can only really sync to ~millisecond precision at best. I’m not aware of the state-of-the-art, but NTP errors and smearing errors in the worst case are probably quite similar. If you need more precise synchronisation, you need to implement it differently. If you want 2 different computers to have the same time, you either have to solve it at a higher layer up by introducing an ordering to events (or equivalent) or use something like atomic clocks.

growse 2y ago
Fair, it's often one of those hidden, implicit design assumptions. Google explicitly built spanner (?) around the idea that you can get distributed consistency and availability iff you control All The Clocks. Smearing is fine, as long as it's interaction with other systems is thought about (and tested!). Nobody wants a surprise (yet actually inevitable) outage at midnight on New year's day.
gpderetta 2y ago
In practice with GPS clocks and OTP you can get very good precision in the microseconds
- withinboredom 2y ago
  Throw in chrony and you can get nanoseconds.