If you require the best precision you can get, setting up a pair of
stratum 1 ntpd masters in each data center location with a GPS modules
is not terribly complex. Low latency and jitter on servers you manage.
140ms is a long way away network-wise, and I would suggest that was a
poor choice of upstream (probably stratum 2 or 3) source.
As Jonathan mentioned, there's no guarantee from Cassandra, but if you
need as close as you can get, you'll probably need to do it yourself.
(I run several stratum 2 ntpd servers for pool.ntp.org)
On 02/09/2017 06:47 PM, Kant Kodali wrote:
> Hi Justin,
> There are bunch of issues w.r.t to synchronization of clocks when we
> used ntpd. Also the time it took to sync the clocks was approx 140ms
> (don't quote me on it though because it is reported by our devops :)
> we have multiple clients (for example bunch of micro services are
> reading from Cassandra) I am not sure how one can achieve
> Linearizability by setting timestamps on the clients ? since there is no
> total ordering across multiple clients.
> On Thu, Feb 9, 2017 at 4:16 PM, Justin Cameron <justin@xxxxxxxxxxxxxxx
>> wrote:> <mailto:kant@xxxxxxxxxxxx>> wrote:
> Hi Kant,
> Clock synchronization is important - you should ensure that ntpd is
> properly configured on all nodes. If your particular use case is
> especially sensitive to out-of-order mutations it is possible to set
> timestamps on the client side using the
> drivers. https://docs.datastax.com/en/
> We use our own NTP cluster to reduce clock drift as much as
> possible, but public NTP servers are good enough for most
> uses. https://www.instaclustr.com/
> On Thu, 9 Feb 2017 at 16:09 Kant Kodali <kant@xxxxxxxxxxxx
> How does Cassandra achieve Linearizability with “Last write
> wins” (conflict resolution methods based on time-of-day clocks) ?
> Relying on synchronized clocks are almost certainly
> non-linearizable, because clock timestamps cannot be guaranteed
> to be consistent with actual event ordering due to clock skew.
> isn't it?
> Justin Cameron
> Senior Software Engineer | Instaclustr
> This email has been sent on behalf of Instaclustr Pty Ltd
> (Australia) and Instaclustr Inc (USA).
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do
> not copy or disclose its content, but please reply to this email
> immediately and highlight the error to the sender and then
> immediately delete the message.