Trixter
Veteran Member
Ok, I actually read all 22 pages of this thread and that answered most of my questions: I see these numbers are how many milliseconds the operation took so obviously lower is better. Sill not sure on what some of them mean like MemEATest and 3DGameTest.
Sorry, I've let this project stall a bit. I plan on doing some coding in a few weeks to finish up a realtime tool that compares against systems; I've abandoned the idea of trying to do it with a very pretty interface in the interest of just Getting It Done.
Lower numbers are better in the five microsecond timing sections, but for the Score, which is the actual synthetic metric, higher is better. On extremely fast machines, the microsecond timings get close to 0 or hit 0, but the Score is still representative of which machine is faster than another.
The names of the tests represent the code that is being executed; in what you wrote above, "MemEATest" is a test of effective address calculation speed when accessing memory. "3DGameTest" is a mixture of opcodes in the same frequency as several 3-D DOS games that are not hard-coded (ie. they scale nicely as processor speed increases).
You can read some background info at http://dosbenchmark.wordpress.com and you can download the actual metric code sections at http://dosbenchmark.wordpress.com/downloads/ if you want to see exactly what they're doing. Even if you don't understand assembler, the 3DGameTest code has a lot of comments at the beginning that explain the methodology and what games were used to come up with the metric.
I have a theory about the Packard Bell 560 hangup – I tried this benchmark on one other system and got the same result – CAPSLOCK can be toggled but the program appears to be not responding. Both systems have a few things in common, but I think only one is the real issue as the “CPU speed detect” is the hang-point. It seems that there is a problem detecting newer “generation” processors that are underclocked – It is probably particular to the Pentium line as it was so long lived and there were numerous changes and die shrinks, etc.
That, and my CPU model/speed detection is not foolproof and can hang some machines if I haven't had access to them. For such machines, run with "-s" and those tests will be skipped. Detection of Pentiums and above is somewhat easy thanks to the CPUID instruction, but for CPUs earlier than that, you have to tickle all sorts of bugs and undocumented opcodes to hone in on what you have. Around 1-2% of the time, my code takes a wrong turn somewhere and hangs certain CPUs.
The CPU model detection is what actually hangs the CPU. The CPU MHz detection is based off of the model detection, so if it hangs, it's never getting to the part that figures out what MHz the CPU is running at.