Messages in this thread | | | Date | Thu, 25 Dec 1997 19:33:54 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: [PATCH] Intel clock speed detection |
| |
On Tue, 23 Dec 1997, Phil Brutsche wrote:
> On Tue, 23 Dec 1997, Nicholas J. Leon wrote: > > > Fellow kernel enthusiasts - > > > [stuff snipped] > > > > Here are the problems I know I haven't addressed: > > > > . does my mhz detection routine work reliably (ie, at all) > > with all non-intel cpu's? > Yes, it'll work, to a point. I haven't any experience with this on AMD > chips, but on Cyrix chips these routines tend to measure the clock speed, > not what is performs like. ie a cyrix PR166+ will return 133MHz because > it runs at 133MHz.
The clock speed is IMO the only relevant information that may have any interest for the kernel. Use your preferred benchmark to know how your processor performs against other ones. BTW, people who are using Cyrix PR200+ at 166MHz clock and so at 83 MHz external clock and 41.5 MHz PCI clock are using a processor that performs as a chip breaker. A processor that requires the user to overclock PCI controllers and most of the time motherboard components is not serious IMO.
> They are close to 100% correct on intel chips. > > . what about SMP machines? > There shouldn't be a problem; a SMP guru will end up proving me wrong > though :-). > > . slight variation of reported mhz (132 vs 133) > Try allowing for some difference; some routines allow the following for > their chips: > A tolerance of 2MHz for '386's > A tolerance of 4MHz for '486's > A tolerance of 5MHz for Pentiums, PPros, and PIIs.
For now, the kernel only needs micro-second timer scaling (BogoMips). I suggest to try measuring the PCI clock speed and to warn about possible boards destruction when it does not conforms to the allowed range.
(For example, this is possible by using the general timer feature of any NCR53C8XX chip and selecting the PCI clock as SCSI clock, but obviously this will not work for standard systems).
Gerard.
| |