September 13th, 2017

Through Address Space and Time with Kithara

"Time is what you measure with a clock."— Of course it is not always as easy as Einstein jokingly put it, especially when it comes to juggling with system times and time bases. One of our developers experienced this first-hand when he managed to travel through time.

During the development of our upcoming PTP stack (Precision Time Protocol), differing time bases caused our developer to travel to the year 1601— at least that is what the system time displayed. In order to escape the harsh world of the 17th century, the developer first had to set the flux capacitor to 1985 so that Windows would be able to contact the NTP (Network Time Protocol) server.

Back in the present, a few modifications to the development environment were made for further testing purposes. This new set-up allowed for the creation of a time loop, distributed among two computers and connected to an EtherCAT network. However, all of a sudden, the clock accelerated forward, this time unintentionally sending our developer far into the future. Sometime around the year 6000 we broke off contact, just to be on the safe side.

This little trip highlights just how complex the handling of the system time can be for system-dependent programming, especially when multiple time bases are involved. Just the different approaches to dealing with leap seconds alone has often been a pain for IT professionals since their introduction.

What are leap seconds? After atomic clocks took global control of the exact time in 1958, it was required to also factor in the gradually decreasing earth rotation by occasionally (about every 18 months either on January 1st or July 1st) adding an additional second. The coordinated universal time (UTC) includes these leap seconds, which have since accumulated to 37 seconds. What may seem to have barely an impact on regular day to day life, can cause significant complications for certain computer processes, as shown by the numerous server and GPS issues that occured in 2012 and 2015. Strictly speaking, the moment a leap second is added, UTC would have to differentiate between an A-second and a B-second. Instead, time-critical and continuously running systems should rather utilize a free-running clock, independent from UTC, to avoid deadlocks. For this purpose, the Kithara PTP stack will provide the exact machine time at a 100 nanosecond resolution.

Despite the time travels of our programmers during its development, the use of the new PTP Module itself will prove to be rather user-friendly as we have minimized the risks of causing a time paradox.