faulty CDROMs

[markw at mohawksoft.com]

> Date: Tue, 25 Jan 2005 18:40:27 -0500
> From: David Hummel <dhml at comcast.net>
> Subject: Re: faulty CDROMs
> To: discuss at blu.org
> Message-ID: <20050125234027.GA14332 at localhost.localdomain>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jan 25, 2005 at 01:30:16PM -0500, markw at mohawksoft.com wrote:
>>
>> > Date: Tue, 25 Jan 2005 8:00:09 -0500
>> > From: <gbburkhardt at verizon.net>
>> > Subject: faulty CDROMs
>> > To: <discuss at blu.org>
>> >
>> > I've been having trouble with burning CDROMs; every so often, I
>> > can't read a file from a CDROM I've created.  This is especially
>> > annoying when working with an ISO image from a distribution.
>> >
>> > Does anyone have any general rules of thumb on how to increase the
>> > yield?
>>
>> Check to see if the hard disk on which the image is stored is on the
>> same
>> IDE chain as the CD burner. This can sometimes cause problems as IDE is
>> CRAP at sharing IDE channels.
>
> Sharing the channel might be slower, but not any less reliable.  That
> is, you should still be able to burn CDs no problem.  Use the Buffer
> Underrun Free feature of your burner if supported (driveropts=burnfree
> option in cdrecord), or decrease the burn speed.  If you're still
> getting failures/coasters, then your problem is deeper (perhaps
> DMA-related).

It is the "slowness" that can cause issues. When the IDE channel switches
devices, there is sometimes a delay that slows down the data rate, even in
fairly fast systems. This delay, reading from the hard disk, then wrting
to the CDROM can be pretty bad if you are reading/writing small chunks.

If you are sharing a channel with the CDROM, your maximum data rate is
really low. CDRW are typically slower than hard disks. So, the amount of
time it takes to read the data off the hard disk, the amount of time it
takes to switch devices on the chain, the amount of time it takes to write
to the CDROM.

So, theoretical data rate reduced to half, because you are reading and
writing from the same channel. Inefficient device sharing on the IDE chain
reduce the data rate even more. And lastly, an asymetry in device data
rate reduces the data rate even more because the hard disk is waiting for
the slower cdrom.

It can get so slow, that a fast cdwriter can easily run out of buffered
data to write.

>
>> Check to see if the cable which connects the CD burner to the IDE
>> controller is an 80 pin grounded IDE cable or a 40 pin old fashioned
>> IDE cable.
>> *ALL* 40 pin IDE cables should be removed from ALL IDE devices. The 80
>> pin cables really are much better.
>
> An 80-conductor cable will make little or no difference performance-wise
> for many CD drives and other devices that are ATAPI-4 or less.  Perhaps
> a slight difference if operating at Ultra DMA mode 2.  You definitely
> want the 80-conductor type if the channel is shared with a fast
> harddrive (required for ATAPI-5 and higher).  It's certainly not going
> to hurt in any case.

The biggest problem with IDE is that there is no error
correction/detection. An 80 pin cable may not improve "performance," but
it will improve noise immunity in the IDE chain.

As described by the origial poster, he is having difficulty burning
reliably. This can easily be explained as electrical noise.

The 80-pin cable is a good idea no matter what, and I have seen a number
of times where a 40 pin cable exhibits obscure failures. Unable to boot
off a CDROM, occasional corruption on a CDRW, and occasional misreading
files. Simply replacing the cable can make these go away if you have an
electrally noisy system.