[EMAIL PROTECTED] wrote:
Hi,
 
  
I didn't know where I have to report the problem. If this is not the 
medium please show me the path.
    

I feel adressed properly. :)

  
Description of the problem: growisofs doesn't record to the speed 
specified. The recorder supports 4x; the media supports 8x. Growisofs 
states "current write speed is 4.1x" but it actually records at 2x. 

sudo /usr/bin/X11/growisofs -Z 
/dev/hdd=/home/david/kubuntu-5.10-dvd-i386.iso 
-use-the-force-luke=notray -use-the-force-luke=tty -dvd-compat -speed=4
Executing 'builtin_dd if=/home/david/kubuntu-5.10-dvd-i386.iso 
of=/dev/hdd obs=32k seek=0'
/dev/hdd: "Current Write Speed" is 4.1x1385KBps.
    

So far so good.

  
   1245184/3291650048 ( 0.0%) @0.0x, remaining 308:17
   1245184/3291650048 ( 0.0%) @0.0x, remaining 440:25
    

Often observed by other users. I myself do not experience
these start delays, though.


  
   7077888/3291650048 ( 0.2%) @1.2x, remaining 108:16
  15761408/3291650048 ( 0.5%) @1.8x, remaining 58:53
...
3287613440/3291650048 (99.9%) @1.7x, remaining 0:01
builtin_dd: 1607264*2KB out @ average 1.8x1385KBps
    

This looks like undersupply at the input side of growisofs.

I can report of three such cases :
- A user who got about speed 2.5x with the real backup
  on the fly but could burn a preformatted image at 4x.
- A user who could burn only with 1.0x from a certain 
  source disk - wether preformatted or on the fly.
  Another disk could deliver data for a 4x burn.
- I myself experience an average of 3.4x on the fly and
  4x preformatted. On the fly i can see speeds as low
  as 0.6x for a few seconds. Usually its 3.9x to 4.1x.

At this mailing list there have been posts which state that an
intermediate RAM buffer between data source and growisofs
can improve performance. But i believe that was about
a mkisofs-growisofs pipe and not about preformatted images.

Your speed pattern resembles the one of the user with
the 1.0x hard disk. Check the performance of yours by
  time dd bs=2048 if=/home/david/kubuntu-5.10-dvd-i386.iso of=/dev/null

If this lasts in the range of half an hour then you got
a simple reason for your problem. (But not a simple solution)
If it is done within five minutes then you have to explore
the cooperation between both, disk and recorder.
They aren't on the same IDE controller, are they ?
if you are willing to use some complexity you can probably improve your performace by using a buffer program befreen mkisofs and growisofs. I tried using a buffer pool of 20MB totasl, 5k buffers, and it did help the performance. However, the most likely cause of this is one or both devices not using DMA, or not allowing interrupts during i/o. Either of these situations will result in less than optimal performance.
-- 
bill davidsen <[EMAIL PROTECTED]>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Reply via email to