[
https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15342898#comment-15342898
]
Colin Patrick McCabe commented on HTRACE-376:
---------------------------------------------
So, there's a bunch of fairly complicated issues here. I posted a patch which
I think addresses them all.
First of all, like I said, we can't "cheat" and use times that are only
meaningful on a single node. If node1 says an event happened at time 1, and
node2 says another event happened at time 1000, we should be able to assume
that there were 999 time units in between them. This rules out using
{{System.nanoTime}} directly, as I've mentioned several times. It is a
system-local time, and we need a global time. Unfortunately, Java doesn't
offer any API to get a wall-clock time with nanosecond granularity.
There will be better time APIs coming out in future JVM versions. Until then,
as a workaround, we can try to correlate the monotonic clock with the wall
clock, and get a wall-clock nanosecond estimate out of that. The code I posted
uses {{NanoTimeTimeSource}} to do that.
Secondly, there shouldn't be any need to store times in both milliseconds and
nanoseconds. If we put nanoseconds since the epoch into a long, we still have
(2^63) / (10^9 * 60 * 24 * 365) = 17548 years of post-1970 time which we can
cover. I'm OK with the HTrace project lasting for "only" 17,000 years.
Overwriting the time in milliseconds should also set the time in nanoseconds,
and vice versa.
We need to change the Span JSON to support nanoseconds. I have done this by
adding the 'E' and 'B' (i.e. capital letter) fields in addition to the 'b' and
'e' fields. Also, we need nanosecond granularity for span time annotations as
well as spans.
Finally, we need some way of choosing to use millisecond granularity versus
nanosecond granularity. The code does this by looking at the configuration key
{{time.granularity}}, which can be either {{ns}} for nanoseconds or {{ms} for
milliseconds. This determines which {{TimeSource}} we use when creating spans.
bq. Nano time call is pretty expensive because it will take like 100+ cpu clock
cycles whereas System.currentMillis() will just take 5 or 6 cpu clock cycles.
Nanotime is an expensive operation. (In my opinion calling nanotime is a
barrier for performance)
That is true only on Windows, not on Linux. There are some relevant answers on
Stack Overflow you could look at. In any case, this will be configurable and
the default will be milliseconds.
> HTrace should support nanosecond time granularities
> ---------------------------------------------------
>
> Key: HTRACE-376
> URL: https://issues.apache.org/jira/browse/HTRACE-376
> Project: HTrace
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.1.0
> Reporter: Colin Patrick McCabe
> Assignee: Pranavan
> Attachments: HTRACE-376.001.patch, HTRACE-376.002.patch,
> HTRACE-376.003.patch
>
>
> HTrace should support nanosecond time granularities. Currently only a
> granularity of milliseconds is supported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
