Mail Archives: djgpp/2001/01/19/02:37:33
"Tom St Denis" <stdenis AT compmore DOT net> wrote in message
news:948d3i$gne$1 AT nnrp1 DOT deja DOT com...
> > NOW, DO YOU STILL DISAGREE AND CLAIM THAT MY CODE IS WRONG???
>
> Hmm loser: I don't have a 807mhz processor. Your code is wrong. A
program
> that says 1+1=3 is wrong despite being coded flawlessly in perfect ANSI C.
Loser you are! and you know why? because you:
1. do not understand what really happens
2. don't pay attention to my arguments
3. can not say what exactly is wrong
4. call me "loser" (you started, not me! - this makes you're twice a loser -
think of it in the meanwhile)
5. I probably can figure out something in addition to this, but it's not of
my concernt and that's enough for now.
Now, divide (807-800) by 800 and multiply by 100%. what do you get? around
1% (actually less than that). You must be glad to have this error value
because you run this program under windows or whatever which
1. doesn't update BIOS tick counter at correct moments or does have a lot of
extra code right after that which may take different time
2. performs disc caching connected with the timer interrupt and/or another
interrupt can occur between "JNE somewhere" and "RDTSC" and thus the problem
is not in my program. instead this is a problem of having competetive code
in the system.
This is why I have 16 measurements in a raw and then find the average.
Btw, have you ever performed real measurments? Let's say in a physics lab?
An error of 1%...2% is treated as a normal thing. There are not many things
in the life that are perfect or perfectly precise.
If you want to have a more precise value, go ahead and unload or disable all
the drivers existing in the system or disable corresponding IRQs except the
timer interrupt (windows will not let you do this :).
Or you can try to increase number of measurements to have a better
average value.
You may also try running this thing under DOS w/o any drivers loaded.
I bet it will give you a better value. In fact, this helps - I've just tried
and
got a rid of the fluctutation of the average value - it's now 564MHz for
my Celeron566MHz (difference is less than 0.4%, btw).
If you still don't like having this 1%, go ahead and round the value
towards closest you like.
For your info, back in days of PCs, XTs, ATs (286-486) you could not get
a correct value of the CPU speed. Various tests were intended to find out
the frequency, but since CPUs of different manufacturers were different in
principle (and still are :), tests took different amount of time on same
kind
of CPUs. This way you couldn't approach 1% of measurements precise.
Final words...
Unless you can prove that the presented code is incorrect or you write a
program that does *always* say the same thing as written on the CPU
chip, don't bother to come up and flame.
Have a nice day.
--
Alexei A. Frounze
alexfru [AT] chat [DOT] ru
frounze [AT] ece [DOT] rochester [DOT] edu
http://alexfru.chat.ru
http://members.xoom.com/alexfru/
http://welcome.to/pmode/
- Raw text -