Wrong.

Counting the number of TSC increments during a known period of time
is not a reliable method of establishing the current CPU core clock
frequency, because -- as I've pointed out in my earlier response --
the x86 architecture does not guarantee that the TSC is incremented
at that particular frequency.

For example, take the following assembly code snippet which targets
a DOS environment. In essence it waits for a timer tick, then reads
the TSC value, then waits for 91 timer ticks (or about 5 seconds at
a rate of ~18.2 timer ticks per second), and then reads the TSC va-
lue again, so that it can compute how often it has incremented over
the course of five seconds.

mov ax,0000h
mov ds,ax
mov bp,046Ch

mov ebx,[ds:bp]
@@: mov ecx,[ds:bp]
cmp ebx,ecx
je @B

rdtsc
mov esi,eax
mov edi,edx

%REP 91 ; 18.2 * 5 seconds = 91 ticks
mov ebx,[ds:bp]
@@: mov ecx,[ds:bp]
cmp ebx,ecx
je @B
%ENDREP

rdtsc
sub eax,esi
sbb edx,edi

int3 ; halt the debugger, so that EDX:EAX can be observed

jmp $$ ; do it again

mov ax,4C00h ; skip the previous JMP to return to DOS
int 21h

Granted, this code is far from being perfect. And yet it manages to
produce surprisingly accurate results.

For example, I ran it in a DOS box under Windows 2000 Professional,
using Turbo Debugger. As expected, the program took five seconds to
go through the 91 timer ticks (which Windows happily fakes for that
good old DOS box).

Now, on my notebook's 866 MHz Crusoe processor -- forced to 866 MHz
by means of LongRun -- I can observe about 1_0000_0000h cycles pass
in five seconds... which comes to 859 MHz. (Quite accurate when you
take W2K, TD, and dynamic translation into consideration!)

However, the result remains the same, even if I force the processor
to 800 MHz. Or 667 MHz. Or 533 MHz. Or 300 MHz.

Why? Because Crusoe always increments its TSC at the chip's nominal
core clock frequency, i.e. 866 MHz in my case, not the current core
clock frequency.