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 v188.8.131.52, 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 v184.108.40.206 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.
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. 220.127.116.11 and ver. 18.104.22.168).
The discs will be tested today only in the Intel IOMeter in 6 main patterns
(Workstation, File-server, Web-server, Database, Random read & Random
Last time it was simple - we used the driver v22.214.171.124 with the default parameters.
But the outcome wasn't that simple or explainable. So, at www.adaptec.com
we downloaded the driver v126.96.36.199 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 v188.8.131.52 shows the results we had with the version 184.108.40.206.
Let's change the driver for the old version again and set MAXTAGS to 32... The
scores look like those we got with the v220.127.116.11 and MAXTAGS equal to 32 by default.
Have a look:
By the way, the tests with the driver v18.104.22.168 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.
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 v22.214.171.124 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 v126.96.36.199 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!