[Dvdrtools-users] ATA, IDE, device, controller and other concepts -- WAS: Is my MSI DR8-A2 broken?

[Bryan J. Smith]

John <address@hidden> wrote:
> As far as having a master and slave both using DMA on the
> same IDE bus... my opinion (without having read ATA specs)
> is that it *SHOULD* not be dangerous.

It has nothing to do with "dangerous," it has to do with the
fact that the 16-bit [PC/]Advanced Technology (AT) Attachment
(ATA) Direct Memory Access (DMA) transfer is an end-point to
memory operation.  Should there be more than one end-point,
this can cause issues.

ATA is merely just an extension of the Enhanced System Disk
Interface (ESDI), which was a single cable, _single_ RLL
drive, for the 16-bit PC/AT bus.  The "intelligence" was
integrated drive electronics (IDE) which allowed the CPU to
talk directly to the drive, instead of needed the extra
expensive of a disk controller and its logic.  This was all
Programmed I/O (PIO).

Must of this led to the standardization efforts of an
evolving ATA consoritum.  Even though they defined some DMA
modes, they had no error checking, and PIO was still
preferred.  The whole master/slave idea was, not
surprisingly, cooked up by Western Digital to double the
devices for ESDI.  It created the master/slave relationship,
and faster PIO modes including the most common mode 4
(16MBps).  This was, again, when everything was still PIO.

ATA UltraDMA modes changed everything.  Not only was the
signaling DDR, but more importantly, a CRC check was added. 
That suddenly made ATA DMA viable since errors could be
caught, a major, prior issue with ATA versus SCSI and its
parity checking.  ATA, like ESDI before it, is still designed
for a _single_ end device -- and that really become important
when it comes to DMA.

Especially since there is no standardization to how devices
"act on a bus" like SCSI.  ATA is _not_ SCSI.  Whatever drive
takes control of the ATA channel, that drive defines what the
ATA channel does.  The whole master/slave is rather
arbitrary, and there is _no_ enforcement to who has priority.
 It's not SCSI where you have a pre-emptive, all-controlling
host adapter controller.  The ATA channel controller, other
than a few registers and bus abritration logic, is rather
"dumb."  It's the drive -- the IDE -- that controls the
channel.

> But, my brother has had horrific disk corruption problems
> from a bad VIA ide controller, under linux.

It's not a "bad" ViA ATA controller per-se, but the fact that
some ATA drive vendors do _not_ follow the ATA specification,
and ViA hasn't been liberal with some of their specs.  That
prevents Linux ATA developers like Hendrick from being able
to read all the registers and set proper modes -- especially
for these problematic drives.

Remember, the ATA controller is a "dumb set of wires" --
literally a 16-bit PC/AT bus arbitrator of 40-pins.  Other
than some registers and signaling, it doesn't do much at all.
 It's the Integrated Drive Electronics (IDE) of the device
that's the "brains" of the operation.  If the ATA controller
is improperly configured to channel DMA transfers to/from
memory correctly, _that's_ why you get corruptions.

It's also why CPU- driven Programmed I/O (PIO) mode is so
much more reliable/stable.  Because the CPU is handling the
transfer, and can do various checking.

ViA also has a nasty habit of changing the ATA logic with
every new revision.  Intel used to be bad on this to in the
early ICH days, but they have stablized much like AMD, nVidia
and SiS.  Vendors who change their ATA logic regularly are
more likely to have "out of sync" Linux drivers.

> And we have pored through the ide driver code put out by
VIA
> and it is(or at least was) absolutely APALLING. Those VIA
guys
> couldnt code their way out of a nutsack.

*WHO* said ViA wrote it?  ViA has _horded_ their
specifications in the past, even when some of their engineers
have donated time.  This really came to a head when IBM
(which affected Western Digital / Hitachi drives too) had
some really non-compliant ATA command sets on their drives
circa 2000-2002.  It affected Intel and ViA.  Intel worked
with Hendrick and other ATA code writers, ViA horded
specifications.

> So, as with many of these things, it depends on hardware
> and software.  Some Nvidia Nforce controllers have also
> had BAD corruption issues

Like?  I can't testify to pre-kernel 2.4.23 or 2.6.5, but
_all_ nVidia ATA driver support in kernel 2.4.23+ (or
backported for distros like RHEL3) and 2.6.5+ seems to be
very, very reliable -- one of the best "out-of-the-box"
experience.

> (caused more by driver software than hardware, again, i
> believe)

Because it's the setup of the ATA channel -- remember, just a
"bus arbitrator" for what is virtually an (overclocked)
16-bit PC/AT bus -- is left to the OS to work with the IDE of
the drive.

> forcing users to run in PIO mode to avoid corruption when
they
> have 2 devices on the same ide bus.

PIO is PIO -- it's absolute.  Slow and CPU taxing, if avoids
the issue of an improperly negotiated DMA setup by the OS of
the ATA controller and the IDE of an ATA device.

> I believe ide corruption issues these days are more
> dependant on the ide controller and software than the hard
> disks/burners,

It has everything to do with the IDE of the device and how
well the OS knows to setup the ATA controller.  Remember, the
IDE controller is rather _dumb_.  Even the Advanced Host
Controller Interface (AHCI) is still a 100% _software_ drive
configuration.

There are many eccentric ATA implementations in IDE out there
-- I haven't seen a single drive vendor implement the ATA
specification to true spec.  And then there are newer specs,
some conflicting specs and -- worst of all -- Microsoft
violating some of those specs (e.g., not even NT5.1/XP, with
all its patches, supports newer ATA LBA48 geometry
correctly).

> though there is no doubt they could also cause the same
> issues if they dont behave properly. It would seem to be a
> simpler job to design one device that fits the ATA spec,
than
> it is to design an ide controller and write the drivers for
it.

Yes, so complain to the device vendors.

Until then, the ATA controllers can do little but share their
complete register settings so the OS can "tame" these
problematic devices.  Until then, the Linux ATA developers
have to "assume" the drives follow the spec, and use the
limited information they can on how to setup the ATA bus
properly with various controllers.

> After what my bro has been through i will only ever use a 
> decent intel ide controller.

Why?  Intel has had its huge share of issues too.  Especially
the ICH southbridges before ICH5.  That was a good _3_years_
of corruptions.

> I just wouldnt touch anything else.

All AMD chips use the same, proven, 4-year old AMD751 ATA
command set.

All nVidia MCP chips use the same, proven, 3-year old nForce2
logic.

All SiS chips, at least through the last year or two, use the
same, proven 4-year old SiS5513 ATA command set.

I wouldn't blindly and ignorantly say Intel is best, and I
have a long history to suggest they change stuff almost as
much as ViA.  The only difference is that they share their
info with the Linux ATA developers, while ViA has horded
specifications.

> Not when i am a slack bastard when it comes to backing up,
> life is too short to waste your time with computers that
> corrupt your work, which they can, and do...

If you're really concerned, take Linux out of the equation.

Instead of hoping for your vendor's end-device IDE
implemention to be to ATA spec, the ATA controller to be well
documented and know by the Linux ATA driver developers and,
most importantly, the Linux ATA driver to be feature complete
-- why not use a card that basically handles 100% of the ATA
on-board?

That's why many of us adopted 3Ware Escalade 6000, 7000 and,
later, 8000 products over 5 years ago for our hard drives in
production networks.  3Ware has its own, field programmable,
ATA controllers on-board, driven by its own, embedded OS, and
works with various ATA fixed disk vendors to ensure 100%
communication.  3Ware also uses only 1 device per channel,
per the specifications of ATA devices in DMA mode.

There is no worry if the Linux developers have all the specs
for not only the ATA controller but the IDE of the ATA device
and hope they work together under their driver.  That is all
moved into the firmware of the 3Ware card.  The 3Ware card
just provides the SCSI block interface to talk to its
on-board ASIC, because Linux _never_ talks directly to the
drives.

Of course, 3Ware cards are only for ATA fixed disks, not
ATAPI optical drives.  But they _do_ get rid of the ATA
issues that Linux will continue to have because vendors don't
follow the ATA specs and some ATA controller vendors don't
share their full specs so Linux can completely deal with
"problematic" ATA devices.

> Anyway as i understand it, the difference between a master
> and a slave is that the master can take control of the bus
> whenever it wants, and the slave has to release it within
> certain time limit or be forced off.

Just like the multitasking in Windows 3.1 gives up control of
the bus.  Trust me, it's that arbitrary.

SATA is *0* different from ATA at the logic level (only the
physical/datalink), and since SATA only does DMA, there is
_no_ option to use master/slave with SATA for a reason.  The
master/slave is for _legacy_ compatibility with things like
Western Digital's EIDE.

> Hence good for your burner to be master on on 1 IDE bus and
> the hard disk you burn from, to be master on the other bus
> -that way data can go into memory on one bus while it goes
out
> on the other.

Yep.  And that's why performance _sucks_ when they are on the
same channel.

ATA is _not_ SCSI.  There is _no_ device-to-device transfers.

[ FYI, the same is true of USB v. FireWire, if you didn't
know. ]

> i think the point Sven is making is that hda and hdb ARE on
> the same channel, and so are hdc and hdd. So hes asking 
> whats the difference between transferring between 2 hard
> disks and between a hard disk and a burner.

Little, except maybe signaling.

> I would say the answer is simply that you wont ever get a 
> coaster when transferring between 2 hard disks.

Yes, because recording is a real-time operation.

Furthermore, you want to _avoid_ kicking in burn-proof,
because you turn off the laser and where it restarts is
_never_ exact.  That's not ideal for compatibility or
longevity -- you want a single, long groove.

> The bandwidth of an ide bus *SHOULD* easily be large enough
> to burn from a hard disk on the same bus as the burner,

Not when the recorder device has "slowed down" the bus to
UltraDMA mode 2 (Ultra33), which most run at.  At 16x DVD-R,
you're talking ~20MBps -- that's well over _half_ the
channel's theoretical time!  In my experience, it's actually
close to 80% of the channels "realistic" transfer rate.

So you've got hardly _anything_ left in the time of the
channel for pulling from hard drive.

> It beats me why burning programs dont allocate more memory
> to buffer incoming data from the hard drives... it would
have
> to help.. everyone knows hard drive speed can drop
extremely
> low when reading large numbers of small files (or
fragments).

Doesn't matter if you buffer more in main memory if you're
entire ATA bus, running at Ultra33, is almost entirely tied
up with a 16x DVD-R transfer rate.

> I find this to be the biggest problem with burning dvds,
but LG
> drives seem to cope extremely well with buffer underruns,
so
> much less of a problem these days

I run my LG GSA-416x on its own ATA channel and _never_ have
an underrun.  And I turn burnproof _off_ for maximum
compatibility.  I haven't had an issue yet.



-- 
Bryan J. Smith     Professional, Technical Annoyance                      
address@hidden      http://thebs413.blogspot.com
----------------------------------------------------
*** Speed doesn't kill, difference in speed does ***