Re: dvd+rw-tools update [6.0, DVD-R DL]
Hi,
> >>My standpoint is that if you get into situation when you consider more
> >>than 64MB, it's likely that bottleneck is abnormal
> > Or the user is an aberrated personality like me who
> > streams compressed archives on the fly. :))
>
> Keep in mind that ring buffer harmonizes *variations* in input rate. It
> can't possibly help if the stream can't be maintained at required rate
> in *average*, no matter how large the buffer is. In other words I find
> it hard to believe that on-the-fly compression of real-life data affects
> required ring buffer size very much.
A fifo increases average throughput if the system can deliver
as peak performance more than the drive speed. Of course
the average write performance cannot be better than the
average data generation performance. A generously sized
fifo can bring both average performances nearer together.
That's because it can save more peak performance for future
use in dire times. (A data structure which transports peak
performance into the past has still to be developed.)
afio on my AMD 2600+ cheapo can deliver about 15 to 20 MB/s
speed as peak performance when reading precompressed data
from memory cached filesystem and it falls to arbitrary low
rates when redundant data achieve good compression ratios.
I found out that a 200 MB fifo can bring the average
write performance with my /opt and /home trees near to
3.0x DVD while a few weeks ago without fifo it was only about
2.2x. A fifo of 32 MB brings about 2.8x.
The CPU load during the backup run is clearly higher now
because afio and gzip can work more freely. (That was with my
own fifo but yours would give similar results.)
I am not sure wether the effect is only due to the buffered
peaks or also due to the decoupling of my suboptimal IDE
hardware.
> as you
> still have to pull a lot of data from disk, you still put quite a
> pressure on VM subsystem, so direct I/O can still help,
But how to talk afio, star or mkisofs into that ?
How to talk myself into streamlining my own processing pipeline ?
There's surely some 10% of CPU load to be squeezed.
To my luck, backup is better done with RW media and those
are limited to 4x speed usually. But if i imagine a 500 MHz
PC with a 4x DVD writer ... uh oh.
> > with 16x DVD a 64 MB buffer gives you just three seconds of
> > reserve.
>
> Yes, which is why I wrote it's on the edge. But idea is also that
> average Joe will get hypnotized by progress indicator and abstain from
> pressing the buttons and cause massive page faults while the recording
> is in progress anyway,
Don't forget Damian Demon and Chris Cron.
Those guys can stirr up a system too. Then there is my overly
smart ReiserFS (first name Hans) and the elevator man (Linus)
not to forget myself (in all my five multiple personalities).
A 4x DVD lasts nearly a quarter of an hour. Enough time to
forget about it and to start some compiler run.
There is always a reason to make the disk rattle.
I can hear a bonking sound from the writer when its buffer
runs empty. With the fifo this sound became rare for uncompressed
ISO 9660 streams. (Compression is still bonking, of course.)
> while technically minded users like ourselves
> will figure out what's appropiate in any particular situation
> [anyway too].
At least i try to take the consequences of my actions like a man:
with a stone face and not showing any sign of pain.
Have a nice day :)
Thomas
Reply to: