[tracking] Use high resolution time in Jaeger clients

[yurishkuro]

In most Jaeger clients we are using the default timer to capture timestamps, which is often only accurate to milliseconds. Most languages provide nanosecond-resolution timers, but those can only be used to measure durations, not get the wall clock timestamps. It is possible to make those work with the default timer by using the following technique

• on the first span in process for a given trace, capture

  • the timestamp T1 using default timer. It will have millisecond precision, but that's ok since we normally expect a clock skew between processes anyway
  • the initial value t1 of the high resolution timer

• keep the reference to these two values in all other spans started in the process for this trace

• every time a new timestamp needs to be captured, use the current value t of the high resolution timer and calculate the new timestamp T = T1 + (t - t1)

• Node.js client Investigate high resolution timers jaeger-client-node#31

[m1o1]

We were thinking about a similar calculation actually, but stumbled upon this:
https://github.com/wadey/node-microtime
which I guess uses a native node addon to provide the time.

[vprithvi]

Could you tie this to a use case? I'm not a fan of the technique proposed as it adds precision without adding accuracy.

[m1o1]

We use a redis cache and some spans are < 1 ms, which gets rounded to 0 and causes start times to be the same. This results in spans that should show up after this span as showing up before it in the Jaeger UI and is a difficult case to handle in the tools we're making for analyzing these traces.

[yurishkuro]

The use case is measuring spans with sub-millisecond durations, which is quite possible on fast networks. It has been asked on a number of occasions across different repos and chat (but I am too lazy to go hunt for references).

[vprithvi]

The use case is measuring spans with sub-millisecond durations

@yurishkuro Wouldn't durations only require high resolution timers (as opposed to high resolution wall clock timestamps)

[yurishkuro]

That can be the first step, which is indeed much easier to implement, but it would still create misleading Gantt chart for such short traces since all span.startTime's will be clamped to 1ms.

[Falco20019]

In C#, this highly depends on OS version and .NET runtime. Around the end of 2017, it got improved to be precise about 0.1us. Before we were at around 15ms or 0.2ms when using workarounds.

So using .NET Standard and .NET Core 2.1+ on a current platform (Unix or Windows) should already have that accuracy available in our current implementation.

[yurishkuro]

Per #3362, we're sunsetting Jaeger clients.