OSDev.org

i also wonder why you have "shl eax,7" .. shouldn't that be "shl eax,8" instead ? or am i missing something ? ...

I will test it with higher values for ecx. I also tested it on my XP1900+. Now I have 11646182Hz for my XP1900+ and 1646154Hz for my XP1800+. The difference is 28, but this are only 28 Hz and it should be 28MHz.

Edit::

You are right it should be shl eax,8. What a stupid mistake!

I added info about SMBIOS to the OSFAQ, but nobody noticed. It contains a field in its structures that simply states the cpu speed.

i did notice and i'm currently checking how it could actually be used.

Pype.Clicker wrote: i did notice and i'm currently checking how it could actually be used.

sorry bout the version mess, was trying to get the _SM_ to display correctly... didn't know doing underscores in wiki table is SUCH a *****.

and YES, I did try &#5f; and <pre>, all displayed as exactly what I typed in. =_something_= and _=something=_ italicize.

<pre> does not prevent wiki parser to get in. <verbatim> does

Pype.Clicker wrote: <pre> does not prevent wiki parser to get in. <verbatim> does

but with <verbatim> wiki still output the <verbatim> tag eh... verbatim .

So that looked kinda silly.

@flashburn :
got any better results with higher ecx / patched shl ? I'm a bit ahsamed i hadn't time to test my own proposition ...

I tested it with 0x4000 in ecx and I optimized the loop a little bit, so that I only exec the "rdtsc" instruction in the loop. Now it seems to give a accurate value. But I try to test it also on a 800 Athlon.

thanks alot ;D "flashburn reports 1800MHz" will certainly look cool in Clicker's bootlog

BTW:

GCC knows 64bit in extended ASM:

int main()
{
unsigned long long start=0, end=0, result;
asm(
"rdtsc\t\n"
:"=A"(start) :
);

sleep(1);

asm(
"rdtsc\t\n"
:"=A"(end) :
);

result = ((end - start)/1)/1000000;
printf("%ld MHZ\n",result);

}

...so you don't have to do the shifting stuff

Dug up an old thread of interest, found this:

Pype.Clicker wrote: The most 'precise' PIT dividers and clock speed i can find:

200 5965.9 Hz
5966 5.00008ms 199.996647670131 Hz
11932 10000.16... us (99,998 Hz)
13125 11.000016 ms
26250 22.000033 ms
59659 50 ms 50000 us 20 Hz

So indeed, using '20Hz' PIT could be the best if one can perform exact CPU speed detection *before* task switching is in place (imho, it wouldn't be nice to have a system which can only schedule 20 tasks a second as our screens goes up to 60 frames a second :-/)

Running the timer at 5965.9 Hz would mean that after 59659 ticks occured, you know 10 seconds have exactly elapsed ... though it might be too long for a calibration.

What value are you assuming for the frequency of the PIT counter? The reason I ask is because I often see the rate quoted as 1.19318 MHz, and then people say it ticks 1193180 times per second, which is nearly two ticks short. See, that first number is actually rounded off and the actual rate is 1.1931818181818... since it continues forever, it's not surprising people just round it off, but you don't get 1193180 ticks per second, you get closer to (but a bit short of) 1193182.

OTOH, if you're looking for an exact number of interrupts per second, the RTC gives you that -- exactly 1024 by default on its periodic interrupts, or you can just get interrupts exactly one second apart by enabling its update interrupts. Trying to use the PIT to simulate what the RTC does with exactness seems kind of odd...

Hmm, just had a thought reading this.

Is it really worthwhile doing frequency detection at run-time?

Wouldn't this be far, far easier to do at install-time.

e.g. If I take an rdtsc/RTC reading at the start of installation and another at the end of installation, then if installation lasts 5 minutes (Which it might after asking appropriate questions/writing files) then I'll have a pretty accurate reading of frequency to store/use when the OS is actually running, even though RTC is only has granularity of one second. The longer the installation takes the more accurate my reading gets.

Guessing low for the frequency when the installer is running shouldn't be a real problem (Guessing high might be).

This is part of a larger idea to just remove some of the crud from the booting process. Namely that detection happens once (At installation time) with a boot option to redetect (For large configuration changes, eg dumping the hardrive in a different computer) and an "Install hardware" inside the OS (For minor changes, eg Installing a new soundcard).

It just seems extremely wasteful to detect everything every boot, when system configurations change so rarely.

Then again, if you were going to go through the process of adding cpu detection to your operating system, would you really want it to keep telling you that you had a 2GHz if you upgraded to at 3GHz unless/until you do a reinstall?

Why not have the user instruct the os to perform a hardware recheck?

Kinda button or command: update_hardware_stat()

polls and checks every device and pci struct in the system for changes and applies them if necessary - driver loading included.