Re: 2.4: high system load with SG_IO on IDE-SCSI: PIO?

Re: 2.4: high system load with SG_IO on IDE-SCSI: PIO?

[Douglas Gilbert]

Matthias Andree wrote:
 > I have seen readcd ("sg driver 3.2.0") use 96% system time
 > for a readcd -c2scan on IDE-SCSI (ATAPI CD-ROM, Plextor
 > PX-4824TA 1.04, UDMA/33), Linux 2.4.19+SuSE patches
 > (k_athlon-2.4.19-167).
 >
 > ...
 > ioctl(3, 0x2285, 0xbfffec20)            = 0
 > ...
 >
 > The same application on a real SCSI-device with SCSI host
 > adaptor (aic7xxx FWIW) is way below 5% system CPU time.
 >
 > Might SG_IO use PIO on ATAPI CD-ROMs? If so, are there
 > patches to enable DMA? Is this at all possible with SG_IO?

 > I find 96% system load is way too high for modern hardware.
 > (Duron/700 that is, VIA 82C686a).

SG_IO is an ioctl in the sg driver that issues scsi commands
and waits for a response. The route from sg is through the
scsi mid level and via ide-scsi to the ide subsystem. Nothing
in the SG_IO ioctl interface addresses ATA DMA and PIO settings.
They can be changed via the hdparm ** command.

The experience from the early 2.4 series was that the ide
subsystem was too aggressive in its DMA settings for CD/DVD
burners. [My experience with scsi devices is that disks have
much better target implementations (i.e. more robust) than
CD/DVD devices and scanners.] Later versions of the 2.4 series
are a lot more conservative in their speed treatment of ATAPI
devices. The robustness comes at the expense of system load.


** Even though a CD writer appears as /dev/scd0 with ide-scsi
appropriately configured, the hdparm command can still be used
on /dev/hdd (for example, if the writer is the slave on the
second IDE bus).

Doug Gilbert

Re: 2.4: high system load with SG_IO on IDE-SCSI: PIO?

[Matthias Andree]

On Mon, 10 Mar 2003, Douglas Gilbert wrote:

> The experience from the early 2.4 series was that the ide
> subsystem was too aggressive in its DMA settings for CD/DVD
> burners. [My experience with scsi devices is that disks have
> much better target implementations (i.e. more robust) than
> CD/DVD devices and scanners.] Later versions of the 2.4 series

ATAPI scanners? Cool stuff. Seriously, there is cheap ATAPI junk and
there is serious stuff.

> are a lot more conservative in their speed treatment of ATAPI
> devices. The robustness comes at the expense of system load.

Well, some amount of configurability would be nice for the ones of us
who have working ATAPI hardware. Even if it's a boot-time parameter like
"hdc=atapidma" or something (that's what FreeBSD does, with the
boot-time variable hw.ata.atapi_dma, it defaults to 0 but drop
hw.ata.atapi_dma="1" into /boot/loader.conf.local and have the machine
talk DMA to ATAPI stuff). Am I missing such an option?

I am currently facing the choice "switch to some other OS that talks DMA
to my CD-writer" or "buy an ATAPI-SCSI-converter" (which is above 100
EUR). I'd like to have a third option to choose, tell the kernel "forget
your sorrows and talk DMA." -- it could use a (user-space) whitelist,
say "Plextor CD-R   4824TA 1.04 is fine".

> ** Even though a CD writer appears as /dev/scd0 with ide-scsi
> appropriately configured, the hdparm command can still be used
> on /dev/hdd (for example, if the writer is the slave on the
> second IDE bus).

/sbin/hdparm -X66 -d1 -u1 happens at boot time (for hdc) -- still I'm
facing unreasonably high system load when writing a CD.

-- 
Matthias Andree

2.4: high system load with SG_IO on IDE-SCSI: PIO?

[Matthias Andree]

Hi,

I have seen readcd ("sg driver 3.2.0") use 96% system time for a readcd
-c2scan on IDE-SCSI (ATAPI CD-ROM, Plextor PX-4824TA 1.04, UDMA/33),
Linux 2.4.19+SuSE patches (k_athlon-2.4.19-167).

...
ioctl(3, 0x2285, 0xbfffec20)            = 0
...

The same application on a real SCSI-device with SCSI host adaptor
(aic7xxx FWIW) is way below 5% system CPU time.

Might SG_IO use PIO on ATAPI CD-ROMs? If so, are there patches to enable
DMA? Is this at all possible with SG_IO?

I find 96% system load is way too high for modern hardware. (Duron/700
that is, VIA 82C686a).

Thanks in advance,

-- 
Matthias Andree