Obtaining the time in Java with nano-second precision


At TransFICC for MiFID compliance (as explained in my previous blog) we need to obtain the time of an event within 100 microsecond accuracy with respect to UTC. To achieve this in Java we first need to be able to obtain the time from the OS with better than millisecond precision. We can then make use of Precision Time Protocol (PTP) to ensure the system clock is synchronised to UTC with sufficient accuracy. Take a look at the excellent posts from Luke Bigum on how to achieve this. As of Java version 8 it is not possible to directly obtain the time with higher than millisecond precision. Java 8 System.currentTimeMillis() will return the time since the Unix epoch in milliseconds. Higher precision time is possible on some underlying systems such as Linux.

On Linux the code that the OpenJDK JVM executes is:
The full source can be found here. The code makes the function call gettimeofday(). This returns the time since the Linux epoch in micro seconds however it is rounded to the nearest millisecond. On newer Linux kernels this is an alias for clock_gettime(). The POSIX spec has deprecated gettimeofday() for clock_gettime() so this should be used instead. On modern Linux systems the function call is implemented as a Virtual Dynamic Shared Object or (VDSO) as opposed to a system call for improved performance.

The accuracy and of the underlying clock is dependent on the clock source being used by the kernel. To view all clock sources availble execute 
cat /sys/devices/system/clocksource/*/available_clocksource
To view the current clock source in use execute 
cat /sys/devices/system/clocksource/*/current_clocksource


Calling clock_gettime() to obtain a nanosecond precision time from the JVM can be achieved using Java using JNA or JNI.  We implement both clock_gettime() using JNA and JNI and performance compared with System.currentTimeMillis() as a baseline. The tests were conducted on a Intel Xeon CPU E5-1650 v3 @ 3.50GHz using the Java Benchmark Harness (JMH).

All the code and benchmarks are available here to be executed independently.



Source JMH output is here

For the most part this is a comparison between JNA and JNI performance. JNA has the advantage of not requiring the user to compile any native code but this comes at the cost of performance. For each call to obtain the time JNA constructs Structure objects that represent native structures. This results in a worse median latency as well as generating significant amounts of garbage degrading long tail latency. The JNA direct mapping showed improved performance past the 99.99 percentiles but was still significantly slower than JNI.

In the future there will be some support for higher precision time in Java 9.




Comments

Post a Comment

Popular posts from this blog

Persisting JMH Results for Regression Detection

JMH is a tool to measure Java code that is executed within  micro-second time scales. You may ask the question why do I care about the performance of code that by definition is executed in a very short period of time? It is important to only optimise code that will have a significant effect on the overall application. Sometimes a small portion of the your application's code is executed many times or your latency requirements of your application is in the micro-second time scale. Once your application is performing as required it can be difficult to maintain that performance whilst making code changes. An automated collection of micro-benchmarks running on key components of your application is an invaluable tool in maintaining the required performance. As a starting point a history of your JMH results needs to be stored in order to analyse trends in benchmark results. Influx JMH reporter is an open source tool we have written that parses the JMH JSON results file from a ben...
Read more

Cracking the Nut - Open Sourcing from a Single Source Tree

Why a single source tree ? At a previous employer the code started out with the main code base in a single checkout with only infrastructure components of the code in their own repositories. As the code base grew the build time gradually become painful. To resolve this developers began to pull out components into their own repositories. This initially solved the problem of slow build times and improved productivity for the developers working on a single component. However, it soon became apparent that making changes to components that had many internal dependencies was particularly cumbersome. It also made it difficult to make changes across multiple repositories. This was solved by moving everything back into a single source tree. What about the slow build times? The short answer is Buck - a build tool from Facebook which is inspired by Google's internal build tool called Blaze, now open sourced as Bazel . In summary these build tools allow you to easily modularize your rep...
Read more