3 ms·
you definitely cannot rely on clocks to determine (reliable) ordering across machines truetime doesn't provide precise timestamps, each timestamp has a "drift"
by preseinger 3y ago
you definitely cannot rely on clocks to determine (reliable) ordering across machines
truetime doesn't provide precise timestamps, each timestamp has a "drift" window
timestamps within the same window have no well-defined order, applications have to take this into account when doing e.g. distributed transactions
- erikerikson 3y agoThey do have a well defined order, just not one based on time.
- timf 3y agoI don't see how it isn't based on time. They use GPS and atomic clocks to establish the time, establish an uncertainty window, and in Spanner's case will have transactions wait out that uncertainty to guarantee an ordering (globally).
- erikerikson 3y agoLook up the case where two transactions affecting the same record share a timestamp (or have overlapping error ranges). An non-timestamp tiebreaker determines the order between the two overlapping commits. It is not unlike the pre-agreement on conflict resolution mechanisms for CRDTs. The context to my first comment included "timestamps within the same window"
- timf 3y agoAgree, and the timestamp comparisons you can make when the windows do not overlap are the basis of the ordering guarantees (across machines, even globally).
- preseinger 3y agokind of? not really? ordering is a logical property which can be informed by physical timestamps, but those timestamps aren't accurately described as "the basis" of that ordering
- dikei 3y ago> you definitely cannot rely on clocks to determine (reliable) ordering across machines You can if you consider "unknown/possibly concurrent" also a valid outcome: for any 2 events A and B, True Time can definitely answers whether A is before B, A is after B, or A is possibly concurrent with B.
- preseinger 3y ago"reliable ordering" usually implies a specific and well-defined order, without concurrent events :)
- deleted 3y ago[deleted]