Re: Low burning speed
DVD+R 16x info:
INQUIRY: [HL-DT-ST][DVDRAM GSA-4163B][A106]
GET [CURRENT] PERFORMANCE:
Write Performance: 7.2x1385=9913KB/s@0 -> 15.9x1385=22059KB/s@1871871
Wow! It "says" that it will gradually increase velocity, perhaps operate
at constant angular velocity? For reference. Zoning is determined mostly
by unit mechanics and has lesser to do with media. Indeed, in order to
provide some linear velocity disk has to be rotated faster closer to
center [where recording starts]. And there is limit for how fast given
motor can go. Zone boundaries reflects maximum motor spin at given
radius. I basically wanted to see zone boundaries (assuming that it
would be same for all media types in this unit), but it doesn't show...
Oh, well...
time test:
tomasz@debian:~$ time dd if=/dev/zero of=/dev/hdc bs=1M count=1000
1000+0 przeczytanych recordów
1000+0 zapisanych recordów
skopiowane 1048576000 bajtów (1,0 GB), 98,1632 sekund, 10,7 MB/s
As Thomas mentioned it's essentially 8x you see.
Pktcddvd not used, doesn't matter whether growiso is started as root
or user.
When started as root growisofs boosts its priority and instructs system
to pinpoint its memory (so that it's not swapped out).
I burned some data using cdrecord+xcdroast again, the average
speed was about 7.7 although it complained that dma is off. I checked it
with hdparm (of course it was on), then just in case "hdparm -X udma2"
and again time test, unfortunatelly no improvement.
It appears that your system "balances" somewhere at 8x. Or in other
words slightly less than 8x is what it can deliver to the unit. Whether
or not you actually get near 8x depends on combination of small factors
and growisofs (as well as cdrskin) apparently ends up just below the
level when unit if forced to take a lot of idle rotations and
performance drops a lot. As mentioned, it seems to be specific to
DVD+RW, but it's probably unit that requires a tad larger marginal for
its DVD+RW recording strategy. How come just growisofs? Probably the
fact that growisofs constrains itself to 32KB data transfers is one of
the small factors. I mean larger transfer chunks would allow performance
not to slip. But one way or another you don't want to "balance" on the
edge (small factors come and go, you stay) and should concentrate on
optimizing your system. Most likely it's kernel deficiency, so kernel
upgrade [or downgrade] might help, but make sure recording unit is on
dedicated IDE channel, double-check cabling... Meanwhile stick to
-speed=6 [for all recordings to ensure you're below the edge with
marginal]. A.
Reply to: