[
https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356360#comment-15356360
]
Adrian Cole commented on HTRACE-376:
------------------------------------
PS in case it helps, I just recently implemented something like this in another
library that previously used millis.
https://github.com/spring-cloud/spring-cloud-sleuth/issues/312
Here's a footnote that may or may not be distracting from that:
I'd suggest not advertising duration in nanoseconds because we cannot
accurately measure at that granularity due to the overhead and change frequency
of System.nanoTime(). For example, if calling nanoTime has to happen twice, and
we should expect 30nanos overhead per call, we can't reliably report duration
in orders of nanos. Moreover, eventhough unix can report time in microseconds
using the presumably cheaper gettimeofday, it cannot in nanos. In short, micros
ends up a pretty decent choice for various reasons even if we didn't consider
zipkin which uses micros consistently for everything.
> 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: Colin Patrick McCabe
> 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)
