Today we are going to test the Seagate Cheetah ST373307LW disc together with the Adaptec 39320D controller as we promised before. Last time when we dealt the Seagate and Fujitsu discs we got strange results for the Cheetah - at the queue line equal to 64, the performance in all IOMeter tests markedly dropped down. Today we are going to clear up the situation. On the preparation table we have two drivers of the Adaptec 39320D controller and one register parameter. 

So, last time we used the driver v1.0.0.0, and in the register key HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\adpu320\Parameters\Device\ in the DriveParameter the queue length was set to 64 (/MAXTAGS = 64). Today we will use the recently released driver v1.1.0.0 and see how performance of the disc/controller tandem depends on this parameter.

But first of all, let me focus on some concepts used in this article. You probably know that Intel IOMeter is a synthetic test generating a certain traffic. In general, the traffic is a flow of commands for reading/writing of data blocks of different sizes. Taking into account this definition and a physical arrangement of data on a disc we can consider that any disc/system traffic can be determined by the following parameters: a share of commands for reading/writing, shares of commands for operation with blocks of each size, a traffic type - serial or random reading/writing, disc load - length of a queue of requests for reading/writing. The Intel IOMeter makes possible to change all these parameters and determine them accurate to 1%. Parameters of certain values form access models. On the other hand, if we statistically analyze the traffic formed by machines working with real applications and having well-defined tasks we can get access models very close to real ones (here you can get more information on the access models used). There is one more technical parameter - a requests queue length which characterizes intensity of operation of a given access model. In our tests we use the following symbols for this length: linear - queue = 1 (linear reading/writing), very light - queue = 4, light - queue = 16, moderate - queue = 64, heavy - queue = 256 (the most thick flow of requests). But today we will use numerical values of the queue length for simplicity sake. Now, when we are through with the technological excursus, let's start our tests. 

Tests

The testbed is standard:

• Mainboard - Supermicro 370DLE (BIOS ver. R1.32);
• CPU - Intel Pentium III 800EB;
• Memory - 512 MB PC133 SDRAM;
• System disc - Western Digital WD100BB-00AUA1;
• OS - Windows 2000 Professional SP3;
• SCSI adapter - Adaptec 39320D (driver ver. 1.0.0.0 and ver. 1.1.0.0). 

The discs will be tested today only in the Intel IOMeter in 6 main patterns (Workstation, File-server, Web-server, Database, Random read & Random write). 

Intel IOMeter

Last time it was simple - we used the driver v1.0.0.0 with the default parameters. But the outcome wasn't that simple or explainable. So, at www.adaptec.com we downloaded the driver v1.1.0.0 and installed it tracing the changes in the register with the advanced Ashampoo Uninstaller. The installation log file shows that the parameter which limits the maximum queue length on the software level (we'll call it MAXTAGS, in contrast to 'queue' or 'queue length' that characterizes the load generated by the Intel IOMeter) changed 64 to 32. We ran the tests and got beautiful smooth results in all patterns:

The only downside is that with the queue length over 32 and, thus, a higher disc load you can forget about a performance growth, which is a disadvantage for a disc designed for server utilization. Let's try to lift MAXTAGS up to 64 and then up to 256 which is the maximum possible value. Well, with only one parameter changed the driver v1.1.0.0 shows the results we had with the version 1.0.0.0. Let's change the driver for the old version again and set MAXTAGS to 32... The scores look like those we got with the v1.1.0.0 and MAXTAGS equal to 32 by default. Have a look:

By the way, the tests with the driver v1.1.0.0 and MAXTAGS = 256 were started several times on the same computer but under Windows 2000 Professional with the Service Pack 2, and they failed to finish in all patterns hanging in the attempt to increase the queue length up to 64. What's the reason and why there are no such problems with the Service Pack 3 is not clear.

So, at MAXTAGS = 32 with any drivers the results are smooth, but at the higher MAXTAGS the performance jumps whatever the driver is installed. 

Conclusion

Well, the picture is very interesting. Judging by the test results it seems that the new driver version differs from the old one only in one parameter value in the register. I'm surprised that the new parameter value simply reduces the disc performance instead of curing unexplainable jumps. We can point to this problem and then leave it aside but there is just one snag. Both Seagate Cheetah 10K.6 and Adaptec 39320D are typical and popular representatives of the SCSI 10k and Ultra320 controller classes of two respected companies, that is why it would be logical to choose this disc and this controller as the reference ones. So, on one hand, we do not have  weighty arguments to replace either the controller or the disc in this tandem, but on the other hand, the results obtained are very important and we can't neglect them.

All in all, we decided to use the disc and the controller as the reference solutions in further tests, with the driver v1.1.0.0 and MAXTAGS = 256 of the Adaptec 39320D controller. This value is chosen since it doesn't reduce the disc performance and doesn't limit the maximum request queue length. We also chose v1.1.0.0 since we hope that the guys at Adaptec brought some more changes in the driver beside one parameter in the register (at least, it takes several hundreds of kilobytes). 
  

Write a comment below. No registration needed!