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

[John]

a late, and pointless reply to Bryan's email. Sorry all :)

On Thu, 5 Jan 2006 02:00 am, Bryan J. Smith wrote:
> 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.

actually it WAS a bad VIA controller, and well known to be so...
eventually

> 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.

sorry, but i think that is oversimplifying it. Sure an ATA controller 
is not a dual-core 64 bit cpu. But its more complex than a dumb 
set of wires.

>  It's the Integrated Drive Electronics (IDE) of the device
> that's the "brains" of the operation.  

this contradicts your very next statement... :

> If the ATA controller 
> is improperly configured to channel DMA transfers to/from
> memory correctly, _that's_ why you get corruptions.

Thats right. Thats what VIAs drivers were doing wrong.

> 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.

yes exactly. i saw every piece of timing code completely rewritten
between one version of their driver and the next. One value one 
time, a different value the next... and both values correct?? 
More likely both were wrong.

> > 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.

VIA said that VIA wrote it. Sure they hoard their specifications.

They dont have to hoard their driver source code, its worthless.
its probably pre-processed, to turn their nice constants and 
macros into inline code, but, its still all rubbish in my opinion.

> > 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.

I'll look it up later. It was well known. I am talking about their 
windows drivers here, not linux. For a while, they had to run 
PIO on many devices, eg burners in particular i believe, or 
corruption would ensue. it was pathetic

> 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.

I would much rather rely on the information that Intel puts out
about their controllers, than VIA

> > 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'll have a look into this before i shoot my mouth off :)

> > 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.

So the hardware logic is proven. That doesnt mean that the retarded 
fools who write drivers for nvidia and VIA, and SiS, wont one day put out 
rubbish drivers that corrupt every byte that passes through them

> 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.

the *only* difference???!!!!! Well, if there was only one difference, 
and i could pick what i wanted it to be, that would probably be the 
one i'd choose.
Saying that is the "only" difference is like saying the only difference 
between good and bad, is that good is... ummm good... and bad is not.

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

why should i do that? i wouldnt trust VIA drivers on windows 
more than i would on linux. Even nvidia screwed things up on 
windows for a while.

> 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?

Why not just use an intel controller with drivers written by people
who know what the hell they are doing. Personally, i would trust
some 3ware controller, with an embedded OS less than I would 
an intel controller on linux. I thought you said these controllers
were stupid... why do they need an entire embedded OS when
theyre stuck on a card?

Plus, that would use up the bandwidth on one of my pci channels.

> 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.

i trust linux more than dodgy small-company firmware and proprietary 
embedded OSes. Im sure those cards did have their uses though,
but i dont think i would use one now, unless i had more $$ and more 
curiosity than i have at the moment :)

If device vendors cant get their ATA devices to work with an Intel 
controller, they will fix their device so it does, or tell intel where their
controller/driver software is deficient, and intel will fix the controller
or its driver

If LG finds their device doesnt work with a VIA controller, why would 
they care when VIA dont? VIA chips are not used by companies 
who demand reliability. Theyre used by ignorant consumers who 
have virus-ridden pcs that dont have an uptime of more than 
3 hours, and whose hard disks are re-formatted every 2 weeks.

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

ok. thats a bit of a bummer

> 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.

hmmkay, thats interesting

> > 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.

33? these drives are 66 now, cmon.

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

at 12x which is all these drives will burn normal media at, thats only 
15MB/sec, which is only 25% of the 66
BTW, i thought 66 MHz ATA bus was 16 bits wide so bandwidth 
should be 133 MB/sec, but this seems to not be the case. Pathetic.
I havent seen any 16x media her in australia, though i havent
looked too hard. Im happy with my LG now, and the 8x Verbatim disks
that it will burn at 12x

> > 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.

these things cant be running at 33MHz still

> > 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.

wellive been using the burner on its own channel too for quite a while
now and yes, it definitely does help. I just still cant quite understand 
why performance was so bad with 2 devices. I mean, obviously, as 
you have said, these buses just werent designed for 2 devices.
It should be a more widely known fact, if performance of 2 devices on
these buses is so poor.

But I refuse to believe these burners are slowing the bus down to 33 MHz
Sure, an old cdrom or dvd drive would, but im sure even the 
pioneer 106 was ATA66 Still, nothing will help a pioneer burn +R

sorry to be argumentative, especially from my position of relative 
ignorance hehehe :)

John