You don't want or need the write option. That's why the
free version of HDTune is good enough - you just want
a rough idea of what "class" of drive you own. (As you
speculate, if a benchmark has a write option, you'd want
to know whether it is destructive or not.)
Well, the reason you did this benchmark, is to see
if the disk drive is fast enough to give good network
copy speed.
And the MDT is not.
The benchmark shape is a curve, and your results range
from 58MB/sec to 31MB/sec over the surface of the platter.
You said you got a transfer rate over the network of
40MB/sec best case. If the place the file is to be read
or written is in the middle of the disk, I can see the
disk being the limiting factor.
That's why you first want to set up a network test
condition, that relies less on a disk. For convenience,
I used RAMDisks for storage, so I could have the freedom
to test regular protocols. And a 1GB sized RAMDisk is
all my computers could have in common, so that's the
size I used. (One computer could have had a bigger
RAM disk, but then that wouldn't be a good candidate
for the smaller computer. I do RAMDisk to RAMDisk transfers
over the network, to eliminate storage speed as an issue.)
Certainly, doing real-world test cases, like hard drive
to hard drive transfers over the network, will tell you
the final result. But it doesn't tell you what part of
the setup is a limiting factor.
You can benchmark the drives. The Seagate end looks good,
and you'll likely hit 100 on that end.
Using network tests like iperf or ntttcp, is to test
the "part in the middle", your network connection.
But any benchmark utility like that, that requires user
tuning, may make it harder to understand the results
and what is really happening.
*******
To "fix" the 845GL, the easiest solution is
1) Buy another Seagate, like the one you just benched.
2) Your 845 motherboard only has IDE. You purchase an
IDE to SATA adapter.
This plugs into the back of a SATA drive. This is the one
I use for experiments. The output is a 40 pin IDE connector,
suitable for plugging to a ribbon cable. Using this,
converts your Seagate, into an IDE drive.
http://ca.startech.com/product/IDE2SAT-25in-and-35in-40-Pin-Male-IDE-to-SATA-Adapter-Converter
Using (1) and (2), you'll get to the 88.9MB/sec write level
as per the Intel datasheet. That's the best I can do for you.
The reason I can't do better, is the PCI bus. If you buy a
SATA add-in card for your 845, it sits on the PCI bus. The
NIC card sits on the PCI bus. The traffic from the two
adds together. The aggregate traffic on the PCI might
be 120MB/sec best case. Splitting that in two, giving
60MB/sec to the NIC and 60MB/sec to the hard drive during
a network transfer, is worse than using the SATA adapter
solution above.
If you use a SATA adapter on the IDE cable, and a PCI NIC,
the 266MB/sec hub supports both of them. You can draw
88.9MB/sec from the IDE interface, 88.9MB/sec on the NIC
over the PCI bus, and the total of ~180MB/sec or so,
fits within the 266MB/sec hub limit. By "spreading the load"
around, you end up with the potential for 88.9MB/sec.
Obviously, this only works, if your network-specific testing
identifies that the network (running some protocol), can
hit above 88.9MB/sec. If the NIC is actually limited in some
way, to 40MB/sec, or you run out of CPU cycles, then installing
the fast disk purely for this purpose would be a waste of time.
So before buying a new disk, you *still* need to test just the
network portion. What I recommend, is a protocol that
allows you to check with Wireshark, that the protocol is
working as expected. (A good test case, will have lots of
1K+ sized packets going in only one direction, without a lot
of other traffic mixed in. Using Wireshark, you can see
how "pure" the test case is.)
Even my RCP test case, the packet pattern didn't look perfect.
By using Wireshark, I could see why selecting Jumbo Frames,
was failing to go faster. For some reason, the packets being
sent, were all different sizes, in a repeating pattern, with
too high a ratio of ACK packets. Using non-jumbo packets
was leading to a better looking trace in Wireshark.
You can't run a whole bulk transfer through Wireshark,
because it will exhaust all the memory on the computer.
You don't do Wireshark protocol analysis while transferring
a 1 GB test file on the disk. I did my testing with a 7 MB
file, so Wireshark would gather a ~7 MB sized trace. And
by doing that, only a little memory got used. Then I could
scroll through the trace, to better understand the
transmission pattern. I could probably afford to go back
and repeat my FTP testing, and use Wireshark to figure out
why it was slower than expected.
Paul
