ATAPI CD-R lags system to hell burning in DAO mode; but not in TAO

I've got a Teac CD-W524E 24x CD-R writer, and ever since I got it several months ago I have had the somewhat annoying issue that burning a cd Disc-At-Once makes the system unusable during the burn. The X cursor jerks, repaints take forever, etc. This problem doesn't occur when burning Track-At-Once - I'm unable to notice any significant increase in system latency when using that mode.

The burner is the only IDE device in the system, and it is the primary master on the primary IDE controller, which is a SiS 5513. It's in UDMA2 mode. I'm using ide-scsi emulation, of course. All 2.4 kernels that I have tried exhibit this problem, including 2.4.17 and 2.4.18-ac3. It does not matter whether I burn with cdrdao or with cdrecord -dao - both lag the system like crazy. I noticed that turning on 32-bit I/O with hdparm helps immensely. This reduces the lag significantly. Setting unmaskirq seems to help a lot too. However, I'm still not satisfied. In particular, burning over NFS in DAO mode is not practical (the data rate simply can't be sustained), even though I can burn TAO CDs fine over NFS.

My friend has a Plextor PX-W2410A burner with similar specifications, and it has the same symptoms as I do. I believe he has a VIA IDE chipset.

I'd like to know if there's a workaround for the problem, and if not, what tools and/or methods I can use to track down the source of the noninteractivity so that a kernel hacker can fix it. The machine has half a gigabyte of RAM, never swaps, and reports 2916.35 bogomips. I think it should be able to burn CDs without too much sweat.

This is presumably because the machine is full of memory which is dirty against a slooow device.

You can work around this by reducing the dirty memory thresholds:

akpm-1:/home/akpm> cat /proc/sys/vm/bdflush
30 64 64 256 30000 3000 60 0 0

Make the "30" and "60" smaller. 10 and 20 perhaps.

Better: change the application to fsync() the data every few megabytes, or open O_SYNC.

-

I don't seem to have sysctl support in my kernel right now, so I can't verify this until I reboot.

I did notice that both cdrdao and cdrdao set realtime scheduling priority. I thought this would surely answer everything, but burning as an unprivileged user causes the same interactvity (and NFS throughput) problems as before.

Hi Aaron :)

I have a Plextor 12/10/32 (just a bit newer) with a VIA chipset
on the mobo, and the only thing that is affected when burning DAO is X Window. I've made a little test: compiling three kernels 2.4.18 and playing the burned files while burning at 12x in DAO runs smoooooth. In fact, I haven't noticed the test finish since the performance was almost the same. But X freezes.

IMHO it's a problem of X, not kernel :?? FYI I have 512M of RAM
and a Duron 850 (over 1700-1800 bogomips).

Raúl

I've been having a similar problem, but in my case it's audio and other non-data CD writes like VCD that have this kind of slowdown problem. DAO vs. TAO doesn't matter in my case. IDE chipset is VIA 686b. The problem disappears if I plug the writer to onboard pdc20265, but burns on that are otherwise flaky.