About martin

Profile Information

Previous Fields

The way it's supposed to work is that drives only disappear when you delete a configuration. Purging old tests shouldn't affect whether a drive is shown or not.
There can be many configurations for a computer, and many tests for a configuration. We don't delete a drive from a configuration just because you turned it off for one test, since you might turn it on again for another test.
I suspect that you're taking the scores and rankings way too seriously.

Our test is timed for 10 seconds and reads and writes at the file level. It is what it is. It reports the speeds it finds at the conditions of the test.
For over 99% of the systems we see tested, our results make sense, although they can be awfully sensitive to fragmentation, which is why we check that as well. Once in a while we see a case like yours. It's awfully hard to know exactly what's going on without doing extensive diagnostics, and we can't afford to do that for a free test.
Are you complaining because we show 400 MB/s and HDTune shows 50 MB/s at 8? HDTune also shows 400 MB/s at the high end of the test.
Don't worry; be happy.

We've done what we can. This is a pathological case, and we can't change our tests to handle it without making the test run much longer at no benefit to 99% of users.
Based on the HDTune results I'd drop the 6th disk to get more consistent speeds, but that's your choice, not mine.

Ha! Look at the values at the left of that bar graph, the ones for smaller files. There's your 10-22 MB/s. It might be informative for you to run the same test with 5 disks instead of 6 to see if the small file performance improves. After all, most of your computing involves reading and writing small files unless you're spending your whole day copying disks or you're an audio-visual guy with huge movies and sound files.
We might be able to give you a more realistic number from OverDrive if we increased the maximum file size for the disk tests. I'll discuss doing that with the other developers.
As for the debug test, I tried it myself and the OverDrive version doesn't spit out the numbers I was looking for. The old full tests would stop on each page and give you debug output if you asked for it.

One issue here is that the different tests measure different things. HDTune 2.55 runs an extended read-only low-level benchmark to obtain the disk speed; you'll notice that the reported speeds are much higher in the initial, sequential portion of the test than in the later, random-access portion of the test.
The OverDrive disk test runs a 10-second or 4 GB read-write file-level benchmark to obtain the disk speed. That corresponds to tests that are in HDTune Pro 3.50, but not HDTune 2.55.
There are two possibilities here. One is that there's a real problem with your setup for writing with the 6th disk in there; the other is that there's a problem that confuses the OverDrive disk test when your drive is that fast.
One way to figure out what's going on would be to enable debugging on the OverDrive disk test and report the disk test section times here: if the second time (the write test time) is very big, there's a real problem. Another way to figure out what's going on would be to download a free 15-day trial of HDTune Pro 3.50 and look at the write and file benchmark results.
Does that help?

Do you have OsdMaestro running? If so, try turning it off. It might be interfering with the 3D test.
The missing DLL problem on the debugging standalone test has been fixed. The new version should be posted for downloading soon.
Your SSD speed problem most likely has to do with the different access patterns used by the two tests, ours and HDTach. It doesn't mean either test is wrong; it means that they're testing different things. We used to break out serial and random reads and writes, but people complained that was too technical for them.
If you really care about SSD speed measurement, please start a different thread about it specifically.

I would be surprised if changing DirectX versions matters at all. What's more likely is that something is slightly broken in your DirectX installation. Reinstalling DirectX should repair the problem.
Reinstalling Windows is of course The Big Hammer, and almost always fixes weird problems like this one.
I don't know why you should be seeing this problem with our software and not other benchmarks, unless they're not using the vertex processor or they run right after a clean boot. It's possible that you run some other software that uses Direct3D and won't give up the vertex processor to our benchmark.
--mh

Rob, it sounds like you've got a very slow connection from Utrecht to Dallas. Perhaps we need to change the timeout value to allow for that, now that the PCPitstop CAB is so much bigger than it was.
BTW, mhLbl.dll is only a tiny test control. The controls you need for the full tests are pcpitstop.dll and pcpitstop3d.dll. It's the 3D control that's big.
Can you run a bandwidth test against our Dallas server and tell us the results? Thanks!
-- mh