cdrecord: DMA speed too slow

[scdbackup@gmx.net]

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