attoseconds

D. J. Bernstein djb at cr.yp.to
Sun Oct 4 18:40:45 UTC 1998


Markus Kuhn writes:
> we are just trying to
> define a robust interface to the clock information available to a good
> operating system

Most modern processors provide exact cycle counts. A good clock routine
can combine cycle-count information with occasional TAI/UTC inputs to
provide reasonably accurate local-time displays with extremely accurate
time differences. The available resolution is going to drop below 1ns in
a few years, so limiting yourself to 1ns seems rather shortsighted.

(Yes, Virginia, you really can tell the difference on a Pentium 233
between something that takes 130ns and something that takes 135ns.)

> external picosecond hardware phase
> comparators clocked by caesium time normals, which send you the data as
> ASCII floating point numbers

Why not settle on a 16-byte format that works for everything? If you're
desperate to save space, you can truncate TAI64NA at the precision you
need---8 bytes for TAI64 or 12 bytes for TAI64N.

---Dan
1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html



More information about the tz mailing list