New Timestamp and Library API

• Student: ChenLi
• Mentors: HarlanStenn, TerjeMathisen, MartinBurnicki
• GSoC: GSoC Project Page
• Google's interview of Harlan about this process: https://www.youtube.com/watch?v=T2Yww1Tt2iU

Summary

Related Items: GSoC2013NewTimestampAndAPIKeyParts, GSoC2013NewTimestampAndAPIDesignOfProject, GSoC2013NewTimestampAndAPIWeeklyUpdates, GSoC2013NewTimestampAndAPIDocuments, GSoC2013NewTimestampAndAPITestCases

There are different timescales being used everywhere, like UTC and GPS. When user application gets timestamp from system, it can’t tell which timescale the system is using. What’s more, the timestamp being used may step backward in cases such as system time is set manually, which could be disaster to time-sensitive applications. So this idea aim to design and implement a new timestamp format and API that will never step backward and provide an easy-to-use interface for programs to fetch timestamp and process with it.

Motivation

As there are many different and widely-used timescales, functions like ‘gettimeofday()’ can no longer satisfy our requirement. It can only tell us the current system time, but can’t tell us what timescale is being used now, and how accurate it is, which is practical for use case e.g. synchronization.

If we can develop a new timestamp system that provides more information about system time, it will bring great convenience.

What’s more, the timestamp system we are using now may step backward, which is a disaster for some time-sensitive applications like database.

Therefore, we aim to implement a new timestamp API which never steps backward. When negative offset is to be applied, our new timestamp API will just write offset to system variable and system kernel will gradually adjust time to the right value in a long period.

Tasks

• Design a new timestamp API that support conversion from system timestamp, and fundamental operations include add/subtract/comparison.
• Implement this new timestamp API in Linux kernel (If time permitted, BSD kernel will be included). Which will provide similar usage like gettimeofday().
• Fully test the implementation. Write detailed wiki pages and documentations.

Timeline

Discussion and Comments

• Instead of a "boot counter" we may want a "clock discontinuty counter", as that's the real purpose behind the "boot counter" idea. Zefram suggested some other ideas too, and we should decide if they should be incorporated now or later. Specifically, he thinks we might want some of the error/uncertainty values to be a custom floating-point value, using 8 bits of exponent and 8 bits of significand. At least the significand can be unsigned. These values can be easily converted to a float. He also points out that some clock sources will not need an "expected offset to correct time". -- HarlanStenn - 20 Jun 2013