Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!tuvie!vmars!alex
From: alex@vmars.tuwien.ac.at (Alexander Vrchoticky)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <1783@tuvie>
Date: 30 Aug 90 14:11:16 GMT
References: <11187@alice.UUCP> <3300165@m.cs.uiuc.edu> <2470@crdos1.crd.ge.COM>
Sender: news@tuvie
Lines: 53

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:

[about synchronizing clocks to nanosecond accuracy]
>  I guess the first question is when will there be a benefit from doing
>so? And how long will it stay in sync?

A global sense of time is a powerful concept in distributed real-time systems. 
The synchronization accuracy achievable depends on a lot of factors,
most notably the variability of the communication delay and the 
drift rates of the local clocks. On local area networks a synchronization
accuracy in the order of a few microseconds can be achieved with just a little 
hardware support and with very reasonable overhead. 
Given the advances of computer architecture in the past I don't 
dare say that synchronization accuracy in the order of nanoseconds will
not be achieved. 

>  The timer should not be more accurate than the accuracy of the
>setting. Unless there's a good way to set such a timer within a ms
>*repeatably* then why worry about how accurately you can measure it? The
>relative timer is important, the absolute timer leads people to believe
>they have accuracy they don't.

System calls to set timers and clocks to absolute values 
are of course nonsensical when the variability of the 
execution time of the system call itself is in the order of the 
granularity of the clock or timer or greater. 

For clocks there is a solution to the problem:
Adjust the *rate* of the clock until the correct value is reached
and maintain the correct value by corrections of the rate. 
Unfortunately 1003.4 does not specify an interface for this 
(ok, this does not really belong in comp.arch ...). 

Given such a clock the variability of the system call does *not* matter
for absolute timers (Putting aside pathological cases). 
I don't see a satisfactory solution for relative timers.
The variability of the notification is of course a problem for both types
of timers.

Note that the accuracy of *any* timer used for interval measurements
also depends on the fact that all corrections of the clock setting are 
gradual: Otherwise short durations might be measured
as if they had taken a negative amount of time.

I agree that for networks of workstations and other non-real-time 
applications a few milliseconds of accuracy are probably plenty. 
But other systems are more demanding: Real real-time systems need Real Time :-)
And they need software mechanisms to access it. 

--
Alexander Vrchoticky  Technical University Vienna, Dept. for Real-Time Systems
Voice:  +43/222/58801-8168   Fax: +43/222/569149
e-mail: alex@vmars.tuwien.ac.at or vmars!alex@relay.eu.net  (Don't use 'r'!)