Quality of Time Architecture & APIs
pdf
Abstract:
Time is not necessarily what a clock reports. There is an uncertainty in time which is often not reported. Quantifying this timing uncertainty with clock parameters such as accuracy, precision, jitter or wander, is what introduces quality in time. Modern operating systems such as Linux lacks this perception of Quality of Time (QoT). It exposes some default clocks which are time synchronized / syntonized on best-effort basis through NTP or PTP, irrespective of the applications demand and the resources at hand. Instead, applications with varying demands should be able to declare their own clocks, bound to certain time bases with the desired quality. Therefore, there is a need for a QoT stack which adapts a global sense of time with some known error tolerance, while balancing resources. In our implementation, the QoT stack is comprised of three major blocks. The first block provides an interface through a set of APIs to an application developer. Using these APIs, the applications can bind to a shared sense of time, called a timeline. They can also unbind from a timeline or even update it’s binding quality. They can query time with a known error estimate or schedule events globally. The second block, Scheduler, expose virtual clocks to user-space for each of these timelines. This block maintains all the timelines as red black trees and all the application defined bindings to the timelines, in terms of accuracy and resolution, in a linked list. The Scheduler is also responsible for timely and correct scheduling of tasks. It implements a distributed ‘wait_until’ function and keeps track of time-sensitive tasks in a waiting queue with an independent hardware timer. This queue also keeps track of changes in the notion of time. The Scheduler implementation is done on the Resource Kernel (RK) framework. Finally the third block, a System Service, adaptively synchronize these virtual clocks in a resource aware fashion and satisfy the application requirements of accuracy and resolution.
Submitted by Fatima Anwar
on
Abstract:
Time is not necessarily what a clock reports. There is an uncertainty in time which is often not reported. Quantifying this timing uncertainty with clock parameters such as accuracy, precision, jitter or wander, is what introduces quality in time. Modern operating systems such as Linux lacks this perception of Quality of Time (QoT). It exposes some default clocks which are time synchronized / syntonized on best-effort basis through NTP or PTP, irrespective of the applications demand and the resources at hand. Instead, applications with varying demands should be able to declare their own clocks, bound to certain time bases with the desired quality. Therefore, there is a need for a QoT stack which adapts a global sense of time with some known error tolerance, while balancing resources. In our implementation, the QoT stack is comprised of three major blocks. The first block provides an interface through a set of APIs to an application developer. Using these APIs, the applications can bind to a shared sense of time, called a timeline. They can also unbind from a timeline or even update it’s binding quality. They can query time with a known error estimate or schedule events globally. The second block, Scheduler, expose virtual clocks to user-space for each of these timelines. This block maintains all the timelines as red black trees and all the application defined bindings to the timelines, in terms of accuracy and resolution, in a linked list. The Scheduler is also responsible for timely and correct scheduling of tasks. It implements a distributed ‘wait_until’ function and keeps track of time-sensitive tasks in a waiting queue with an independent hardware timer. This queue also keeps track of changes in the notion of time. The Scheduler implementation is done on the Resource Kernel (RK) framework. Finally the third block, a System Service, adaptively synchronize these virtual clocks in a resource aware fashion and satisfy the application requirements of accuracy and resolution.