Re: [PATCH] dynamic tick patch
From: George Anzinger
Date: Wed Jan 19 2005 - 19:41:46 EST
Thomas Gleixner wrote:
On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
I don't think you will ever get good time if you EVER reprogramm the PIT.
Why not ? If you have a continous time source, which keeps track of
"ticks" regardless the CPU state, why should PIT reprogramming be evil ?
First it takes too long. Second, you are (usually) programming it to run at
1/HZ but you do this somewhere between the ticks (and, likely you don't really
know where between them you are). This last means, on the average, that you
lose 1/2 a tick time, i.e. the tick interrupt will happen 1/2 a tick late for
each reprogramm done.
If you say, well, lets just use the TSC (or some other timer) you have the
problem that in x86 boxes those don't rely on "rocks" selected for time keeping,
so you have an inaccurate clock to this degree. Also, in the case of the TSC,
at boot time we "try" to figure out how many cycles of TSC it takes to do a PIT
cycle by "looking" as the PIT in a loop while we catch the TSC. Problem is that
the I/O sync needed to look at the PIT is several TSC cycles long and we don't
really know how close we got. Even using the max PIT time of around 50 ms the
error on my 800 MHZ PII is 10 or more TSC cycles.
At one point I tried to get the PIT to sync back up by doing a short cycle
followed by the normal cycle. I.e. I loaded the counter for the time remaining
in the jiffie, started the PIT and then loaded the 1/HZ latch count on top of
it. The spec says the new count should be loaded by the chip when the current
one expires. This sort of worked, but I still got feedback on clock drift.
Also, there are some PITs out there that don't do this correctly. And in the
load part, you have to wait for the first program to start prior to loading the
second one. This is a busy loop waiting for an I/O event, i.e. much too long.
We should also keep in mind that we really want the timer tick to happen as
close as possible to the jiffies++ as possible. Especially if we are doing high
res timers, any delay here will show up as late timers.
--
George Anzinger george@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/