Time Resolution

[Ashley Yakeley]

In article <41FE23F1.6080908 at cql.com>, Seth Kurtzberg <seth at cql.com> 
wrote:

> Doesn't automatically forcing a system clock tick screw up the time?  

Well, one nanosecond is three cycles of a 3GHz processor. For the time 
being it seems unlikely to be a problem.

> Also, what happens when you are using NTP?  NTP might just correct it, 
> but it would screw up the calculations NTP uses and it could start 
> oscillating.

NTP knows all about this, and it's only an issue with leap seconds. See
<http://www.eecis.udel.edu/~mills/leap.html>

> I don't think we disagree, in general, it's more a question of whether 
> or not system clock related computations should match the precision of 
> the system clock.  123.45000 implies that the value is known to be 
> accurate to five decimal points (just picking an arbitrary number of 
> digits beyond the decimal point, because I don't recall the actual 
> precision of the high resolution library).  Truncating at the end is 
> also not "correct," because the final result in general might be 
> different if you compute with five digits and truncate, rather than 
> computing with two digits throughout.  (Again, whatever the number is; I 
> pulled 2 digit out of the air, just to use a number.)
> 
> To me all this shows that the system clock needs to be handled as a 
> special case, not just converted into the high resolution representation

The system clock gives measurements with a particular accuracy attached. 
This isn't a particularly special case, other time applications may 
involve measurements or calculations to some particular accuracy.

-- 
Ashley Yakeley, Seattle WA