>> - The estimated remaining time should be more conservative.
> It is difficult to make predictions, especially about the future. :-)
Yes, I'm quite aware that even as simple-looking a problem as predicting
the approximate time of completion of a data transfer is hard in general.
> While developing ddrescue, I noticed that the current rate is too volatile,
> but the average rate may take a long time to reflect changes in speed,
> especially after a change of phase.
>
> So I use the average rate of the last 30 seconds to estimate the remaining
> time. If your rescue is having slow fluctuations of speed, ddrescue will
> probably show fluctuations in the remaining time. Maybe increasing the
> interval to the last 60 seconds could dampen such fluctuations, but would
> also increase the amount of calculation involved.
Interesting. In my recent experience, I often (probably because I've
been mostly reading from fast devices and writing to slower ones) see
behavior along the lines of:
- For a few tens of seconds, the rate is significantly higher than
the average.
- For a minute or more, ddrescue appears completely frozen (presumably
the kernel is draining the output queue or something).
So when the display is updated, the recent rate has usually been high
(when it's not, the display is not updated at all) which would explain
why I see a predicted remaining time which is virtually always more
optimistic than the reality.
Maybe the real problem is the fact that the process is temporarily
frozen (C-c and `kill` only take effect after the minute-or-more, so
the freeze is really at the level of the kernel. Never bothered to try
and track down what it's really doing at that point)?
> '--size=input' is not needed because it is the default behavior of ddrescue
> (when lseek returns the true size),
Thanks for confirming.
> but '--size=output' is indeed useful
> when overwriting the output file or device. Thank you for the
> suggestion. I'll implement it for the next version, to be released
> in January.
Great, thanks.
Stefan
