[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979668#comment-13979668
]
Benedict commented on CASSANDRA-6106:
-------------------------------------
Well, if we're not worried about monotonicity, we can certainly simplify the
patch - but I would much rather not introduce a new thread for updating the
spec; if we're incurring the micros cost on a seconds time horizon, incurring
it a few times each second is irrelevant (even a few times per thread in the
worst case), it's just a matter of ensuring that we don't incur those micros
costs for _every_ query, as it would be a really noticeable percentage of total
operation time. We already have far more threads than necessary, let's not
introduce one here where it's not necessary (note that 3x loop is only ever
going to occur if we overlap with a GC pause, so we're only likely to loop
twice at most, and almost never more than once).
Still, I'd much prefer that we just get comfortable with the math, since if we
don't address it now it will go on the backburner and be forgotten. Correctness
relies on integer arithmetic always truncating instead of rounding, so there's
no floating point weirdness or edge cases to contend with. Behaviour is the
same for all value ranges. We always apply a delta to a fixed offset, and the
delta is calculated by multiplying by a monotonically increasing value, and
dividing by a fixed value - as such the monotonically increasing multiplier
either pushes the combined value over into the next whole number after
division, or it doesn't. Since we are also guaranteed to only ever move by at
most 10% of the elapsed time interval, we essentially get (at most) 1
microsecond in 10 simply appears to take 2 microseconds to elapse.
TL;DR: every x microseconds we deduct an extra 1microsecond when adjusting
backwards, so we can only ever stall time (by 1 microsecond), never jump
backwards.
Either way, since your patch applies no monotonicity guarantees, any slight
risk I'm wrong in the analysis really doesn't seem to be important - it's still
much better than without it, if that's your only concern?
> Provide timestamp with true microsecond resolution
> --------------------------------------------------
>
> Key: CASSANDRA-6106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6106
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: DSE Cassandra 3.1, but also HEAD
> Reporter: Christopher Smith
> Assignee: Benedict
> Priority: Minor
> Labels: timestamps
> Fix For: 2.1 beta2
>
> Attachments: microtimstamp.patch, microtimstamp_random.patch,
> microtimstamp_random_rev2.patch
>
>
> I noticed this blog post: http://aphyr.com/posts/294-call-me-maybe-cassandra
> mentioned issues with millisecond rounding in timestamps and was able to
> reproduce the issue. If I specify a timestamp in a mutating query, I get
> microsecond precision, but if I don't, I get timestamps rounded to the
> nearest millisecond, at least for my first query on a given connection, which
> substantially increases the possibilities of collision.
> I believe I found the offending code, though I am by no means sure this is
> comprehensive. I think we probably need a fairly comprehensive replacement of
> all uses of System.currentTimeMillis() with System.nanoTime().
--
This message was sent by Atlassian JIRA
(v6.2#6252)
