lkml.org 
[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] i386: Selectable Frequency of the Timer Interrupt
    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
    -
    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 00:36    [W:2.970 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site