Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

Nishanth Aravamudan
2005-07-12T22:31:54Z

On 12.07.2005 [10:50:23 -0700], john stultz wrote:
> On Tue, 2005-07-12 at 08:26 -0700, Martin J. Bligh 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
> > >> >
> > >> > The reality is that the crystal is usually off by 50-100 ppm from the
> > >> > standard value, depending on temperature.
> > >> >
> > >> > 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
> > >> >
> > >> > Some HZ values indeed fit the tick frequency better than others, up to
> > >> > 333 the error is lost in the physical error of the crystal, for 500 and
> > >> > 1000, it definitely is larger, and thus noticeable.
> > >> >
> > >> > Some (less round and nice) values of HZ would fit even better:
> > >> >
> > >> > HZ ticks/jiffie 1 second error (ppm)
> > >> > ---------------------------------------------------
> > >> > 82 14551 1.000000152 0.2
> > >>
> > >>
> > >> Most interesting... Would 838 Hz be a much better choice than 1000 then?
> > >> (apart from the ugliness).
> > >
> > > No, 838 isn't significantly better. 864 and 627 would be better
> > > candidates:
> > >
> > > HZ ticks/jiffie 1 second error (ppm)
> > > ---------------------------------------------------
> > > 627 1903 0.999999314 -0.7
> > > 838 1424 1.000109105 109.1
> > > 864 1381 1.000001829 1.8
> > >
> > > A good HZ value would make ntpd significantly happier, if the crystal is
> > > of reasonable quality.
> > >
> > > 152ppm (1000Hz) is 13 seconds a day,
> > > 0.7 ppm (627Hz) is 22 seconds a year.
> >
> > Does positive vs negative error make a difference to the timer subsystem?
> > Nish was telling me they had to add 1 extra tick to timer inaccuracies
> > because of the errors ... does changing the polarity of the error
> > affect that (seems like it would ... but I got lost by now ;-))?
>
> It doesn't affect the soft-timer subsystem very much due to the
> additional rounding described above, but it does affect anywhere jiffies
> is used directly via HZ for time. Awhile back there were some issues we
> had with proc output being confused in the transition via HZ, ACTHZ and
> USER_HZ that were related.
>
> This would probably be a good plug for Nish's time based (as opposed to
> tick based) soft-timer work. By utilizing the timekeeping subsystem,
> using absolute nanoseconds since boot instead of jiffies to expire soft-
> timers we can avoid worrying about HZ/ACTHZ error in that subsystem.
> Additionally it avoids any sort of accumulating error which could be
> caused by lost ticks and allows for lower best-case latencies and
> improved average latencies.

FWIW, I will be trying to get a new version of my patch which is
independent of John's timeofday rework (will use xtime &
wall_to_monotonic as a nanosecond "time" value) out before the end of
the week.

I think these arguments are still valid for the worst-case scenario with
my patch, as the hardware interrupt rate is still tied to HZ. But, at
least, we can discuss it in clearer terms and disjoin the soft-timer
issues from the hardware ones (I hope).

Thanks,
Nish