Quality of Time

file

Visible to the public The Impact of QoT on Estimation and Control

Inexpensive computation and ubiquitous embedded sensing, actuation, and communication provide tremendous opportunities for societal impact, but also great challenges in the design of networked control systems, because the traditional unity feedback loop that operates in continuous time or at a fixed sampling rate is not adequate when sensor data arrives from multiple sources, asynchronously, delayed, possibly corrupted, and -- especially important for this project -- the different entities that participate in the control system do not share a common clock.

file

Visible to the public Quality of Time Architecture & APIs

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.

file

Visible to the public Go-RealTime: Knowledge and Control of Time in High Level Programming Language

Abstract:

General purpose operating systems (OS) are concurrent and multithread, and the primary goal of thread scheduler is to enforce fairness among all threads. This design is unsuitable for Real-Time (RT) systems, because tasks have soft or hard deadline of finishing time. Concurrency breaks timing of RT applications because users never know when their program is actually running. Explicitly allocation of processor resource to programs (threads) is thus necessary for timing-aware applications.