Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> 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.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |