On Sat, 6 Aug 2005 13:37, Gabriel Devenyi wrote:
> After conducting some further research I've determined that cool n quiet
> has no effect on this "bug" if you can call it that. With the system
> running in init 1, and cool n quiet disabled in the bios, a sleep(N>0)
> results in the run_time
After conducting some further research I've determined that cool n quiet has
no effect on this "bug" if you can call it that. With the system running in
init 1, and cool n quiet disabled in the bios, a sleep(N>0) results in the
run_time value afterwards always being nearly the same value of
After conducting some further research I've determined that cool n quiet has
no effect on this bug if you can call it that. With the system running in
init 1, and cool n quiet disabled in the bios, a sleep(N0) results in the
run_time value afterwards always being nearly the same value of
On Sat, 6 Aug 2005 13:37, Gabriel Devenyi wrote:
After conducting some further research I've determined that cool n quiet
has no effect on this bug if you can call it that. With the system
running in init 1, and cool n quiet disabled in the bios, a sleep(N0)
results in the run_time value
On Thu, 4 Aug 2005 22:05, Gabriel Devenyi wrote:
> Con Kolivas wrote:
> > I have to think about it. This seems a problem only on one type of cpu
> > for some strange reason (lemme guess; athlon?) and indeed leaving out the
> > sleep 1 followed by the check made results far less reliable. This way
Con Kolivas wrote:
I'd appreciate it. It's almost like some power stepping that's responsible.
I've never seen it happen on any intel processor (including the pentiumM ones
which have truckloads of power saving features). I've asked many people if
they're running some equivalent of
Con Kolivas wrote:
On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:
Hi Con,
You must hate me by now...
No. A bug report is a bug report. I hate the fact that I coded up 2000 lines
of code and am still suffering from a problem in the same 10 lines that I did
in version .01. PEBKAC.
I
On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:
> Hi Con,
>
> You must hate me by now...
No. A bug report is a bug report. I hate the fact that I coded up 2000 lines
of code and am still suffering from a problem in the same 10 lines that I did
in version .01. PEBKAC.
> The "Gaming" benchmark
Hi Con,
You must hate me by now...
The "Gaming" benchmark has the same issue with nan coming out of the
STDEV calculations, probably requires the same fix as before.
Secondly, the benchmarking of loops_per_ms is running forever, and I
managed to determine where its happening.
In calibrate
Hi Con,
You must hate me by now...
The Gaming benchmark has the same issue with nan coming out of the
STDEV calculations, probably requires the same fix as before.
Secondly, the benchmarking of loops_per_ms is running forever, and I
managed to determine where its happening.
In calibrate
On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:
Hi Con,
You must hate me by now...
No. A bug report is a bug report. I hate the fact that I coded up 2000 lines
of code and am still suffering from a problem in the same 10 lines that I did
in version .01. PEBKAC.
The Gaming benchmark has
Con Kolivas wrote:
On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:
Hi Con,
You must hate me by now...
No. A bug report is a bug report. I hate the fact that I coded up 2000 lines
of code and am still suffering from a problem in the same 10 lines that I did
in version .01. PEBKAC.
I
Con Kolivas wrote:
I'd appreciate it. It's almost like some power stepping that's responsible.
I've never seen it happen on any intel processor (including the pentiumM ones
which have truckloads of power saving features). I've asked many people if
they're running some equivalent of
On Thu, 4 Aug 2005 22:05, Gabriel Devenyi wrote:
Con Kolivas wrote:
I have to think about it. This seems a problem only on one type of cpu
for some strange reason (lemme guess; athlon?) and indeed leaving out the
sleep 1 followed by the check made results far less reliable. This way
with
14 matches
Mail list logo
