cdrecord: DMA speed too slow
With cdrtools-2.01a33, i had the following incident when blanking a CD-RW.
I did not yet experience it with newly compiled 2.01a35. But it isn't
reproducible with a33, either.
Joerg, i would appreciate any test proposals.
Command was :
cdrecord -v blank=all speed=12 dev=0,0,0
Output of cdrecord :
...
Drive DMA Speed: 1734 kB/s 9x CD 1x DVD
cdrecord: DMA speed too slow. Cannot write at speed 10.
cdrecord: Max DMA data speed is 5.
cdrecord: Try to use 'driveropts=burnfree'.
After that, cdrecord ended without further message.
("speed 10" is ok. The drive does only 10x with CD-RW.)
I checked messages of earlier runs. They look rather like :
Drive DMA Speed: 4480 kB/s 25x CD 3x DVD
So i retried with the same media and blanking worked fine (still speed=12).
Drive DMA Speed: 4373 kB/s 24x CD 3x DVD
I then wrote data to the disk (with driveropts=burnfree as usual, speed=12) :
Drive DMA Speed: 4261 kB/s 24x CD 3x DVD
Those kB/s numbers are not very stable, although one can have quite straight
sequences : ... 4439 4480 4467 4470 4476 4480 4476 4473 4476 4464 4464 ...
(This impression did not change when i switched from a33 to a35.)
Generally the measurement seems to yield results which are lower than the
drive's real capabilities :
The drive burns 4.7e9 random bytes to DVD+RW via growisofs in about 930
seconds. That's a throughput of at least 4900 kB/s (minus pre- and post-burn
activities, i'd rather say 5100 kB/s). Read speed is >= 7500 kB/s.
It initially had strange moments of slowliness with growisofs but this
effect has vanished meanwhile.
Most time i do blank=fast and when writing data i use driveropts=burnfree.
I mostly used 4x CD-RWs where that low speed would have been ok, i guess.
So i do not really know how often those low DMA values got measured in the
weeks when i used 2.01a33. But i verify every CD and would have noticed if
any (of 79 on this writer) wasn't burnt sucessfully.
I assume that cdrecord is not to blame for the low DMA speed measurement.
Maybe the kernel's time handling is messed up, or the system really had a
short moment of mental absence.
But given its instability - is it possible to reduce the influence of that
measurement ? I would have a legacy problem if blanking needed
driveropts=burnfree in order to work reliably.
How about warning rather than aborting ? Or to wait a few seconds and then
redo the measurement rather than aborting on first try ?
Environment :
$ uname -a
Linux ... 2.4.21-215-athlon ... i686 athlon i386 GNU/Linux
$ hdparm /dev/hdc
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
BLKRAGET failed: Invalid argument
HDIO_GETGEO failed: Invalid argument
The writer is a LG DVDRAM GSA-4082B under ide-scsi emulation, media is
"4x-12x Platinum" CD-RW. (growisofs was used via /dev/sr0 and ide-scsi.)
The CPU runs at 1900 MHz, mostly idle. There is plenty of free RAM.
No media in /dev/hdd (a DVD ROM).
Room temperature is 26 Celsius. Disks leaving the drive are luke warm.
Have a nice day :)
Thomas
Reply to: