> CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
> At the same time we will NOT support the following clocks:
>
> CLOCK_VIRTUAL a clock measuring the elapsed execution time (real or
> wall) of a given task.
...
> For tick less systems we will need to provide code to collect execution
> times. For the ticked system the current method of collection these
> times will be used. This project will NOT attempt to improve the
> resolution of these timers, however, the high speed, high resolution
> access to the current time will allow others to augment the system in
> this area.
...
> This project will NOT provide higher resolution accounting (i.e. user
> and system execution times).
It is nice to have accurate per-process user/system accounting.
Since you'd be touching the code anyway...
> The POSIX interface provides for "absolute" timers relative to a given
> clock. When these timers are related to a "wall" clock they will need
> adjusting when the wall clock time is adjusted. These adjustments are
> done for "leap seconds" and the date command.
This is a BIG can of worms. You have UTC, TAI, GMT, and a loosely
defined POSIX time that is none of the above. This is a horrid mess,
even ignoring gravity and speed. :-)
Can a second be 2 billion nanoseconds?
Can a nanosecond be twice as long as normal?
Can a second appear twice, with the nanoseconds getting reset?
Can a second never appear at all?
Can you compute times more than 6 months into the future?
How far does time deviate from solar time? Is this constrained?
If you deal with leap seconds, you have to have a table of them.
This table grows with time, with adjustments being made with only
about 6 months notice. So the user upgrades after a year or two,
and the installer discovers that the user has been running a
system that is unaware of the most recent leap second. Arrrgh.
Sure you want to touch this? The Austin group argued over it for
a very long time and never did find a really good solution.
Maybe you should just keep the code simple and fast, without any
concern for clock adjustments.
> In either a ticked or tick less system, it is expected that resolutions
> higher than 1/HZ will come with some additional overhead. For this
> reason, the CLOCK resolution will be used to round up times for each
> timer. When the CLOCK provides 1/HZ (or coarser) resolution, the
> project will attempt to meet or exceed the current systems timer
> performance.
Within the kernel at least, it would be good to let drivers specify
desired resolution. Then a near-by value could be selected, perhaps
with some consideration for event type. (for cache reasons)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:20 EST