Improved Progress

[ML]

Hi,

I think a better Information about the actual Progress will be nice. I'm missing following Information:
-actual Speed of FileTransfer
-needed Time for Backup till now
-estimated Time for Backup

Additional I'm not able to see the complete Path cause auf encrypted Home Directory.

regards

[Germar (germar)]

At the moment there is no way to calculate the estimated time to end as rsync does not provide any reliable progress informations. Next rsync version 3.0.10 will come with --info=progress2 option which will be useful. But until that version is released and is used in common distributions there is no way to implement this as well as progress bars.

What do you mean with complete Path in encrypted Home? Can you please fill a separate bug or question for this?

[ML (0cs935kb517wwmwa7m9428daadkye-m9u2-wz6bkyhu4uqpfausw0ege9b0y33eg)]

thanks, I will.

[Mauro (mauromol)]

Hi Germar,
it seems like now BIT shows proper progress information. However, I have an only question: the Speed indication seems to be exceptionally optimistic, or rather completely wrong. I'm currently backing up to a NAS (SSH remote profile in full rsync mode) from a notebook with an 802.11n wireless connection, so speed can't be much more than 5 MB/s. If I do a --benchmark-cipher the reported speed is on that order of magnitude, but the current progress indicator says I'm backing up at... 2,70 GB/s!!! :-O
The speed seems to increase with time passing by, so my suspect is that there is just a wrong division in place...

Or am I missing something?

[Mauro (mauromol)]

Sorry for posting here, I didn't notice this is a duplicate :-(
By the way I'm using BIT 1.1.2. Please let me know if I should rather open a new bug.

[Germar (germar)]

Hi Mauro,
This is a bug in rsync 3.1.0 (https://<email address hidden>/msg29871.html). But even if you patch rsync with the attached patch the progress will still be wired. I already made rsync calculate all files in advance which helped a little. I think this is caused by rsyncs delta-sync algorithm which will only transfer changed blocks of files.

[Mauro (mauromol)]

I also thought about the delta-synch being the cause, but in my case that was a new backup (from scratch), so the delta was the entire backup set (please note I was using an unpatched rsync 3.1.0). I also thought about compression, but it could not be the case either.
That backup ended up with a speed of more than 3 GB/s! :-P This obviously completely breaks the ETA, too.

Anyway, since you have the total size copied and the elapsed time, couldn't BIT compute the (average) speed by itself?
The remaining size (and hence the ETA) could be more problematic (because of the delta-sync), but it may be more accurate all the same, given the current situation...

Maybe an option "make BIT compute the rsync progress information by itself" (disabled by default) with a tooltip that talks about the rsync 3.1.0 bug could be the best solution...

[Germar (germar)]

unpatched 3.1.0 rsync version does calculate wrong. So if you had patched it before the progress should have been accurate for the first snapshot.

Also the further snapshots will show a more or less accurate average speed. Only ETA and percent done is still not correct. But there is nothing I could do with manual calculation because BIT itself doesn't know which files had change and how many data need to be transferred. I hope the rsync guys will improve this with next version.