> As I understand it, this will not quarantee that they are millisecond
> accurate which is what you need for Cassandra to use the correct commit.
> We've seen problems in production and had to rearchitect parts of the system
> due to this even though all servers are NTP synched.
It does not matter if all clocks are infinitely well in synch. Without
actual co-ordination you cannot rely on clocks to resolve conflicting
writes correctly if there is an ordering requirement. Even with
perfect clocks, all sorts of other effects can affect the "timeline"
as observed by an outside observer. For example, the "first" client
may get context switched away by the OS just before grabbing the
current time, allowing the "second" client to obtain an earlier
timestamp.
("First" and "second" refer to some arbitrary ordering with respect to
something else; whatever it is that you are looking to achieve
ordering with respect to.)
Clocks should be synchronized, yes. But either your data model is such
that conflicting writes are okay, or you need external co-ordination.
There's not hoping for the best by keeping clocks better in synch.
--
/ Peter Schuller (@scode on twitter)
