Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 : TimeBase

[Tero Kivinen <[e-mail]>]

[e-mail] writes:
> >The time base is so that one does not have to be committed to picoseconds / 
> >milliseconds, etc.    Even in your example, I believe you used "unit" or time 
> >base.  Our thinking was that we wanted future proof so as to be able to 
> >handle very small values and very large (as may be needed for DTN, for 
> >example).   We can see if we can express years in picoseconds and see 
> >what happens.   Then, the unit would always be picoseconds 
> 
> The issue is with the hardware. When we were first researching the
> "proper" or "best" time unit in which the PDM time differentials
> should be measured, we found that different CPU hardware measure
> time very differently. Some CPUs are still measuring time in
> milliseconds and using multiple clocks to do it.

Yep, but the problem is that if the implementation still need to be
able to cope with other devices using different time bases, this does
not help. 

> Our plan was to have a CPU specify the time differential in its
> native time units, to reduce its processing time when communicating
> with another device that is at the same level. One could say that
> the most logical solution is to use the time signature of the
> slowest device, so that all the time-adjustment calculations are
> performed on the device most capable of handling them quickly, and
> similarly, requiring the slowest device to adjust to the timing used
> by the fastest device would be forcing those calculations onto the
> device least capable of handling them quickly. Further, why make two
> devices that use the same clock unit to change to a different time
> scale on both ends of the conversation? If both use microseconds,
> why not let them specify their time differential in microseconds?

The problem is that some implementations measure time in 0.01 seconds
(10 ms), some implementations have timers which go up 60 times per
second, then there are implementations which have free running counter
running that full clock speed (or some fraction of clock speed or some
other very fast value, but not necessarely ms, µs, ns or ps).

So even if you have 4 time bases, there are lots of implementations
which need to convert their clock to something that is suitable for
the wireformat.

If we do not have time base, i.e. everything uses some common timebase
then you always need to do it, but on the other hand it is simple, as
there is no selection whether you should be using ms, µs, ns or ps are
your time base.

Having the 2^scale factor to the numbers will take care of being able
to represent any time value there, having two different ways of doing
scaling (both 2^scale factor and the time base) will just complicate
things. 

> That's the reasoning that we had about the timebase.
> 
> Of course, we are open to discussion. 

I think it would be simplier to just have one fixed timebase, and it
might even be better to take the timebase so it is so small, that we
do not need negative exponents for scale, like attoseconds.

Attoseconds (10^-18) is so short that light can travel only 0.3 nm in
one attosecond, so that should be enough for PDM (until we get new way
of making transistors, and start measure latencies between
transistors).

If your clock is running milliseconds, you need to multiply the time
in ms with 0.88818 ((1000/1024)^5) to get time in attoseconds with
scale of 50. For microseconds the multiplier is 0.90949 with scale of
40, nanoseconds 0.93132 with scale of 30, picoseconds 0.95367 with
scale of 20, and femtoseconds 0.97656 with scale of 10.
-- 
[e-mail]