Re: dvd+rw-tools update [6.0, DVD-R DL]
Hi,
> > How come that the time granularity of the backup processing chain
> > does not get finer as the systems get faster ?
>
> What do you understand by time granularity?
I see a fifo as a method to smoothen out peaks and gaps in a
input function and to bring the output nearer to the input
average.
The intensity of peaks and gaps resp. the deviation from the
average can be characterized by the time span in which one
may expect that those irregularities compensate each other.
The product of this time span and the average speed determines
the size which is needed for an effective buffer.
This time span is what i mean with "time granularity".
If the overall system gets faster, i would expect this
characteristic timespan to get shorter. But it seems to
stay within the range of several seconds.
Since the average speed grew and the time staid more or
less the same, the fifo size had to grow.
The only logical explanation is that the characteristics
of the input function have changed while the system
became faster.
Other views which lead me to the same result:
My considerations about the benefits and effectivity of a fifo
always dealt with relative speeds of input and output. Never
with absolute speed.
Thus one would expect that if both input and output speed
increase in the same proportion, then the effectivity should
stay the same. But it obviously doesn't.
A simple thought experiment:
Imagine a movie of an old backup run which is shown at double
speed. The report messages about buffer size and buffer fill would
stay exactly the same.
If everything would have gotten faster by technical progress then
we would have exactly that highspeed movie situation. But we haven't.
> But oneproblem is that current drives have less internal RAM compared to
> older drives if you take the drive speed into account.
True. But were the drive buffers sufficient 4 years ago ?
If they weren't very effective in the past then their relative
diminishment would not be significant now.
I'm still riddling.
What effect did change the shape of our input functions ?
> > http://lists.debian.org/cdwrite/2004/cdwrite/2006/01/msg00057.html
> > A short answer would be welcome.
>
> Well, some things that are not done immediately because of workload may be
> forgotten if noone pings again.
You could have simply declared it a feature :))
How old did it become while being unnoticed ?
> *** 3737,3745 ****
With my copy of 2.01.01a4 it's in line 3565 ... make ...
... running again my reported test command ...
Track 01: 125 of 125 MB written (fifo 100%) [buf 99%] 8.0x.
WARNING: padding up to secsize.
Track 01: writing 300 KB of pad data.
Track 01: Total bytes read/written: 131198521/131506176 (64212 sectors).
...
Track 02: 38 of 38 MB written (fifo 100%) [buf 99%] 8.5x.
WARNING: padding up to secsize.
Track 02: Total bytes read/written: 40104790/40105984 (19583 sectors).
Ok, no padding reported on track 2. Is it readable ?
(The cdrom driver shows me both tracks as one continous stream.)
dd if=/dev/cdrom bs=1m skip=124 | afio -tvk - 2>&1 | less
Yep. afio can detect the start of the archive and reports all files.
Looks good.
Have a nice day :)
Thomas
Reply to: