On Tue, Jul 12, 2005 at 08:57:06AM -0700, George Anzinger wrote:
> >>>The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
> >>>and is divided by 12 to get PIT tick rate
> >>>
> >>> 14.3181818 MHz / 12 = 1193182 Hz
>
> Yes, but the current code uses 1193180. Wonder why that is...
Because it was stated so in some ancient DOS docs? I really don't know.
x86-64 uses 1193182. This is because when I was doing x86-64 timing
code, I had observably better results with this number.
> >>> HZ ticks/jiffie 1 second error (ppm)
> >>>---------------------------------------------------
> >>> 100 11932 1.000015238 15.2
> >>> 200 5966 1.000015238 15.2
> >>> 250 4773 1.000057143 57.1
> >>> 300 3977 0.999931429 -68.6
> >>> 333 3583 0.999964114 -35.9
> >>> 500 2386 0.999847619 -152.4
> >>> 1000 1193 0.999847619 -152.4
>
> If we are following the standard and trying to set up a timer, the 1
> second time MUST be >= 1 second. Thus the values for 300 and above in
> this table don't fly.
In that case, the table will look like this (with the CGA clock fixed to
14.31818000 MHz):
HZ ticks/jiffie 1 second error (ppm)
---------------------------------------------------
100 11932 1.000015365 15.4
200 5966 1.000015365 15.4
250 4773 1.000057270 57.3
300 3978 1.000182984 183.0
500 2387 1.000266794 266.8
1000 1194 1.000685841 685.8
---------------------------------------------------
82 14551 1.000000279 0.3
216 5524 1.000001956 2.0
432 2762 1.000001956 2.0
864 1381 1.000001956 2.0
1381 864 1.000001956 2.0
> If we are trying to keep system time, we'll we do just fine at
> that by using the actual value of the jiffie (NOT 1/HZ) when we update time
> (one of the reasons for going to nanoseconds in xtime).
Yes, adding (12.0/14318180)*LATCH to xtime in each timer interrupt,
instead of (1.0/HZ) indeed eliminates the error entirely.
> The observable thing the user sees is best seen by setting up an
> itimer to repeat every second. Then you will see the drift AND it
> will be against the system clock which itself is quite accurate (the
> 50-100ppm you mention), even without ntp. And the error really is in
> the range of 848ppm for HZ=1000 BECAUSE we need to follow the
> standard. You can easily see this with the current 2.6 kernel. We
> even have a bug report on it:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=3289
Going to HZ=864 would fix this problem. It would likely cause other
problems in places that expect 1/HZ to be a sane number, though.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |