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 guess we all have our weaknesses, mine is off-by-one errors, which are
a bad thing when writing code for a statistics class at school ;)
The "Gaming" benchmark has the same issue with nan coming out of the
STDEV calculations, probably requires the same fix as before.
Anyway Peter Williams has promised to fix it for me (yay!).
Secondly, the benchmarking of loops_per_ms is running forever, and I
managed to determine where its happening.
In calibrate loops you run a while loop and iterate to get 1000 for
run_time, then you calculate it one more time to ensure it was right
*however* you put a sleep(1) before that. It seems to seriously skew the
results, as it consistently adds ~500 to run_time, as run_time is now
1500, it jumps back up to redo because of the goto statement, and runs
the while loop again, continue ad nausium. I added some simple debugging
output which prints run time at the end of each while loop, and right
before the goto if statement, this is the output.
The solution I used is of course to simply comment out the sleep
statement, then everything works nicely, however your comments appear to
indicate that the sleep is there to make the system settle a little,
perhaps another method needs to be used. Thanks for your time!
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 the sleep
1 I have not had spurious results returned by the calibration. I'm open to
suggestions if anyone's got one.
Yeah, thats right, it spins forever on both my athlon-tbird and my
athlon64 (in x86_64 mode). I'll take another look at the code tonight,
to see if I can figure out why its causing this, or another way of
incurring the delay you're looking for.
Cheers,
Con
--
Gabriel Devenyi
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |