Time, Where does it come from?

This is part of a two part series on time measurement. Part 2 will explain how to obtain accurate time measurement in Java. This first part explains the general concept of time measurement.

How do we measure time?


With a clock of course. So how do we build a clock? The first thing we need is to observe something that occurs at a constant rate. Humans have built clocks based on observations of changes in their environment that appeared to occur at a constant rate.

Sundial
Sundial

Some of these earliest clocks were Sundials. The shadow cast by the Sundial moves based on the rate of rotation of the earth on its axis. This observation of the Earth's rotation is what Greenwich Mean Time was based on. At the Royal Observatory in Greenwich astronomers would observe the sun and other stars in order to calibrate their clocks. In principal on average the sun would appear directly above in the sky at 12h00.00. This is why its called Mean time. The current term for this mean solar time is called UT1. This method of time measurement has the fundamental problem that the earth does not rotate on its axis at a constant rate, it fluctuates and on average is slowing down. At this rate eventually the earth will stop rotating on its axis, fortunately this will only happen in 1.9 trillion years.

The definition of the second


The second unit has historically been derived from the length of the day divided by 86400. (24 hour x 60 min x 60 sec). Since the invention of Atomic Clocks measurements of time with much greater accuracy is possible. The Nist-F1 Atomic Clock is expected to not vary more than a second in 100 million years. With this level of accuracy, it was insufficient to define the second with respect to the length of a day and it was therefore redefined in 1967 as "9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom." That's a mouth full, put a little more simply its an electron moving back and forth between two sub-energy levels of a caesium atom.

Why is time measurement useful?


Sometimes we want to determine the order of events, their spread or agree on having an event at a time in the future. Unfortunately there is no easily derived absolute time, i.e. time has to be measured relative to some particular point in the past. We therefore make up some point, usually a significant event in history where we measure time from. Some examples of these are the Year 1 in the Gregorian calendar (they started counting from 1) and Unix time. Unix time is defined as the number of seconds since 00:00:00 UTC on the 1st of January 1970.

With these relative starting points we can state that the Boston Tea Party occurred on the 16th of December 1773 on the Gregorian Calendar or that there will be a total solar eclipse at 1607962479 Unix time. Depending on the event we require varying levels of granularity in our time measurement. Events like the Boston Tea Party do not require second level granularity to be useful, however a solar eclipse can last a few seconds and therefore in order to avoid missing the event second level granularity is required.


Time in a computing world

Computers make millions of decisions per second. In Financial Markets computers are used to automatically make decisions on whether to buy or sell assets. In order to determine the order of events we need clocks with micro and sometimes nano second granularity. A microsecond is one millionth of a second and a nanosecond is one billionth of a second. To put that in perspective, one nanosecond is to one second as one second is to 31.71 years.

Markets in Financial Instruments Directive (MiFID)


MiFID is a large set of European Union laws which impose a broad range of regulations on investment services. A review of MiFID known as MiFID II requires details of trades to be published including the time at which they occurred. For traders using "high frequency algorithmic trading" it requires the clocks used have at least one microsecond granularity. See: Regulatory technical and implementing standards - Annex I , pg 507.

Granularity of a time measurement is not very useful if your measurement is not accurate. The only way to determine the accuracy of a clock is to use another clock that you trust more. In order to check the accuracy of your wrist watch you glance at another clock and compare. You may be able to ensure that your clocks are accurately synchronised by a couple of seconds. This process is much more challenging when you are attempting to sync clocks with microsecond accuracy. 

Part 2 How to efficiently obtain nanosecond clock precision from Java.

Comments

Post a Comment

Popular posts from this blog

Obtaining the time in Java with nano-second precision

Image
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 t...
Read more

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