[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Notes on CD Burning under Linux



Hi,

Some more news to cheer you up.
I've been playing a bit with CD-burners under Linux, and decided to
share some of the small problems I encountered during the process, as
well as the delightful bottom line.

1. Hardware: I tried two CDRs: Panasonic (Matsushita originally)
CW-7502, and Yamaha CR-100 (I believe that's the model name, but I'm not
quite sure). Both are SCSI CDRs capable of writing at up to x4 speed.
The CD reading device in both cases was a x32 Pioneer SCSI CD.
2. Software: I used the latest beta versions of cdrecord, mkisofs and
xcdroast.
3. Caveat emptor:
   a. Be sure to disable wide negotiation on the SCSi device dedicated
to the CDR (in the SCSI bios setup menu). This may (and indeed does)
cause detection problems. This procedure is not needed for SCSI CDs,
usually.
   b. The excentric Joerg Schilling, writer of cdrecord, preferred to
install it under /opt/schilly. Better move it to /usr/local.
   c. Xcdroast comes with its own version of cdrecord, but this lags
behind the latest cdrecord version. For me at least it made a
difference. I suggest installing cdrecord seperately, and linking it to
the file Xcdroast expects to find.
   d. Multisession and Bootable CD writing is already supported under
cdrecord, but Xcdroast (which is a front end to cdrecord, mkisofs and
some other related programs) doesn't yet reflect that functionality. I
didn't burn bootable CDs, but multisession burning seems to work just
fine. Read the cdrecord detailed man page.

4. Performance: I've had some sad experience with CD-burning under
Win95, and heard that the situation under NT is even worse. I therefore
was quite skeptical about the claims that under Linux you can burn a CD
and meanwhile work normally, not to mention ridiculous stories about
compiling a kernel while burning. From my poor experience it seemed
inevitable that under such conditions a buffer underrun will occur
during a prolonged burning session. 
Well, here are the facts:
I checked it under two machines:
1. A double Pentium 200 with 2 maxtor IDE disks, 24MB FPM RAM and an old
buslogic ISA SCSI controller.
2. An AMD K6-233, with UW fast SCSI controller and disk and 128MB SDRAM.

On the weaker machine I was able to compile a kernel while burnng a
music CD at double speed with no problems. From my experience, that
means it would probably be able to burn a data cd under the same load at
x4 speed, but I haven't checked it. When I increased the load, compiling
with the -j flag set to higher values, burning failed at loads around 5,
due to heavy swapping on the IDE disks (memory was exhausted).

On the stronger machine, burning data at x4 speed was not interrupted at
all, aven when I concommitantly compiled a kernel with a -j 8 flag,
which brought the load to around 8. However, since the machine didn't
exhaust its memory under these conditions, I decided to load it with
some more CPU and disk activity. I therefore added to that tarring and
gzipping of a 0.5GB directory tree. This indeed produced a lot of disk
activity, and even some memory swapping, bringing the load to around 10,
yet the burning continued uninterrupted. 
At that point I decided I must do something drastic. I decided I'll just
rob the machine of as much memory as I could. I therefore opened matlab
and created a matrix that takes several hundred megabytes (the machine
has around 0.8G swap space). This worked as expected, inducing frantic
swapping, and the load climbed to unprecedented 12, and yet the burning
showed no signs of giving up, and finished successfully. 

I find this experiment TOTALLY AMAZING, and I'm sure anyone with some
experience burning under MSxxx will agree on that.

Q.E.D. #2 for today.   ;-))

Tuvik

.

-- 
--------------------------------------------
               Tuvik Beker
      P.O. Box 571, Givatayim 53104
Tel. (972) 3 5714436    Fax. (972) 3 5334349
         becket@shum.huji.ac.il
--------------------------------------------