Hi,
On Tue, 18 Oct 2005, George Anzinger wrote:
Above says IOW if we have a clock with a frequency f and a resolution with
r=10^9/f, we have to round time t up so that it becomes a integer multiple i
of r, so that once the counter reaches the value i all timer with up to a
time value of i*r are expired.
You don't specifically disagree, so I can assume you agree that this a valid interpretation of the spec?
(I'm asking because it's important for the design of the timer system.)
If we now simply ignore the resolution fraction, we get a rounded value
which is quickly far away from the real value (with a worst case of r-1
nsec). This means an explicit rounding is likely only to make things worse
and any rounding is better done as part of the conversion from/to timespec
to/from the counter value according to the above rules and even this
conversion should be avoided as much as possible to minimize rounding
errors.
I think the rounding errors you are talking about would require us to define
the clock period in something finer than nanoseconds.
No, you don't have to, all you have to do is to make sure that "Quantization error shall not cause the timer to expire earlier than the rounded time value." IOW at the time the timer expires, the expiry time must not be greater than clock_gettime().
Rather I think you would like to turn the hardware resolution into the
resolution we use and send to the user. This, I think, is not quite the right
way to go. Suppose, for example, we have a timer that will do micro second
resolution. To provide this to the user implies that he is free to ask for
timers that expire every micro second. Today, this is not really a wise thing
to do as we would soon use all the cpu cycles doing interrupt overhead. So we
define a resolution, say 100 micro seconds, and set things up that way. This
means we, at most, need to handle timer interrupts once every 100 usecs (still
not really wise, put possible with some of todays hardware).
Now, if the timer we use actually has a resolution of 1.33333 usec, do we want
to use a multiple of this as our resolution? Not really, folks would just get
confused. We can just tell them it is 100usec and do the math. The errors
introduced by this are, at most, 1.3333 usec, and they are NOT cumulative, as
long as we do the math for each expiry. (If we try to compute a LATCH to use
to get 100 usec periods, we will accumulate errors, so why do that?) A jitter
of 1.3333 usec is well under the radar, being lost in the interrupt overhead.
No, the error is worse, although I specifically talk about the rounding done in Thomas' patch, I'm not sure we're really talking about the same thing. I didn't mean the error caused by jitter, in this case I'd actually agree with you.
He sets the resolution right now to (NSEC_PER_SEC/HZ) and uses this value to explicit round the time values. For example a timer is set to the value 1.1ms and is rounded to 2ms. The timer tick now actually expires at 1.2ms and could expire the timer, but it's instead expired at 2.2ms and user space sees an error of 1.1ms.
A similiar error even exists with interval timer, e.g. an interval timer is set to 0.9ms and rounded to 1ms. If the clock now expires a little too early the timer will expire repeatedly one tick too late.
In general due to this rounding and normal clock skew an extra error is added with an average value of half the timer resolution.
But, as I say above, we don't want to export the hardware detail, but an
abstraction we build on top of it. Suppose we don't want to provide 100 usec
timers except where really needed. We could provide a different abstraction
that has, say 10 ms resolution. We could then set things up so that the user
gets this all most all the time, say by define CLOCK_REALTIME with this
resolution. We then might define CLOCK_REALTIME_HR to have a resolution of
100 usec. The user who needs it will realize that it has higher overhead
(else why would we make it a bit harder to get to), and use it only when he
needs the resolution it provides.
There is no reason that both of these "clocks" can not use the same underlying
code and hardware. At the same time they do not have to.
I don't have a problem with this at all. I think it's fine to leave clock_getres(CLOCK_REALTIME) at a save value.
The spec allows both resolutions:
"an implementation (is required) to document the resolution supported for
timers and nanosleep() if they differ from the supported clock resolution"
What we want to do, and what is done by others, is to define different clocks
which carry their resolution to the timers used on them. This is a little
orthogonal to the standard, but seems to be a reasonable extension.
Could you please give me an example for "others"?
I don't think I have a problem with this. My point is to better define "reasonable extension" or to be more specific what user expectations are reasonable. What is needed by applications and where exactly do we draw the line, when it comes to extra complexity in the timer design.
I wouldn't a priori exclude the possibility to break some user applications, which have unreasonable expectations. We did this in the past (e.g. sched_yield()), we simply fixed the applications and moved on, but this requires more information about what applications expect about high resolution timer.
No problem. Do be advised I will be out most of next week through the end of Oct.
George, many thanks for trying to understand me and helping me to get a better understanding of the issues. I see more misunderstandings than disagreements, so I'd be really grateful, if you can help me later to translate this into something Thomas and Ingo can understand. :-)