OSDev.org

Hi all.

I just started a 'How can i tell cpu speed' page on the FAQ, hoping that i would find all the bits and bytes in the long-burried posts, but i have to admit i'm still missing the proper tutorials/code snippet so far.

So if one of you has something to offer, please feel free to add your contribution to http://www.osdev.org/osfaq2/index.php/H ... peed%20%3F

Cheerz

hi,
This can be easily done by using rdtsc in the pentiums. I have a small code written for gcc in linux. If you are using in your own OS, you have to write your own sleep function. That can be done by using timer chip. I ont have code for that right now.

The detailed explanation can be found at intel's document at
ftp://download.intel.com/design/Pentium ... 161808.PDF

It says that you have higher precision if the sleep value is longer.

If you dont want to use sleep function you can monitor the clock tick value in the BDA whick gets incremented in every clock tick. It it is 6ch in the BDA.


int main()
{
unsigned int slow, shigh;
unsigned int elow, ehigh;
unsigned long long start=0, end=0, result;
asm(
"rdtsc\t\n"
:"=a"(slow), "=d"(shigh)
:
);

sleep(1);

asm(
"rdtsc\t\n"
:"=a"(elow), "=d"(ehigh)
:
);
start |= shigh;
start <<= 32;
start |= slow;

end |= ehigh;
end <<= 32;
end |= elow;

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

}

Or if you dont want to use 64bit data type. You can just use the lower 32 bits of the tsc.

regards virusx

virusx wrote: Or if you dont want to use 64bit data type. You can just use the lower 32 bits of the tsc.

And get the same bug Windows has? Not a chance.

Windows cannot calculate >4.3GHZ processors correctly because of, you guessed it, chopping off the MSDW (most significant dword). Theinquirer.net had a 4.3ghz prescott running at, what Windows said, 10mhz. (4.300 - 4.294 = 0.006 ~= 0.01)

Do your homework before posting explicit bugs.

hi candy,
thanks for the nice info. I didn't know that.

regards

The detailed explanation can be found at intel's document at
ftp://download.intel.com/design/Pentium ... 161808.PDF

It says that you have higher precision if the sleep value is longer.

FTP gives an error that it doesn't exists at all ::)
So, give a better url

the only google hit for 24161808.pdf points toward Xperts Xchange ...
AP-485 Intel Processor Identification With the CPUID Instruction 241618 (rev 08)

design\Xeon\applnots\24161825.pdf on ftp://download.intel.com seems to be the closest match ...

support\processors\procid\ has all the CPUID stuff ...
i'll report later if the download was indeed interresting ...

However, there is a major issue with the code virusX posted: how can you know 'how far' the current second have advanced when you get the initial timestamp ?
As far as i can tell, it would be better if RDTSC was issued *in* the interrupt handler (both for the initial read and for the final read).

Pype.Clicker wrote: However, there is a major issue with the code virusX posted: how can you know 'how far' the current second have advanced when you get the initial timestamp ?
As far as i can tell, it would be better if RDTSC was issued *in* the interrupt handler (both for the initial read and for the final read).

My choice would be to put it in the assembly stub for that particular interrupt, after pushing the registers, and pushing the return of that one on the stack as well, then the value is passed up to the cpu module to work with, and then the timer is called.

Which gives an always-accurate cpu clock (for people that reprogram their clock to 100hz, the count you get from the processor clock minus the previous one is 1/100th of the processor speed, which is something like 12000000 for a duron 1200mhz so you can /easily/ get the processor speed. For easier handling on the nerd size, make the clock go at 128hz and use a left shift of 7 or a multiply of 0x80 )

hi,
I downloaded that document long ago from
http://www.x86.org/intel.doc/appnotes.htm
see ap-485.

I have that doc but how do i attach here???

regards

i still have to read the section 12 "Operating Frequency" of ftp://download.intel.com/support/proces ... 161815.pdf ... however one thing that concerns me is that the PIC never exactly run at 1/N Hz, right ? is there a PIC frequency that would be better suited so that we're sure an integer amount of seconds elapsed after an integer amount of clock ticks ?

**wow*wow*wooow** the application note even has

; Filename: FREQUENC.ASM ;
; Copyright (c) Intel Corporation 2001-2003 (...)
; This example assumes the system has booted DOS.
; This program runs in Real mode.

should be a good starting point

Pype.Clicker wrote: i still have to read the section 12 "Operating Frequency" of ftp://download.intel.com/support/proces ... 161815.pdf ... however one thing that concerns me is that the PIC never exactly run at 1/N Hz, right ? is there a PIC frequency that would be better suited so that we're sure an integer amount of seconds elapsed after an integer amount of clock ticks ?

If you program it to 20 hz it should run 100% exact. However, running at 1/5th of that (famous 100hz, value is 11932) that makes it use a 0.2 too large divisor, which results in a deviation of your clock running 20 ticks slow compared to the 1193180 tick clock, or one second every 59659 seconds. For frequency determination this is a pretty good score.

Also, is determining the exact freq life threatening for anybody? If not, don't complain about roundoffs.

hi,
How can you say that my code has the major defect. What it does is reads the tsc in two interval(1 sec). substracting the second value with the first value and dividing with interval (1sec) gives the cpu speed. It is the method given by intel's manual.
Try it, it gives value near to accurate. In my sys it gives 1402 mhz(1400 mhz real).

I ripped the docs below from intel doc.

[attachment deleted by admin]

virusx wrote: hi,
How can you say that my code has the major defect. What it does is reads the tsc in two interval(1 sec). substracting the second value with the first value and dividing with interval (1sec) gives the cpu speed. It is the method given by intel's manual.
Try it, it gives value near to accurate. In my sys it gives 1402 mhz(1400 mhz real).

I'm not saying your code has any defect at all. I am saying your suggestion can only create a bug in other operating systems..

By the way, how many operating systems still leave the BIOS intact with its PIT setting to increment the BDA setting? And how precise is that?

the code you expose from intel starts with a "wait_new_tick" loop, which indeed will give you a good timing as both the initial RDSTC and final RDSTC occur "close" to an IRQ0.

Notice that 'sleep(1)' never guarantees your code will be resuming one second later: it justs guarantees you that you will sleep for *at least* one second, which may lead to surprising results on a heavy-loaded system.

thanks for your submission, anyway

I expect BDA Polling to give poor results in protected mode, since that variable is incremented only through the RTC interrupt ... If i wish to have a interruptless approach, i think i would program the PIT in "one-shot" mode (i did it recently for telling if i'm on a real CPU or on Bochs) and poll the PIT counter until its value reaches zero.

Also, does someone know if the TimeStamp Counter continues incrementing when one issues the HLT instruction ?

and obviously, even Intel tries to tell the closest multiple of base bus frequencies (33MHz, 50MHz) that approaches the measured value.

Pype.Clicker wrote: and obviously, even Intel tries to tell the closest multiple of base bus frequencies (33MHz, 50MHz) that approaches the measured value.

algorithm: multiply the value you get by 6, add 50, chop off the last 2 decimals, divide by 6, and use that value. This rounds off to 1333 / 1350 / 1366 / 1387 / 1400 etc. so you get a "nice" speed instead of 1402.123 mhz. And just for a hint, try searching the processor ID string, it usually contains the speed too (note, the speed, not the frequency)