Re: Low burning speed
Hi, i have to amend my experiment proposal about 64 kB rather than 32 kB blocking factor. It turned out that libburn with DVD always used 32 kB in the past. So this would be untested and in worst case could lead to the need to reboot if the drive dislikes it heavily. Necessary changes would be : In libburn/os-linux.h : #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 In libburn/write.c this "32" would have to become "64" o->obs = 32*1024; /* buffer flush trigger for sector.c:get_sector() */ Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Hi, Andy Polyakov: > 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. My theory is slightly different. I would blame it on latency and not on throughput because Tomasz can write DVD-R or DVD+R with 8x and no obvious performance glitches. My idea is that the drive blocks on a WRITE10 from the SGIO driver for a very short while, when it misses the write position due to rotation frequency. Then it becomes ready to accept the next write, but SGIO does not react fast enough, so that again the write position is missed and again blocking occurs. This would give a decisive role to the very early speed performance switch from 6x to 8x. It would also explain why in the same LBA range nominal 6x works better than nominal 8x. One could try to verify that idea by making a small pause at about 2 GB, wait for everything to calm down, and then resume writing. In my theory, after the pause there would be full 8x throughput, because then latency would be less critical due to higher sector frequency at the outer rim of the media. The pause would be made to break the bad rythm of blocking and resuming the WRITE commands. > How come just growisofs? Probably the fact that growisofs > constrains itself to 32KB data transfers libburn once used 64 kB but a year ago i switched to 32 kB because 64 kB did not work well with the combination of SuSE 9.0, USB, CD and audio sectors. I had a similar report before from Eduard Bloch about kernel 2.6 and USB but at that time i had neither a USB drive nor a 2.6 kernel. -- To Tomasz: One could revoke that 32k change for an experiment: Currently in libburn/os-linux.h : /* ts A70523 : >32k seems not good with kernel 2.4 USB drivers and audio #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 */ #define BURN_OS_TRANSPORT_BUFFER_SIZE 32768 Experiment proposal: #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 make install and then run the test with cdrskin again. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
DVD+R 16x info: INQUIRY:[HL-DT-ST][DVDRAM GSA-4163B][A106] GET [CURRENT] PERFORMANCE: Write Performance: 7.2x1385=9913KB/[EMAIL PROTECTED] -> 15.9x1385=22059KB/[EMAIL PROTECTED] 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: [EMAIL PROTECTED]:~$ 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.
Re: Low burning speed
Hi, > [EMAIL PROTECTED]:~$ time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 > skopiowane 1048576000 bajtów (1,0 GB), 98,1632 sekund, 10,7 MB/s That's nearly 8x speed. Given that there is a short piece of 6x at the start, this is the full nominal speed to be expected. I am running out of ideas but one: scheduling priority. Try as superuser: nice -20 growisofs ...normal.slow.job... If this shows no better performance, try the same with cdrskin. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
