[
https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357642#comment-15357642
]
Colin Patrick McCabe commented on HTRACE-376:
---------------------------------------------
Hi [~adriancole],
Very interesting discussion as always!
This brings to mind the famous distinction between accuracy and precision that
tends to come up in statistics. We might be able to calculate the expected
value of some random variable to 5 digits right of the decimal point, but if
there is a wide variance in the probability distribution, we can say that our
calculated expected value isn't very precise.
I agree that our software's time measurements certainly becomes imprecise when
we get down to nanoseconds. And displaying that value with high accuracy could
be misleading. However, I think nanoseconds is still the way to go, for a few
reasons:
* Some systems are more precise than others. For example, some PC systems are
configured to use the high-resolution timer (the HPET hardware) rather than the
TSC hardware. Those systems will have more accuracy. If we artificially limit
accuracy, we won't serve the more precise systems well. We don't really know
what the limits of accuracy are, and we especially don't know what the accuracy
limits of future systems might be.
* A lot of times, people want to know about durations rather than absolute
times. For example, [~pranavanc5e] is probably hoping to get some insight into
things happening on a single node in Phoenix. For this purpose, it doesn't
matter if the call to get the time has a fixed overhead. Since both the start
and end time are shifted forward, the duration will still be in the ballpark.
* People should be collecting a lot of trace data which should allow them to
look at the variance in different values for the same span. People should also
be exercising common sense and not reading too much into the duration
difference between a 500 ns span and a 501 ns span.
* People are not used to thinking in terms of microseconds because APIs tend to
be in milliseconds or nanoseconds.
bq. Moreover, eventhough unix can report time in microseconds using the
presumably cheaper gettimeofday, it cannot in nanos.
Hmm. I haven't seen anything suggesting {{gettimeofday}} is cheaper than
{{clock_gettime}}. I thought they were both implemented via the VDSO hack on
Linux, so their performance should be the same? At least on my system, the man
page for {{gettimeofday}} says that's obsolete and {{clock_gettime}} should be
used.
> 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)
