[jira] [Comment Edited] (CASSANDRA-7979) Acceptable time skew for C*

["Ryan Svihla (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253398#comment-14253398 ] 

Ryan Svihla edited comment on CASSANDRA-7979 at 12/19/14 2:01 PM:
------------------------------------------------------------------

For the record, if we rename it to something more innocuous such as (horrible name but tossing it out there to start the conversation) "key update frequency" I'd be a lot less concerned

Update:

I was reading the patch notes and it looks like the name is a lot less silly in the code 
ColUpdateTimeDeltaHistogram

Again I debate the real value of this, but as long as it's not a minefield and we document it in a way that prevents a giant huge gaping pit I'll deal with it.


was (Author: rssvihla):
For the record, if we rename it to something more innocuous such as (horrible name but tossing it out there to start the conversation) "key update frequency" I'd be a lot less concerned

> 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
>             Fix For: 2.0.12, 2.1.2, 3.0
>
>         Attachments: 2.0_7979.diff, 2.0_7979_v2.txt, 2.0_7979_v3.txt, 2.1_7979_v2.txt, trunk_7979.diff, trunk_7979_v2.txt
>
>
> 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)