Mail Archives: djgpp/2001/01/19/03:15:23
just an addition.
besides all those arguments I presented here, it's up to you not to use this
program which I posted here for free to the public domain. if you don't like
it, nobody pushes you to use it. that's simple enough to understand, I
think.
--
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/
"Alexei A. Frounze" <dummy_addressee AT hotmail DOT com> wrote in message
news:948q04$ct3cj$1 AT ID-57378 DOT news DOT dfncis DOT de...
> "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 -