[Haskell-cafe] Re: System.CPUTime and picoseconds

[ChrisK]

Neil Davies wrote:
> I've found the pico second accuracy useful in working with 'rate 
> equivalent' real time systems. Systems where the individual timings 
> (their jitter) is not critical but the long term rate should be accurate 
> - the extra precision helps with keeping the error accumulation under 
> control.
> 
> When you are selling something (like data bandwidth) and you are pacing 
> the data stream on a per packet basis you definitely want any error to 
> accumulate slowly - you are in the 10^10 events per day range here.
> 
> Neil
> 

Now I am posting just because I like to look at the time scales.

A rate of 10^10 per Day is a period of 8.64 microseconds.

If you want to slip only 1 period per year then you need a fractional accuracy 
of 2.74 * 10^-13.  In one day this is a slip of 23.7 nanoseconds.

So atomic time radio synchronization is too inaccurate. I have seen GPS 
receivers that claim to keep the absolute time to within 100 nanoseconds.

Lennart is right that 1 picosecond accuracy is absurd compared to all the 
jitters and drifts in anything but an actual atomic clock in your room.  But 
since CPUs tick faster than nanosecond the CPUTime needs better than 1 
nanosecond granularity.  I agree with Lennart — I also want an Integral type; it 
keeps the granularity constant and avoids all the pitfalls of doing math with a 
Double.  Out of simplicity I can see why the granularity was set to 1 picosecond 
as it is slightly easier to specify than 100 picosecond or 10 picosecond or 1/60 
nanosecond (hmmm... arcnanosecond?).

Maybe Haskell should name the "1/60 nanosecond" unit something clever and create 
a new Time submodule using it for April 1st.  [ Base 60 is the real standard: 
http://en.wikipedia.org/wiki/Babylonian_mathematics has an 1800 B.C. tablet with 
the (sqrt 2) in base 60 as (1).(24)(51)(10) ]

-- 
Chris