Re: NT4 bug? Or bug in my hardware?

[bp () dial isys hu (Peter Berendi)]

> I fed this one to my NT guy, and here is what he came up with:
>
> ---
> Pete,
>
> I just tried this on our NT 4.0 server (no SP2, Pentium 133/32).
> While the performance monitor indicates a 100% processor load, other
> measurements indicate otherwise.  Subjective evaluation of the
> machine indicate that the processor is running at "normal" speed.
> In addition, limited gnu utilities installed on this NT server find
> no problems with the CPU load, performance or memory space.
>
> All this would seem to indicate that the "bug" found is in fact
> affecting the performance _measurement_ of the CPU, rather than the
> CPU (or the kernel) itself...

I can prove you the opposite. Try to repeat my experiment:

I wrote a quick and dirty 'performance measurement utility' in C

-------------------
#include <stdio.h>
void zz() {
 }
int main() {
  int i, j = 0, t;
  t = time(NULL);
  while(1) {
    for(i = 0; i < 1000000; i++)
      zz();
    j += 1;
    printf("%f\r", (time(NULL) - t + 0.0) / j);
    fflush(stdout);
  }
  return 0;
}
-------------------

What does it measure (for those who can't speak C): an average of
how many seconds does it take to execute a specific instruction
sequence. The lower is the number it prints, the faster is
_this_process_ executed.

First, in Control Panel -> System -> Tasking, set 'Foreground and
background applications equally responsive'  (or alternatively,
after starting my utility, press alt-tab to move the focus off the
command prompt window)

Then start a command prompt and run my application for one minute on
your freshly restarted, unloaded NT machine (wait 5 minutes after
logging in to let all services finish their initialization). It
printed me 0.18 on a Pentium-90 machine with NT Server 3.51.

Next, abort the program with ctrl-c, do the telnet localhost 135
trick and restart my utility. This time it printed me 0.37 on the
same machine, it means that this process was given only roughly
_half_of_the_processor_time_ it was given earlier.

I repeated this experiment a few times, the results was always the
same.