Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance

On Wed, Sep 02, 2009 at 04:36:29PM +0200, Olivier Smedts wrote:
> 2009/9/2 Emil Mikulic <emikulic_at_gmail.com>:
> > On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote:
> >> Hi,
> >>
> >> I've been testing the new siis driver, and I have found no
> >> appreciable performance change, using dd as a measure of "raw"
> >> performance.
> >>
> >> I get about 40MB/s read, and 30MB/s write.  See attached
> >> bench-*.txt files.
> >
> > [...]
> >
> >> ada0: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
> >> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
> >
> > Huh, I have the same disk:
> >
> > # dmesg | grep ad4
> > ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata2-master SATA300
> >
> > Sequential read on a disk this size should be around 120MB/sec at the
> > outer tracks:
> >
> > # dd if=/dev/ad4 of=/dev/null bs=128k count=5000
> > 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec)
> >
> >> Also I find it surprising that my gmirror read is only 40MB/s,
> >> and not 60-80MB/s, any thoughts on this?
> >
> > Stripe will give you higher throughput.
> > Mirror will give you more random seeks per second.
> 
> And higher read throughput.

This is a myth and not true for linear access in the general case.
A disk usually lays the track reversed order to increase read throughput.
Once the head is positioned it reads data into cache until the
asked block is reached, so it already has more or less of the following
blocks in cache.
If you need the following block you better ask the same disk, because
at average it already has the half track in cache.
If you ask another disk it has to do a physical read first.
To really increase linear throughput you need to preread data at a large
offset (knowing the physical layout of the drive), but since in real
world this is usually data of a completely different file it doesn't
make much sense.
For short range switches you just ask two disks for different blocks,
but require them to issue the same physical reads.
Of course you can double the read throughput, but only tuned for
contructed cases.

Striping is different, because say first strip is accessed from disk 1
and second stripe from disk 2.
This reduces performance, because unlike disk 1 disk 2 has the following
block not in cache, but for upcoming blocks you win from the cummulative
preread cache.
But real world filesystem access rarely is that linear, so even then it
mmight be better to increase the stripe size large enough to not take
the linear win, but also not have the disk switch loss.

In real world you usually can win performance from random access in
both cases and random access is what you almost always really want to
increase.

-- 
B.Walter <bernd_at_bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.