[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: