SATA HD & DMA ?

SATA HD & DMA ?

Post by Hish » Wed, 01 Sep 2004 08:01:07



Hello,
Just curious...Do Serial ATA 150 drives benefit from enabling dma
via hdparm the way regular ATA drives do?
 Any special optins I should use?
Thanks,
Hish
 
 
 

SATA HD & DMA ?

Post by Michael Heimin » Wed, 01 Sep 2004 15:36:25


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message


Quote:> Hello,
> Just curious...Do Serial ATA 150 drives benefit from enabling dma
> via hdparm the way regular ATA drives do?
> Any special optins I should use?

Mh, doesn't work for me at all:

# hdparm -d /dev/sda

/dev/sda:
 operation not supported on SCSI disks

# 3ware-check.sh
# of ports: 2
    Port 0: ST380013AS 3JV9BNGZ 74.53 GB (156301488 blocks): OK(unit 0)
    Port 1: ST380013AS 3JV9846B 74.53 GB (156301488 blocks): OK(unit 0)

Output from: tw_cli info c0 drivestatus

SATA drives on 3ware hw RAID controller running in RAID 1 mode.
Might depend on how your system uses SATA, mine recognizes them
as SCSI and those hdparm settings don't work with SCSI.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNBxoAkPEju3Se5QRAkKpAJ9fnO9k7T1IbBPCWB5OVti1yClBuwCfZ/xy
QW1qtcxZ2mFoPXDUAdF7xC8=
=Er07
-----END PGP SIGNATURE-----

 
 
 

SATA HD & DMA ?

Post by John-Paul Stewar » Thu, 02 Sep 2004 00:28:42



> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message


>>Hello,
>>Just curious...Do Serial ATA 150 drives benefit from enabling dma
>>via hdparm the way regular ATA drives do?
>>Any special optins I should use?

> Mh, doesn't work for me at all:
[snip]
> Might depend on how your system uses SATA, mine recognizes them
> as SCSI and those hdparm settings don't work with SCSI.

Do SATA drives have any mode of operation other than DMA?  It my
understanding that with SCSI turning DMA on/off is with hdparm is
impossible because DMA is the only possible mode of operation.  I'd
expect it to be the same with SATA.
 
 
 

SATA HD & DMA ?

Post by John-Paul Stewar » Thu, 02 Sep 2004 02:21:54




>>>Might depend on how your system uses SATA, mine recognizes them as SCSI
>>>and those hdparm settings don't work with SCSI.

>>Do SATA drives have any mode of operation other than DMA?  It my
>>understanding that with SCSI turning DMA on/off is with hdparm is
>>impossible because DMA is the only possible mode of operation.  I'd expect
>>it to be the same with SATA.

> From man hdparm:
>        Although this utility is intended primarily for use  with  (E)IDE
>        hard disk devices, several of the options are also valid (and
>        permitted) for use with SCSI hard disk devices and MFM/RLL hard
>        disks with  XT  inter- faces.

But as the previous poster showed, the -d option to hdparm is *not*
valid for use with SCSI disks.  Note the keyword "several", not "all"
options.

The ones that do work:  a, E (for SCSI CD-ROMs), f, g, r, t, T.  I can't
test -L (no suitable hardware) but it should work too.  Options listed
in the man page as "dangerous" weren't tried.  Aside from that, *all
other* hdparm options fail on SCSI drives.  (Real SCSI, no idea about
SATA drives that the kernel sees as SCSI.)

 
 
 

SATA HD & DMA ?

Post by Michael Heimin » Thu, 02 Sep 2004 03:14:16


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message




>>>>Might depend on how your system uses SATA, mine recognizes them as SCSI
>>>>and those hdparm settings don't work with SCSI.

>>>Do SATA drives have any mode of operation other than DMA?  It my
>>>understanding that with SCSI turning DMA on/off is with hdparm is
>>>impossible because DMA is the only possible mode of operation.  I'd expect
>>>it to be the same with SATA.

>> From man hdparm:
>>        Although this utility is intended primarily for use  with  (E)IDE
>>        hard disk devices, several of the options are also valid (and
>>        permitted) for use with SCSI hard disk devices and MFM/RLL hard
>>        disks with  XT  inter- faces.
> But as the previous poster showed, the -d option to hdparm is *not*
> valid for use with SCSI disks.  Note the keyword "several", not "all"
> options.

Yup, dunno the point of posting a few lines of man hdparm?

The only options I'm using are -tT on SCSI, just to check for
reasonable numbers, if you know the drive speed.

Quote:> The ones that do work:  a, E (for SCSI CD-ROMs), f, g, r, t, T.  I can't
> test -L (no suitable hardware) but it should work too.  Options listed
> in the man page as "dangerous" weren't tried.  Aside from that, *all
> other* hdparm options fail on SCSI drives.  (Real SCSI, no idea about
> SATA drives that the kernel sees as SCSI.)

AFAIK, the kernel doesn't know much about the RAID, it just
recognizes the device (scsi0: 3ware Storage Controller) through
the 3w_xxxx module loaded from initrd as SCSI.

Only the 3ware provided tool 'tw_cli' can configure the
controller and see the real devices in the array:

3ware CLI> help

Copyright (c) 2003 3ware, Inc.  All rights reserved.
3ware CLI (version 2.00.00.032b)

Commands   Description
-------------------------------------------------------------------
info       Displays information about the controller
alarms     Displays or deletes the list of AENs
set        Displays or modifies controller settings
maint      Performs maintenance operations on a controller
quit       Exits the CLI

Type help <command> to get more details about a particular
command.

Runs great.
;)

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNL/3AkPEju3Se5QRAhqGAKCwmswHmR9Htx0hXnEadXchO1L91gCgjA4b
LYyClst28DNrpsnzUsa7m6U=
=S1ds
-----END PGP SIGNATURE-----

 
 
 

SATA HD & DMA ?

Post by Michael Heimin » Thu, 02 Sep 2004 03:27:47


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message


[..]

Quote:> All in all, sata is a formidable waste of time and a huge marketing bluff.

Rubbish.

Quote:> pata is cheaper and works. sata hardware is still just relabeled pata with
> an adaptor. No hotplug, no queue command like scsi. A smaller cable with a
> different power plug.
> What a deal.

You are sure you know what you are talking about? Strange enough
the 3ware SATA raid controller in my box supports command queues,
as it does support hot-plug.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNMMiAkPEju3Se5QRAqzRAKCou2W5bwD5Nia3eBNeYyH6RqZVVQCg1nMB
a/87CeXANkAUuEKjda5q8cQ=
=GIJ3
-----END PGP SIGNATURE-----

 
 
 

SATA HD & DMA ?

Post by Rick Moe » Thu, 02 Sep 2004 04:01:27



Quote:> I know. I was just stating that one could try. Not that it should work.
> As sata is not scsi, perhaps hdparm -d1 should apply.

If your drivers access the disks via the kernel's SCSI layers, as is the
case with libata drivers, 3Ware drivers, and some others, then hdparm
tuning will not work.   If you're using a conventional driver/ide-class
or ataraid-class Linux kernel driver, on the other hand, it will.

Quote:> All in all, sata is a formidable waste of time and a huge marketing bluff.

Even though I'm a SCSI bigot, I'd call it an incremental improvement
over PATA in every way.

Quote:> pata is cheaper and works.

There's no reason SATA shouldn't be cheaper yet, after the inevitable
product introduction period.  Current price differences, such as exist,
are a market effect, and will go away.

Quote:> sata hardware is still just relabeled pata with an adaptor.

Not always.  Early drives were indeed just PATA drives with a Marvell
(or similar) bridge chip.  Those are either going away or gone; not sure
which.  Moreover, even those garnered some of SATA's advantages, such as
easing of length limits, thinner cables with less impairment of airflow,
etc.

Quote:> No hotplug....

SATA can in theory do hotplug.  A couple of implementations (notably
3Ware) already do their own hotplug, including on Linux.

Quote:> no queue command like scsi.

SATA does provide for tagged command queueing.  Jeff Garzik is currently
coding TCQ support for his libata driver set, accordingly.  It's not
here yet, but will be eventually.  (Then, we'll see if it works well.)

Quote:> A smaller cable with a different power plug.  What a deal.

You also get lower voltage levels (on fully-native SATA drives that
don't use a bridge chip), and consequently lower power levels, which
translates to less heat and the ability to have smaller, quieter
workstation boxes.

The "150MB/sec" bit (bus transfer speed ceiling) is smoke and mirrors,
because the drives are (as always) bottlenecked on physical read access
times, but could be useful at some distant future point.

 
 
 

SATA HD & DMA ?

Post by Michael Heimin » Thu, 02 Sep 2004 04:09:49


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message



>>> All in all, sata is a formidable waste of time and a huge marketing
>>> bluff.
[..]
>>> with an adaptor. No hotplug, no queue command like scsi. A smaller

                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Quote:>> You are sure you know what you are talking about? Strange enough the
>> 3ware SATA raid controller in my box supports command queues, as it does
>> support hot-plug.
> Of course I am. Be careful, I'm not saying that sata doesn't support
> it. But as of today NO MB supports hotplug and almost no sata drive has

Ah well, looks like I completely misread your post? Anyway, there
are lots of (server) mobo supporting hot-plug for many devices.

Please stop trying to convince me you would know what you are
talking about.

[..]

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNMz8AkPEju3Se5QRAijAAJ9FHRv+6fT6CUHqJNjRuAbRIO/9WACfSyx1
YIr1JMROi2yvM0jDbZjEAzU=
=cgy5
-----END PGP SIGNATURE-----

 
 
 

SATA HD & DMA ?

Post by Vladimir Florinsk » Thu, 02 Sep 2004 05:10:08



> Hello,
> Just curious...Do Serial ATA 150 drives benefit from enabling dma
> via hdparm the way regular ATA drives do?
>  Any special optins I should use?
> Thanks,
> Hish

Well, it's a pity this newsgroup has degraded so much, judging from the
quality of the discussion that followed your post. To answer your
question, SATA benefits from busmastering the same way as regular ATA
does. Example:

# hdparm -d 0 /dev/hde
# hdparm -t /dev/hde

/dev/hde:
 Timing buffered disk reads:   12 MB in  3.27 seconds =   3.67 MB/sec

# hdparm -d 1 /dev/hde
# hdparm -t /dev/hde

/dev/hde:
 Timing buffered disk reads:  206 MB in  3.03 seconds =  68.09 MB/sec

As far as "special options", there was never a need to use any with ATA,
and it is the same with SATA.

--
Vladimir

 
 
 

SATA HD & DMA ?

Post by Rick Moe » Thu, 02 Sep 2004 06:15:16


Stan, would you mind t* your quotations, please?  Thank you.
Welcome to Usenet.  Now, kindly learn not to leave a mess.


[Elimination of bridge chips from newer drive models:]

Quote:> Not at all. Except for (maybe) the latest raptor generation this is
> still not the case.

Well, you're mistaken.  I've just fetched for inspection and have sitting
here on my desk, for example, a Seagate ST380013AS (80 GB SATA) drive, a
model introduced probably a year ago.  (This isn't my drive; I'm
personally a SCSI bigot, as previously mentioned.)  It has no bridge
chip.

[hotplug:]

Quote:> In practice no mb with sata supports that yet.

Well, you are mistaken.  3Ware cards have made that possible for years.

Quote:> No drive supports tcq yet, apart from the aforementioned.

Well, you're mistaken.  What's not yet supported in drives is _native_
command queueing.

Quote:>> You also get lower voltage levels (on fully-native SATA drives that
>> don't use a bridge chip), and consequently lower power levels, which
>> translates to less heat and the ability to have smaller, quieter
>> workstation boxes.

> You are forgetting about the 200+W 3D video cards that are around.
> And you need to change power supply because the plug is different.

Changing the subject so quickly?   ;->

I have no idea what you mean by needing to "change the power supply",
but you probably have in mind some particular red-herring scenario that,
like 200W video cards, is nowhere inherent in the topic.

Quote:>> The "150MB/sec" bit (bus transfer speed ceiling) is smoke and mirrors,
>> because the drives are (as always) bottlenecked on physical read access
>> times, but could be useful at some distant future point.

> I do not have a crystal ball for the future, I cannot answer on that.

Don't act dense, please.  My meaning should have been perfectly plain:
A bus-level bandwidth limit that makes no difference whatsoever given
current-production hard drives' physical limitations -- e.g., ATA/100's
vs SATA's -- can be expected to eventually matter as newer hard drives
with improved physical-access speeds emerge.  It happened with ATA/33 --
eventually -- (and arguably with ATA/66) and will happen with its
successors.

Quote:> And plugging a sata controller on the pci bus is not a smart thing
> either.

1.  That's really a rather crackpot claim.  I imagine you must be making
some weird assumption about both a feeble PCI implementation and about
some farfetched bulk-transfer scenario that -- if you'd bothered to read
my earlier post attentively -- I was saying cannot occur in the present
day real world on account of physical read access limits.

2.  Of course, generally people's SATA host adapters will be chips built
into newer motherboard -- most often an ICH5 -- not an add-on card, be
such cards PCI-X or whatever.  The whole point of ATA is to do mass
storage with simple, cheap chipsets cranked out in large quantities.

--
Cheers,     Founding member of the Hyphenation Society, a grassroots-based,
Rick Moen   not-for-profit, locally-owned-and-operated, cooperatively-managed,

 
 
 

1. HD not using DMA on old laptop (which supports dma)

I recently purchased a 20GB IBM Travelstar disk for my aging Dell XPi
Latitude
(think 1995-6...). The disk it was shipped with, an 800MB IBM disk, worked
fine, but was too small. The new disk somewhat didn't live up to my
expectations when tested with hdparm, giving me 1.7MB/s throughput on the
read/write(hdparm -t /dev/hda), and a measly 14MB/s on the buffertest
(hdparm -T /dev/hda). Compared to what I'm used to on my 10GB disk, this is
BAD. The reason was that DMA was disabled, something the disk should/does
support. The old disk used DMA.
But even with a fresh kernel with the support built-in, it didn't work
enabling it!
Does someone know whether this has to do with an old bios (96), old
disk-controllers, or...what?
Thought linux handled that, not the bios... Everything else is working
allright, though.
Help/Knowledge is appreciated.

Carl-Erik
Slackware 8.1 user.

2. IPMASQADM doesn't forward local requests, ?

3. DMA Timeouts with 3112 SATA Controller (status == 0x21)

4. HP storageworks DAT72 USB external tape drive on centos 4.2

5. Seagate SATA drives and enabling DMA

6. on board sound chip ESS

7. DMA errors on SATA drive in Gentoo 2004.0 using VT8237 chipset

8. Offtopic (sorry) - Network Switches losing the plot.

9. SATA, DMA + Linux?

10. DMA Timeouts with 3112 SATA Controller (status == 0x21)

11. 2.4.21-ac4 & cm9739 & SATA

12. Installing RH8 directly to SATA HD

13. SATA HD Help