[ https://issues.apache.org/jira/browse/CASSANDRA-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140078#comment-14140078 ]
Benedict commented on CASSANDRA-7979: ------------------------------------- I think this is an excellent idea. We can ensure low cost by only taking the minimum delta for all columns in a given update. Once we deliver improved latency metrics there will be effectively no cost/competition for maintaining this, but in the meantime this will keep it low enough. > Acceptable time skew for C* > --------------------------- > > Key: CASSANDRA-7979 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7979 > Project: Cassandra > Issue Type: Improvement > Reporter: sankalp kohli > Assignee: sankalp kohli > Priority: Minor > > It is very hard to know the bounds on clock skew required for C* to work > properly. Since the resolution is based on time and is at thrift column > level, it depends on the application. How fast is the application updating > the same column. If you update a column say after 5 millisecond and the clock > skew is more than that, you might not see the updates in correct order. > In this JIRA, I am proposing a change which will answer this question: "How > much clock skew is acceptable for a given application". This will help answer > the question whether the system needs some alternate NTP algorithms to keep > time in sync. > If we measure the time difference between two updates to the same column, we > will be able to answer the question on clock skew. > We can implement this in memtable(AtomicSortedColumns.addColumn). If we find > that a column is updated within say 100 millisecond, add the diff to a > histogram. Since this might have performance issues, we might want to have > some throttling like randomization or only enable it for a small time via > nodetool. > With this histogram, we will know what is an acceptable clock skew. > Also apart from column resolution, is there any other area which will be > affected by clock skew? > Note: For the sake of argument, I am not talking about back date deletes or > application modified timestamps. -- This message was sent by Atlassian JIRA (v6.3.4#6332)