Evan Hillas <firstname.lastname@example.org
David Gibbs wrote:
Evan Hillas <email@example.com
Maybe a change to CLOCK_MONOTIC is in order where it will not perform
any accumulating compensation.
CLOCK_MONOTONIC doesn't do any accumulating compensation. The compensation
is done on the boot time.
That is an additional correction that doesn't affect CLOCK_MONOTIC,
it's not the one I'm interested in.
The app's request gets rounded to the
nearest integral interrupt period and stays that way until it's stopped
or the interrupt period is adjusted.
I don't think we can do that, round the applications request that way. If
the application wants rounding, it needs to do the rounding itself.
Let me reword that one. I meant have the OS choose the closest IRQ
period based on rounding, which it already does, then no subsequent
accumulation applied, which it currently does do to match the app's
real time request.
We don't accumulate on an application's behalf. We record the
applications request as exactly as possible. Then, we just move
current time forward by the clock period, and on each tick, ask,
"is current time > next expiry application asked for", and if yes,
notify the client. If it is a repeating timer, we then add
exactly what the client asked for to the client's next expiry.
You seem to be suggesting that we should modify the "amount to
add" to the app's expiry from what the application asked for to
some other value.
We shouldn't do that. It is up to the client application to choose
that value, not the OS, and if the client chooses a bad value -- one
that doesn't align well with the amount the OS adds as its clock
period -- the application will have bad behaviour.
Currently the Posix based timer mechanism tries to fit a request over
many events by accumulating the error for each event and at fairly
regular intervals one extra or one less IRQ interval is applied to
match the calculated real time of the app's request. This method
creates a "beat" as described in the tick-tock articles.
Hm... I guess it might look like that, though that isn't the implementation.
Of course the OS can round off the request. My concern has always been
that, left to the application, there is no guarantee for the applications
that their rounding will always match the OS's internal IRQ interval
The application can query the OS's internal IRQ interval by calling
ClockPeriod(), and make sure their request rounds cleanly to this.
So, the idea I had above, is add a mechanism that forces the request to
the nearest integral of the IRQ interval.
And, I repeat that this is up to the application to do, should the
application need this.
However, this idea is not ideal either. When it comes to interrupt
period adjustment such sampling systems are screwed unless the new period
is lucky enough to land on a multiple of the integral.
Systems should NOT be adjusting the interrupt period on the fly. It should
be set once, as a system design consideration, shortly after boot time -- and
before anything that will depend on it configures -- and never be changed.
Really? Any root access program can change it at will. I would think
that there is some sort of attempt by the OS to keep track of real
time during such changes.
And, any root process can disable interrupts for 15 minutes. Any root
process can send a SIGKILL signal to every other process in the system.
Any root process can map all of physical memory and start scribbling
Just because a root process CAN do something does not mean that it is
a good system design decision for a root process to do so.
Yes, if you modify the clock period, things will work fine from the
OS point of view. Our mechanism for handling time, and timers, really
doesn't care if you twitch it over and over again.
But, most systems that have any dependency on the system clock will
decide, as a design decision, what trade-off they want between overhead
and precision in the clock, and set that up as a system design decision,
implement the appropriate change (if any) shortly after boot, and leave
the system that way. Then, if someone does need to run without beat/
accumulated error problems, they can safely query the system value for
this and use that, confident that it won't change.
QNX Training Services