TAP Precision Time APIs: Difference between revisions

From OpenCompute
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
[https://www.opencompute.org/wiki/Time_Appliance_Project Time Appliances Project]  
[https://www.opencompute.org/wiki/Time_Appliance_Project Time Appliances Project]  


Unix clock_gettime API was designed a couple of decades ago. The time is encoded as number of units between now and a date half a century ago. In theory this is sufficient in the field of physics, and it should be sufficient any use of time as a phenomenon. In practice, representing the time is an offset from the epoch worked well for most of us, and for half of a century, the only change was a few improvements related the size of the unit.
Unix clock_gettime API was designed a couple of decades ago. The time is encoded as number of units between now and a date half a century ago. In theory this is sufficient in the field of physics, and it should be sufficient any use of time as a phenomenon. For the majority of the systems, it was sufficient in practice as well. Representing the time is an offset from the epoch worked well for most of us, and for half of a century, the only change was a few improvements related the size of the unit.  
   
   
Representing the time as just a number works well for many software systems. However, in the last two decades, to increase the efficiency of the system, we started building system where we replace communication with simple local calculation. For such systems, we need more information about the clock synchronization process. It became important when was the clock synchronized, what type of physical local clock we have, what was the last measured offset between local clock and the referent clock.
Representing the time as just a number works well for many software systems. However, in the last two decades, to increase the efficiency of the system, we started building system where we replace communication with simple local calculation. For such systems, we need more information about the clock synchronization process. It became important when was the clock synchronized, what type of physical local clock we have, what was the last measured offset between local clock and the referent clock.

Revision as of 00:48, 8 December 2021

Screenshot 2020-07-01 16.35.12.png

Workstream #3

Time Appliances Project

Unix clock_gettime API was designed a couple of decades ago. The time is encoded as number of units between now and a date half a century ago. In theory this is sufficient in the field of physics, and it should be sufficient any use of time as a phenomenon. For the majority of the systems, it was sufficient in practice as well. Representing the time is an offset from the epoch worked well for most of us, and for half of a century, the only change was a few improvements related the size of the unit.

Representing the time as just a number works well for many software systems. However, in the last two decades, to increase the efficiency of the system, we started building system where we replace communication with simple local calculation. For such systems, we need more information about the clock synchronization process. It became important when was the clock synchronized, what type of physical local clock we have, what was the last measured offset between local clock and the referent clock.

In the Time API stream, we will start with discussing software system and services that would benefit from better clock and time API. Initially I would like to focus our discussions on defining the problem that we want to solve, any requirements and existing solutions. At some point, we could discuss building a reference implementation, but that is not the primary goal. The goal is to publish an official proposal for time and clock API that allow designing system where time is reliable fundamental building block.

Objective

Time and clock API that allow designing system where time is reliable fundamental building block

- APIs to bring accurate time to the user space
- APIs to disseminate the time error (error bound)
- APIs to provide viability over the time synchronization process


Project Team

- Lead: Georgi Chalakov (NVIDIA)
-
-