Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.hardware > #3062 > unrolled thread

SATA->IDE emulation on IBM P4 bogs down on HD writes

Started byMike Spencer <mds@bogus.nodomain.nowhere>
First post2016-05-19 20:23 -0300
Last post2016-05-30 15:49 +0200
Articles 18 — 7 participants

Back to article view | Back to comp.os.linux.hardware


Contents

  SATA->IDE emulation on IBM P4 bogs down on HD writes Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-05-19 20:23 -0300
    Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2016-05-19 16:32 -0700
      Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-05-20 12:28 -0300
        Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2016-05-20 09:10 -0700
    Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2016-05-22 11:37 +0200
    Re: SATA->IDE emulation on IBM P4 bogs down on HD writes "Carlos E.R." <robin_listas@invalid.es> - 2016-05-24 21:52 +0200
      Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-05-28 04:07 -0300
        Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-28 11:09 +0000
          Re: SATA->IDE emulation on IBM P4 bogs down on HD writes "Carlos E.R." <robin_listas@invalid.es> - 2016-05-28 17:12 +0200
          Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-05-29 01:50 -0300
            Re: SATA->IDE emulation on IBM P4 bogs down on HD writes ANTant@zimage.com (Ant) - 2016-05-29 11:41 -0500
          Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-05-29 02:41 -0300
            Re: SATA->IDE emulation on IBM P4 bogs down on HD writes "Carlos E.R." <robin_listas@invalid.es> - 2016-05-29 14:06 +0200
              Re: SATA->IDE emulation on IBM P4 bogs down on HD writes ANTant@zimage.com (Ant) - 2016-05-29 11:42 -0500
                Re: SATA->IDE emulation on IBM P4 bogs down on HD writes "Carlos E.R." <robin_listas@invalid.es> - 2016-05-29 21:09 +0200
                  Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Aragorn <thorongil@telenet.be.invalid> - 2016-05-30 10:57 +0200
                    Re: SATA->IDE emulation on IBM P4 bogs down on HD writes "Carlos E.R." <robin_listas@invalid.es> - 2016-05-30 14:21 +0200
                      Re: SATA->IDE emulation on IBM P4 bogs down on HD writes Aragorn <thorongil@telenet.be.invalid> - 2016-05-30 15:49 +0200

#3062 — SATA->IDE emulation on IBM P4 bogs down on HD writes

FromMike Spencer <mds@bogus.nodomain.nowhere>
Date2016-05-19 20:23 -0300
SubjectSATA->IDE emulation on IBM P4 bogs down on HD writes
Message-ID<87a8jl7htw.fsf@bogus.nodomain.nowhere>
This probably isn't a hardware matter per se but maybe a hardware
wizard here will have a solution.

IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
into one of those (suitable cable and power adapter) results in the
SATA drive being seen by Linux as hda. (?!) It works just fine in
every respect except one:

Large writes to the HD, e.g. cp bigfile-from-foo /dir/on/HD, runs as
expected for a few seconds, then the system bogs down.  X cursor gets
jerky, key strokes may take a minute to elicit visible response.
Copy proceeds at an acceptable speed but the box is unusable until the
copy is finished and sync'd.

This happens for any foo from which bigfile is copied -- USB thumb
drive, HD mounted over USB or another partition on the HD.  Does *not*
happen with no HD writes, viz. cp /dir/on/HD/bigfile /mnt/usb/other-media
or cp /mnt/usb/thumb/bigfile /mnt/usb2/other-thumb.

I've tried various things -- tweaking bits in /proc/... according to
Documentation/sysctl/vm.txt, runnning mbuffer. Looks (to me; but what
do I know?) like RAM is filling up with reads and stays filled up
until writes to HD are completed.

Aynone know about this?

Using SLackware 11 with 2.4.33 kernel.  A (much) newer kernel might
very well fix it.  I need to continue with the 2.4 kernel on this box.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [next] | [standalone]


#3063

FromBobbie Sellers <bliss-sf4ever@dslextreme.com>
Date2016-05-19 16:32 -0700
Message-ID<nhli7q$711$1@dont-email.me>
In reply to#3062
On 05/19/2016 04:23 PM, Mike Spencer wrote:
> This probably isn't a hardware matter per se but maybe a hardware
> wizard here will have a solution.
>
> IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
> labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
> into one of those (suitable cable and power adapter) results in the
> SATA drive being seen by Linux as hda. (?!) It works just fine in
> every respect except one:

	Not a wizard but a simple minded person who has to ask
why not A) get a SATA interface for the machine and plug it in.
	B) buy a true IDE drive to your boot drive.
	<ide hard drives for sale>
>
> Large writes to the HD, e.g. cp bigfile-from-foo /dir/on/HD, runs as
> expected for a few seconds, then the system bogs down.  X cursor gets
> jerky, key strokes may take a minute to elicit visible response.
> Copy proceeds at an acceptable speed but the box is unusable until the
> copy is finished and sync'd.
>
> This happens for any foo from which bigfile is copied -- USB thumb
> drive, HD mounted over USB or another partition on the HD.  Does *not*
> happen with no HD writes, viz. cp /dir/on/HD/bigfile /mnt/usb/other-media
> or cp /mnt/usb/thumb/bigfile /mnt/usb2/other-thumb.
>
> I've tried various things -- tweaking bits in /proc/... according to
> Documentation/sysctl/vm.txt, runnning mbuffer. Looks (to me; but what
> do I know?) like RAM is filling up with reads and stays filled up
> until writes to HD are completed.
>
> Aynone know about this?
>
> Using SLackware 11 with 2.4.33 kernel.  A (much) newer kernel might
> very well fix it.  I need to continue with the 2.4 kernel on this box.
	
	Better buy that IDE hard drive then.

	bliss

[toc] | [prev] | [next] | [standalone]


#3064

FromMike Spencer <mds@bogus.nodomain.nowhere>
Date2016-05-20 12:28 -0300
Message-ID<87zirkpx3j.fsf@bogus.nodomain.nowhere>
In reply to#3063
Bobbie Sellers <bliss-sf4ever@dslextreme.com> writes:

> On 05/19/2016 04:23 PM, Mike Spencer wrote:
>
>> This probably isn't a hardware matter per se but maybe a hardware
>> wizard here will have a solution.
>>
>> IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
>> labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
>> into one of those (suitable cable and power adapter) results in the
>> SATA drive being seen by Linux as hda. (?!) It works just fine in
>> every respect except one:
> 
> Not a wizard but a simple minded person who has to ask
> why not A) get a SATA interface for the machine and plug it in.
> B) buy a true IDE drive to your boot drive.
> <ide hard drives for sale>

  A) Seems like overkill for an old machine. What would that be, a
     card that plus into a  slot?  Jeez, the  IBM mobo *has* SATA
     plugs that work *almost* perfectly.

  B) Done that.  Nobody on my manor has new IDE drives for sale but a
     friend had a 500G IDE HD with only a few hours' uptime on it.
     Tedious process of backing up his data, re-partitioning,
     re-installing Slackware etc. etc. Ongoing.  RSN.

It would still be nice to tweak the SATA->IDE emulation into
submission.

Thanks for paying attention.


>> Large writes to the HD, e.g. cp bigfile-from-foo /dir/on/HD, runs as
>> expected for a few seconds, then the system bogs down.  X cursor gets
>> jerky, key strokes may take a minute to elicit visible response.
>> Copy proceeds at an acceptable speed but the box is unusable until the
>> copy is finished and sync'd.
>>
>> This happens for any foo from which bigfile is copied -- USB thumb
>> drive, HD mounted over USB or another partition on the HD.  Does *not*
>> happen with no HD writes, viz. cp /dir/on/HD/bigfile /mnt/usb/other-media
>> or cp /mnt/usb/thumb/bigfile /mnt/usb2/other-thumb.
>>
>> I've tried various things -- tweaking bits in /proc/... according to
>> Documentation/sysctl/vm.txt, runnning mbuffer. Looks (to me; but what
>> do I know?) like RAM is filling up with reads and stays filled up
>> until writes to HD are completed.
>>
>> Aynone know about this?
>>
>> Using SLackware 11 with 2.4.33 kernel.  A (much) newer kernel might
>> very well fix it.  I need to continue with the 2.4 kernel on this box.
> 	
> 	Better buy that IDE hard drive then.


-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]


#3065

FromBobbie Sellers <bliss-sf4ever@dslextreme.com>
Date2016-05-20 09:10 -0700
Message-ID<nhncm9$vui$1@dont-email.me>
In reply to#3064
On 05/20/2016 08:28 AM, Mike Spencer wrote:
> Bobbie Sellers <bliss-sf4ever@dslextreme.com> writes:
>
>> On 05/19/2016 04:23 PM, Mike Spencer wrote:
>>
>>> This probably isn't a hardware matter per se but maybe a hardware
>>> wizard here will have a solution.
>>>
>>> IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
>>> labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
>>> into one of those (suitable cable and power adapter) results in the
>>> SATA drive being seen by Linux as hda. (?!) It works just fine in
>>> every respect except one:
>>
>> Not a wizard but a simple minded person who has to ask
>> why not A) get a SATA interface for the machine and plug it in.
>> B) buy a true IDE drive to your boot drive.
>> <ide hard drives for sale>
>
>   A) Seems like overkill for an old machine. What would that be, a
>      card that plus into a  slot?  Jeez, the  IBM mobo *has* SATA
>      plugs that work *almost* perfectly.

	Almost and work perfectly are not the same as working perfectly
but it seems cheaper to me than the alternative.
>
>   B) Done that.  Nobody on my manor has new IDE drives for sale but a
>      friend had a 500G IDE HD with only a few hours' uptime on it.
>      Tedious process of backing up his data, re-partitioning,
>      re-installing Slackware etc. etc. Ongoing.  RSN.

	Well I expected the use of some Search Engine and a credit card.

	I pay cash only to salvagers which got me one working machine
and one which nearly boots.  The culprit is Windows 10 which was 
installed on a machine never certified for it.  It has locked the
BIOS so that it is not displayed.  Even after removing it from the
machine the BIOS is locked.  But it almost boots. ;^(

>
> It would still be nice to tweak the SATA->IDE emulation into
> submission.

	Yes and it would be nice IF I can figure out how to
remove the locked BIOS and put an unlocked BIOS on it.
>
> Thanks for paying attention.

	You are welcome, if I had anything better to do I would be
away doing it.

>
>>> Large writes to the HD, e.g. cp bigfile-from-foo /dir/on/HD, runs as
>>> expected for a few seconds, then the system bogs down.  X cursor gets
>>> jerky, key strokes may take a minute to elicit visible response.
>>> Copy proceeds at an acceptable speed but the box is unusable until the
>>> copy is finished and sync'd.
>>>
>>> This happens for any foo from which bigfile is copied -- USB thumb
>>> drive, HD mounted over USB or another partition on the HD.  Does *not*
>>> happen with no HD writes, viz. cp /dir/on/HD/bigfile /mnt/usb/other-media
>>> or cp /mnt/usb/thumb/bigfile /mnt/usb2/other-thumb.
>>>
>>> I've tried various things -- tweaking bits in /proc/... according to
>>> Documentation/sysctl/vm.txt, runnning mbuffer. Looks (to me; but what
>>> do I know?) like RAM is filling up with reads and stays filled up
>>> until writes to HD are completed.
>>>
>>> Aynone know about this?
>>>
>>> Using SLackware 11 with 2.4.33 kernel.  A (much) newer kernel might
>>> very well fix it.  I need to continue with the 2.4 kernel on this box.
>> 	
>> 	Better buy that IDE hard drive then.
	
	bliss
	

[toc] | [prev] | [next] | [standalone]


#3069

FromPascal Hambourg <boite-a-spam@plouf.fr.eu.org>
Date2016-05-22 11:37 +0200
Message-ID<nhruk9$25g5$1@saria.nerim.net>
In reply to#3062
Mike Spencer a écrit :
> 
> IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
> labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
> into one of those (suitable cable and power adapter) results in the
> SATA drive being seen by Linux as hda. (?!)

hd* vs sd* naming has nothing to do with the hardware but with the
IDE/ATA driver used for the disk adapter. Old IDE drivers use the IDE
naming hd*, even for SATA drives. Newer ATA drivers based on libata use
the SCSI naming sd* with both SATA and IDE drives.

> Using SLackware 11 with 2.4.33 kernel.  A (much) newer kernel might
> very well fix it.

Yes. 2.4 kernels are very old. I dropped them a long time ago even for
machines older than a Pentium 4. You should at least try a 2.6 kernel
with libata drivers. I think that IDE drivers have not been actively
maintained for a while.

[toc] | [prev] | [next] | [standalone]


#3075

From"Carlos E.R." <robin_listas@invalid.es>
Date2016-05-24 21:52 +0200
Message-ID<41oe1d-dje.ln1@Telcontar.valinor>
In reply to#3062
On 2016-05-20 01:23, Mike Spencer wrote:
> This probably isn't a hardware matter per se but maybe a hardware
> wizard here will have a solution.
> 
> IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
> labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
> into one of those (suitable cable and power adapter) results in the
> SATA drive being seen by Linux as hda. (?!) It works just fine in
> every respect except one:
> 
> Large writes to the HD, e.g. cp bigfile-from-foo /dir/on/HD, runs as
> expected for a few seconds, then the system bogs down.  X cursor gets
> jerky, key strokes may take a minute to elicit visible response.
> Copy proceeds at an acceptable speed but the box is unusable until the
> copy is finished and sync'd.

This is typical on Linux. The write to file is cached in RAM while there
is free RAM, then it slows down as the media is not capable of writing
down that lot. And, as there is no more free RAM, the rest of the
processes slow down considerably. The slowest the destination media is,
and the fastest the originating media is, the worst the issue is. Ie, if
the destination is on USB, issue is bad. If it is to a USB stick it is
worst.

There are some tweeks you can do if the copy uses "dd", telling it to
not cache the write. Try "oflag=direct" or "nocache".

Some machines and kernel combinations are worst than others.


You can check the write speed of the disk with "hdparm -tT /dev/device".

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#3106

FromMike Spencer <mds@bogus.nodomain.nowhere>
Date2016-05-28 04:07 -0300
Message-ID<87inxy8xtd.fsf@bogus.nodomain.nowhere>
In reply to#3075
"Carlos E.R." <robin_listas@invalid.es> writes:

> On 2016-05-20 01:23, Mike Spencer wrote:
>
>> This probably isn't a hardware matter per se but maybe a hardware
>> wizard here will have a solution.
>> 
>> IBM P4 desktop came with an IDE HD.  HD failed.  Mobo has two plugs
>> labeled "SATA IDE n" where n is "1" and "2".  Plugging a SATA drive
>> into one of those (suitable cable and power adapter) results in the
>> SATA drive being seen by Linux as hda. (?!) It works just fine in
>> every respect except one:
>> 
>> Large writes to the HD, e.g. cp bigfile-from-foo /dir/on/HD, runs as
>> expected for a few seconds, then the system bogs down.  X cursor gets
>> jerky, key strokes may take a minute to elicit visible response.
>> Copy proceeds at an acceptable speed but the box is unusable until the
>> copy is finished and sync'd.
> 
> This is typical on Linux. The write to file is cached in RAM while there
> is free RAM, then it slows down as the media is not capable of writing
> down that lot. And, as there is no more free RAM, the rest of the
> processes slow down considerably. The slowest the destination media is,
> and the fastest the originating media is, the worst the issue is. Ie, if
> the destination is on USB, issue is bad. If it is to a USB stick it is
> worst.

That doesn't appear to nail my problem.

I just finished a series of big copies -- 700M to 2G -- (a) from my HD
to and external IDE HD connected by USB adapter, (b) from another external
IDE HD to a USB stick and (c) from the USB stick to the first external HD.
None of these copies caused the problem.  The bogging down only occurs
during writes to the main SATA HD connected to the "SATA IDE" plug on
the mobo.

> There are some tweeks you can do if the copy uses "dd", telling it to
> not cache the write. Try "oflag=direct" or "nocache".

I'll think about that.

> Some machines and kernel combinations are worst than others.

I cinfess to an old kernel.  The IBM P4 has otherwise done everything
as expected.

> You can check the write speed of the disk with "hdparm -tT /dev/device".

Okay, another crevice to peer into.  I'll have a look, tnx.


-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]


#3108

FromHenrik Carlqvist <Henrik.Carlqvist@deadspam.com>
Date2016-05-28 11:09 +0000
Message-ID<nibu9f$eis$1@dont-email.me>
In reply to#3106
On Sat, 28 May 2016 04:07:58 -0300, Mike Spencer wrote:
> The bogging down only occurs during writes to the main SATA HD
> connected to the "SATA IDE" plug on the mobo.

My guess is that your bad performance is explained by lack of DMA. You 
could verify that guess by studying the output of

hdparm -i /dev/hda

You will probably get better performance with DMA if you instead use your 
SATA drive in SATA mode. That could probably be accomplished by changing 
some setting in your CMOS setup. My guess is that you now have a setting 
which might be named something like "legacy" or "IDE" when you instead 
shoule have a setting named something like "SATA" or "AHCI".

Once that setting is changed your kernel might instead see your drive as 
/dev/sda instead of /dev/hda. As such you might have to reconfigure your 
/etc/fstab and/or your bootloader.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[toc] | [prev] | [next] | [standalone]


#3113

From"Carlos E.R." <robin_listas@invalid.es>
Date2016-05-28 17:12 +0200
Message-ID<43po1d-jit.ln1@Telcontar.valinor>
In reply to#3108
On 2016-05-28 13:09, Henrik Carlqvist wrote:
> On Sat, 28 May 2016 04:07:58 -0300, Mike Spencer wrote:
>> The bogging down only occurs during writes to the main SATA HD
>> connected to the "SATA IDE" plug on the mobo.
> 
> My guess is that your bad performance is explained by lack of DMA. You 
> could verify that guess by studying the output of
> 
> hdparm -i /dev/hda
> 
> You will probably get better performance with DMA if you instead use your 
> SATA drive in SATA mode. That could probably be accomplished by changing 
> some setting in your CMOS setup. My guess is that you now have a setting 
> which might be named something like "legacy" or "IDE" when you instead 
> shoule have a setting named something like "SATA" or "AHCI".
> 
> Once that setting is changed your kernel might instead see your drive as 
> /dev/sda instead of /dev/hda. As such you might have to reconfigure your 
> /etc/fstab and/or your bootloader.

Good points, worth checking.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#3121

FromMike Spencer <mds@bogus.nodomain.nowhere>
Date2016-05-29 01:50 -0300
Message-ID<87vb1xii2i.fsf@bogus.nodomain.nowhere>
In reply to#3108
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

> On Sat, 28 May 2016 04:07:58 -0300, Mike Spencer wrote:
>
>> The bogging down only occurs during writes to the main SATA HD
>> connected to the "SATA IDE" plug on the mobo.
> 
> My guess is that your bad performance is explained by lack of DMA. You 
> could verify that guess by studying the output of
> 
> hdparm -i /dev/hda

Okay. HD details are getting kinda above my pay grade but I'll see
what I can puzzle out. 

> You will probably get better performance with DMA if you instead use your 
> SATA drive in SATA mode. That could probably be accomplished by changing 
> some setting in your CMOS setup. My guess is that you now have a setting 
> which might be named something like "legacy" or "IDE" when you instead 
> shoule have a setting named something like "SATA" or "AHCI".

I'll look for that, too.  I don't recall ever seeing anything like
that but I may have forgotten or ignored it.

> Once that setting is changed your kernel might instead see your drive as 
> /dev/sda instead of /dev/hda. As such you might have to reconfigure your 
> /etc/fstab and/or your bootloader.

Yes.  Lilo's been told MBR->hda3 and fstab is about hda partitions.

We have a week or maybe a fortnight just now to get all our vegetable
gardens in so it's taking priority.  Bit of extra bother keeping the
rabbits & porcupines away from the veggies with assorted ad hoc fencing.


Tnx,
-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]


#3126

FromANTant@zimage.com (Ant)
Date2016-05-29 11:41 -0500
Message-ID<o7CdnZojII8ihtbKnZ2dnUU7-N-dnZ2d@earthlink.com>
In reply to#3121
Mike Spencer <mds@bogus.nodomain.nowhere> wrote:

> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

> > On Sat, 28 May 2016 04:07:58 -0300, Mike Spencer wrote:
> >
> >> The bogging down only occurs during writes to the main SATA HD
> >> connected to the "SATA IDE" plug on the mobo.
> > 
> > My guess is that your bad performance is explained by lack of DMA. You 
> > could verify that guess by studying the output of
> > 
> > hdparm -i /dev/hda

> Okay. HD details are getting kinda above my pay grade but I'll see
> what I can puzzle out. 

Copy and paste it for us? We'll help you. ;)
-- 
Quote of the Week: "Remember, ants are only waiting for you to die..." --unknown
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
  /\___/\   Ant(Dude) @ http://antfarm.home.dhs.org (Personal Web Site)
 / /\ /\ \                 Ant's Quality Foraged Links: http://aqfl.net
| |o   o| |
   \ _ /    Please nuke ANT if replying by e-mail privately. If credit-
    ( )     ing, then please kindly use Ant nickname and AQFL URL/link.

[toc] | [prev] | [next] | [standalone]


#3123

FromMike Spencer <mds@bogus.nodomain.nowhere>
Date2016-05-29 02:41 -0300
Message-ID<87r3clifod.fsf@bogus.nodomain.nowhere>
In reply to#3108
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

> On Sat, 28 May 2016 04:07:58 -0300, Mike Spencer wrote:
>
>> The bogging down only occurs during writes to the main SATA HD
>> connected to the "SATA IDE" plug on the mobo.
> 
> My guess is that your bad performance is explained by lack of DMA. You 
> could verify that guess by studying the output of
> 
> hdparm -i /dev/hda

Here's the output from hdparm -I (-I is allegedly more readable and
informative than -i) and hdparm -i.  I don't know what most of it
means without a lot of reading.

Comments welcome if anything jumps out at you as possible source of
the problem.

The CMOS check will have to wait a bit yet.

TIA,
- Mike


--- BEGIN hdparm -I output ---

root# hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media
    Model Number:       ST3160815AS
    Serial Number:      9RX1XL9X
    Firmware Revision:  3.ADA
Standards:
    Supported: 7 6 5 4
    Likely used: 7
Configuration:
    Logical     max current
    cylinders   16383   65535
    heads       16  1
    sectors/track   63  63
    --
    CHS current addressable sectors:    4128705
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors:  312500000
    device size with M = 1024*1024:      152587 MBytes
    device size with M = 1000*1000:      160000 MBytes (160 GB)
Capabilities:
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, no device specific minimum
    R/W multiple sector transfer: Max = 16  Current = 16
    Recommended acoustic management value: 208, current value: 0
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
    Enabled Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
       *    Write cache
       *    Look-ahead
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    DOWNLOAD_MICROCODE
            SET_MAX security extension
           Automatic Acoustic Management feature set
       *    48-bit Address feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
       *    General Purpose Logging feature set
       *    SATA-I signaling speed (1.5Gb/s)
       *    SATA-II signaling speed (3.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Phy event counters
       *    Software settings preservation
Security:
    Master password revision code = 65534
        supported
    not enabled
    not locked
        frozen
    not expired: security count
    not supported: enhanced erase
Checksum: correct

--- END hdparm -I output ---

--- BEGIN hdparm -i output ---

 root# hdparm -i /dev/hda

/dev/hda:

 Model=ST3160815AS, FwRev=3.ADA, SerialNo=9RX1XL9X
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI\
-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

--- END hdparm -i output ---

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]


#3125

From"Carlos E.R." <robin_listas@invalid.es>
Date2016-05-29 14:06 +0200
Message-ID<fj2r1d-n2m.ln1@Telcontar.valinor>
In reply to#3123
On 2016-05-29 07:41, Mike Spencer wrote:

> Capabilities:
>     LBA, IORDY(can be disabled)
>     Queue depth: 32
>     Standby timer values: spec'd by Standard, no device specific minimum
>     R/W multiple sector transfer: Max = 16  Current = 16
>     Recommended acoustic management value: 208, current value: 0
>     DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
>          Cycle time: min=120ns recommended=120ns

You are using "udma5", it seems.
My SATA drives use "udma6", but my kernel is way more recent, too.

I have a pentium IV machine running, with an IDE PATA drive. It uses
udma5, with a recent kernel. I'll post most relevant output so that you
can compare.

Capabilities:
        LBA, IORDY(can be disabled)
        Standby timer values: spec'd by Vendor, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: 254
        Recommended acoustic management value: 128, current value: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                Power-Up In Standby feature set
           *    SET_FEATURES required to spinup after power up
                Address Offset Reserved Area Boot
                SET_MAX security extension
                Automatic Acoustic Management feature set
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD


Speed test (busy machine):

AmonLanc:~ # hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   790 MB in  2.00 seconds = 394.57 MB/sec
 Timing buffered disk reads: 132 MB in  3.00 seconds =  43.93 MB/sec
AmonLanc:~ #


As you can see, PATA is slow, compared to SATA (44 MB/S)


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#3127

FromANTant@zimage.com (Ant)
Date2016-05-29 11:42 -0500
Message-ID<o7CdnZUjII94htbKnZ2dnUU7-N-dnZ2d@earthlink.com>
In reply to#3125
Carlos E.R. <robin_listas@invalid.es> wrote:
> On 2016-05-29 07:41, Mike Spencer wrote:

> > Capabilities:
> >     LBA, IORDY(can be disabled)
> >     Queue depth: 32
> >     Standby timer values: spec'd by Standard, no device specific minimum
> >     R/W multiple sector transfer: Max = 16  Current = 16
> >     Recommended acoustic management value: 208, current value: 0
> >     DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
> >          Cycle time: min=120ns recommended=120ns

> You are using "udma5", it seems.
> My SATA drives use "udma6", but my kernel is way more recent, too.

> I have a pentium IV machine running, with an IDE PATA drive. It uses
> udma5, with a recent kernel. I'll post most relevant output so that you
> can compare.

> Capabilities:
>         LBA, IORDY(can be disabled)
>         Standby timer values: spec'd by Vendor, no device specific minimum
>         R/W multiple sector transfer: Max = 16  Current = 16
>         Advanced power management level: 254
>         Recommended acoustic management value: 128, current value: 254
>         DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>              Cycle time: min=120ns recommended=120ns
>         PIO: pio0 pio1 pio2 pio3 pio4
>              Cycle time: no flow control=240ns  IORDY flow control=120ns
> Commands/features:
>         Enabled Supported:
>            *    SMART feature set
>                 Security Mode feature set
>            *    Power Management feature set
>            *    Write cache
>            *    Look-ahead
>            *    Host Protected Area feature set
>            *    WRITE_BUFFER command
>            *    READ_BUFFER command
>            *    NOP cmd
>            *    DOWNLOAD_MICROCODE
>            *    Advanced Power Management feature set
>                 Power-Up In Standby feature set
>            *    SET_FEATURES required to spinup after power up
>                 Address Offset Reserved Area Boot
>                 SET_MAX security extension
>                 Automatic Acoustic Management feature set
>            *    48-bit Address feature set
>            *    Device Configuration Overlay feature set
>            *    Mandatory FLUSH_CACHE
>            *    FLUSH_CACHE_EXT
>            *    SMART error logging
>            *    SMART self-test
>            *    General Purpose Logging feature set
>            *    WRITE_{DMA|MULTIPLE}_FUA_EXT
>            *    64-bit World wide name
>            *    IDLE_IMMEDIATE with UNLOAD


> Speed test (busy machine):

> AmonLanc:~ # hdparm -tT /dev/sda

> /dev/sda:
>  Timing cached reads:   790 MB in  2.00 seconds = 394.57 MB/sec
>  Timing buffered disk reads: 132 MB in  3.00 seconds =  43.93 MB/sec
> AmonLanc:~ #


> As you can see, PATA is slow, compared to SATA (44 MB/S)

Yep, PATA is older than SATA. IIRC, PATA is basically IDE?
-- 
Quote of the Week: "Remember, ants are only waiting for you to die..." --unknown
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
  /\___/\   Ant(Dude) @ http://antfarm.home.dhs.org (Personal Web Site)
 / /\ /\ \                 Ant's Quality Foraged Links: http://aqfl.net
| |o   o| |
   \ _ /    Please nuke ANT if replying by e-mail privately. If credit-
    ( )     ing, then please kindly use Ant nickname and AQFL URL/link.

[toc] | [prev] | [next] | [standalone]


#3128

From"Carlos E.R." <robin_listas@invalid.es>
Date2016-05-29 21:09 +0200
Message-ID<hcrr1d-8lj.ln1@Telcontar.valinor>
In reply to#3127
On 2016-05-29 18:42, Ant wrote:
> Carlos E.R. <robin_listas@invalid.es> wrote:


> Yep, PATA is older than SATA. IIRC, PATA is basically IDE?

Yes, exactly.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#3129

FromAragorn <thorongil@telenet.be.invalid>
Date2016-05-30 10:57 +0200
Message-ID<nigvac$aqo$1@dont-email.me>
In reply to#3128
On Sunday 29 May 2016 21:09, Carlos E.R. conveyed the following to 
comp.os.linux.hardware...

> On 2016-05-29 18:42, Ant wrote:
>> Carlos E.R. <robin_listas@invalid.es> wrote:
> 
> 
>> Yep, PATA is older than SATA. IIRC, PATA is basically IDE?
> 
> Yes, exactly.

The term IDE has basically been misused all along.  SATA, SCSI and SAS 
devices are all IDE devices as well.  IDE stands for "Integrated Drive 
Electronics", which is pretty much the case with all modern storage 
devices. ;)

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]


#3130

From"Carlos E.R." <robin_listas@invalid.es>
Date2016-05-30 14:21 +0200
Message-ID<jqnt1d-f1c.ln1@Telcontar.valinor>
In reply to#3129
On 2016-05-30 10:57, Aragorn wrote:
> On Sunday 29 May 2016 21:09, Carlos E.R. conveyed the following to 
> comp.os.linux.hardware...
>> On 2016-05-29 18:42, Ant wrote:
>>
>>
>>> Yep, PATA is older than SATA. IIRC, PATA is basically IDE?
>>
>> Yes, exactly.
> 
> The term IDE has basically been misused all along.  SATA, SCSI and SAS 
> devices are all IDE devices as well.  IDE stands for "Integrated Drive 
> Electronics", which is pretty much the case with all modern storage 
> devices. ;)

You are right. However, the expression "IDE hard disk" exists, referring
to what some name "PATA", in contrast to "SATA". You can find it in many
wikipedia articles, although I didn't locate one describing it. Well,
this one:

https://en.wikipedia.org/wiki/Parallel_ATA

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]


#3131

FromAragorn <thorongil@telenet.be.invalid>
Date2016-05-30 15:49 +0200
Message-ID<nihgdb$4qm$1@dont-email.me>
In reply to#3130
On Monday 30 May 2016 14:21, Carlos E.R. conveyed the following to 
comp.os.linux.hardware...

> On 2016-05-30 10:57, Aragorn wrote:
>
>> On Sunday 29 May 2016 21:09, Carlos E.R. conveyed the following to
>> comp.os.linux.hardware...
>>
>>> On 2016-05-29 18:42, Ant wrote:
>>>
>>>> Yep, PATA is older than SATA. IIRC, PATA is basically IDE?
>>>
>>> Yes, exactly.
>> 
>> The term IDE has basically been misused all along.  SATA, SCSI and
>> SAS devices are all IDE devices as well.  IDE stands for "Integrated
>> Drive Electronics", which is pretty much the case with all modern
>> storage devices. ;)
> 
> You are right. However, the expression "IDE hard disk" exists,
> referring to what some name "PATA", in contrast to "SATA". You can
> find it in many wikipedia articles, although I didn't locate one
> describing it. Well, this one:
> 
> https://en.wikipedia.org/wiki/Parallel_ATA

That's why I said it has been misused all along.  People have for years 
already been using it to refer to PATA devices, as if SATA devices 
suddenly wouldn't be IDE devices anymore. ;)

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [standalone]


Back to top | Article view | comp.os.linux.hardware


csiph-web