It used to be that DVD-burning was pretty straightforward under various distributions:
$ growisofs -dvd-compat -Z /dev/hdc=myvacation.isoMostly, all would go smoothly. However, hardware driver advances have been uneven, such as for drives and cables and I/0 ports, firmware, and the BIOS. A DVD drive might read OK, yet might encounter glitches when burning:
$ growisofs -dvd-compat -Z /dev/hdc=myvacation.iso Executing 'builtin_dd if=myvacation.iso of=/dev/sr0 obs=32k seek=0' :-[ PERFORM OPC failed with SK=3h/POWER CALIBRATION AREA ERROR]: Input/output error
A user could run a burn program (eg. Brasero) to overcome manual settings. However, the next problem is the DVD drive, which is supposed to burn at, say, 4-16x, is burning instead at about .5x. That would be something like 680 KbSec, if we agree 1x is supposed to be about 1.32 MB/Sec. This is annoying, to be sure. (Note: one good thing about Brasero, it seems a rare non-K3b burner which will do video, at least if configured properly.
Is the cable the problem, the DVD firmware... some other? The burner only working at 1/8 of its lowest burn speed is going to cause I/O problems and user delays. We could also test the burner's native capacity, as described here, to provide a rough view.
# hdparm -i /dev/sr0
Model=PIONEER DVD-RW DVR-108 , FwRev=1.18 , SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=13395, BuffSize=64kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4
AdvancedPM=no
Drive conforms to: Unspecified: ATA/ATAPI-2,3,4,5
* signifies the current active mode # hdparm -I /dev/sr0
ATAPI CD-ROM, with removable media
Model Number: PIONEER DVD-RW DVR-108
Serial Number: DKDC451400WL
Firmware Revision: 1.18
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
cache/buffer size = unknown
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 64.0kB
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* Power Management feature set
* PACKET command feature set
* DEVICE_RESET command
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Timing cached reads: 1234 MB in 2.00 seconds = 616.60 MB/sec
Timing buffered disk reads: 22 MB in 3.23 seconds = 6.82 MB/sec
Speed
With an advertised 12x reading speed, a speed of about 16 MB/sec, we see that the true, uncached read speed of 6.82 MB/sec is not coming close. And, as noted above, a write speed of about .682 MB/sec, is anywhere between 1/8 to 1/32 of the advertised 4x-16x write speed range. Hmm...DMA
The first two checks confirm UDMA (Ultra Direct Memory Access) is working, and that in fact UDMA4, one of the faster forms of UDMA, has been selected. It's also worth the reading the IDE ffile with $ cat /proc/ide/piix.
Cable
UDMA4 requires an 80 pin cable to transfer reliably at the 66 MB/Sec transfer rate. Apparently, avoiding capacitive interference is the issue for using the 80 pin over its 40 pin predecessor. I haven't opened the box, but it's unlikely that an 80 pin cable was used for this drive, since I simply cannibalized two drives from older systems when constructing the system. The 80 pin cables are more reliable as well as backwards-compatible to earlier drives. At any rate, I can note this as potentially a problem, but perhaps not a full explanation.
No comments:
Post a Comment