Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

microsecond precision timestamp #16

Open
jendap opened this issue Oct 11, 2016 · 2 comments
Open

microsecond precision timestamp #16

jendap opened this issue Oct 11, 2016 · 2 comments

Comments

@jendap
Copy link

jendap commented Oct 11, 2016

Millisecond is eternity in microservice world. More than a request duration if one builds something "micro". And for better or worse many people do. (and some other folks have just really fast machines and network)

@esammer
Copy link
Member

esammer commented Oct 14, 2016

@jendap: That's a fair point. Part of the reason we picked millis has to do with the granularity of most downstream systems processing this data and their implementation details as well as the cost of higher resolution timers. Many systems that act on this data don't understand micros or nanos, so we'd lose granularity anyway. The issue around "cost" has to do with the size and code complexity to handle timestamps at those granularities, especially in languages that don't support unsigned types (e.g. JVM languages). That means those languages need to represent time in complex types. I might also challenge the assertion that microservices mean finer grained timing is required. All of the normal latency mechanics (https://gist.github.com/jboner/2841832) still apply to those services just as any others and we're not really targeting profiler-level timing.

I'm open to discussion on this, but I wanted to capture why we choose millis initially. Thanks!

@jendap
Copy link
Author

jendap commented Oct 15, 2016

The timestamp is already a "long". Signed integer being a problem? In year 2262 for nanoseconds - 2^63 / 10^2 / 3600 / 24 /365 ~= 292 years. Later for microseconds.

In order for anybody care in 2262 it has to be successful today. Today people are doing microservices, servless and / or async multithreaded stuff (on multicore cpus). People will not be happy once they get reordered (like in partitioned kafka topic).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants