lkml.org 
[lkml]   [2005]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] i386: Selectable Frequency of the Timer Interrupt
Vojtech Pavlik wrote:
> 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.
>
But if you are going to an "odd" value, would 1381 would be a better
choice, given the interest in minimizing latency currently evident? The
overhead would be a little higher, of course, but the people who want to
drop to 250 for battery life would probably want 216 anyway.

How serious is the 1/HZ = sane problem, and more to the point how many
programs get the HZ value with a system call as opposed to including a
header or building it in? I know some of my older programs use header
files, that was part of the planning for the future even before 2.5
started. At the time I didn't expect to have to use the system call.

--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
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/

\
 
 \ /
  Last update: 2005-07-13 18:27    [from the cache]
©2003-2011 Jasper Spaans