5 ms·

Can you elaborate on the need? What possible reason, short of a very contrived one, is there for having to keep a large number of machines' clocks in-sync? And

by zo1 11y ago

Can you elaborate on the need? What possible reason, short of a very contrived one, is there for having to keep a large number of machines' clocks in-sync? And for that matter, why would anyone build any process/system/software that requires a distributed system's machines to all have their clocks in-sync. I am baffled.

matthewmacleod 11y ago
Well, it's a reasonable solution to some distributed problems. I imagine that many distributed algorithms can be simplified a lot of you have a reliable and accurate time source. If you can build a reliable clock at less cost (development and/or overhead) than a time-insensitive algorithm would cost, then why not do it?
pjungwir 11y ago
Many security protocols use credentials that are only valid for a brief time. Here is a simple example of a problem caused by my server's time being more than 10 minutes off from the time on S3: http://illuminatedcomputing.com/posts/2015/04/paperclip_expiring_url_and_request_has_expired/ http://illuminatedcomputing.com/posts/2015/04/paperclip_expi...
- abrookewood 11y ago
  Yep, security is a big one. Authentication & encryption can behave very unpredictably if your times are not in sync. So, you might not be able to login to a server, or connect via HTTPS etc
lmorris84 11y ago
I believe Google Spanner obsesses over timestamps quite a lot to deliver distributed transactions with something called TrueTime [1]. [1] http://research.google.com/archive/spanner.html http://research.google.com/archive/spanner.html
amaks 11y ago
There is a simple reason why it's needed - in distributed transaction you need to establish the causality of changes. That's why truetime is needed.
deleted 11y ago
[deleted]
ska 11y ago
Sorry - missed this somehow. People have mentioned distributed transactions and security, another area is synchronizing modeling with (hard or soft) real time inputs from separate hardware. There are a bunch of ways to get yourself tied up in knots once at least 2 physical bits of hardware are involved.

by zo1 11y ago

matthewmacleod 11y ago

Well, it's a reasonable solution to some distributed problems. I imagine that many distributed algorithms can be simplified a lot of you have a reliable and accurate time source. If you can build a reliable clock at less cost (development and/or overhead) than a time-insensitive algorithm would cost, then why not do it?

pjungwir 11y ago

Many security protocols use credentials that are only valid for a brief time. Here is a simple example of a problem caused by my server's time being more than 10 minutes off from the time on S3: http://illuminatedcomputing.com/posts/2015/04/paperclip_expiring_url_and_request_has_expired/ http://illuminatedcomputing.com/posts/2015/04/paperclip_expi...

abrookewood 11y ago
Yep, security is a big one. Authentication & encryption can behave very unpredictably if your times are not in sync. So, you might not be able to login to a server, or connect via HTTPS etc

lmorris84 11y ago

I believe Google Spanner obsesses over timestamps quite a lot to deliver distributed transactions with something called TrueTime [1]. [1] http://research.google.com/archive/spanner.html http://research.google.com/archive/spanner.html

amaks 11y ago

There is a simple reason why it's needed - in distributed transaction you need to establish the causality of changes. That's why truetime is needed.

deleted 11y ago

[deleted]

ska 11y ago

Sorry - missed this somehow. People have mentioned distributed transactions and security, another area is synchronizing modeling with (hard or soft) real time inputs from separate hardware. There are a bunch of ways to get yourself tied up in knots once at least 2 physical bits of hardware are involved.