I didn't really know how to put it. Maybe system load would be better. But
the actual problem is, I effectively can't burn audio and other types
at 16x in Linux, while there is no problem in some other operating systems
with the same hardware and applications.
Here're some time figures from cdrdao:
cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu 6:41.86 total
cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s system 12% cpu 4:31.71 total
cdrdao simulate -n --speed 16 foo.cue 2.67s user 128.77s system 52% cpu 4:10.68 total
So yes, system time goes up quite steeply.
But even though 50% is quite high, CPU load is not the problem as such,
the problem is getting data to the writer fast enough. And it's not
happening. Even a single audio track that is completely cached so that
there is no HD access has problems. It's like somehow accessing the CD
writer hogs the system for such long periods that there is insufficient
time to fill the writing program's buffer.
One thing I noticed just now. If I turn off unmaskirq for the CD writer
with hdparm -u 0 /dev/hdc, it helps a little, but not enough. Time
reports now:
cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu
2:13.22 total
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/