You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having a config/cli option for seeing the current (instead of the average) speed in the backup progress bar
Reason
I would personally really enjoy seeing the speed spike up (and dip down) in real time. Keeping the time estimate an average is probably a good idea, but I feel like an option to set the speed to real-time wouldn't cause any harm and would be really cool!
Thanks for considering this option :)
The text was updated successfully, but these errors were encountered:
Hi @jullanggit, thanks for opening this issue.
Note that rustic currently already shows the current speed - which is averaged/smoothed a bit.
The point is that a concept of "actual speed" is a very complicated. We just can say that at some given points in time, we made a progress of a given amount of bytes. Calculating a speed always includes doing some averaging...
Thanks for the quick answer! Would it maybe be possible to have an option to change how much smoothing is applied? The reason I even noticed this is that the counter still shows multi-MB/s speeds, even tough the total count (in MB) hasn't changed for a few seconds. Again, nothing too big, just something that would maybe be fun to play around with!
I have looked a bit into the source code for the progress bar and came to the conclusion, that it would probably be needlessly complicated to show the "current speed" / average less, so I will be closing this issue.
Nonetheless, thanks for looking into this!
Proposal
Having a config/cli option for seeing the current (instead of the average) speed in the backup progress bar
Reason
I would personally really enjoy seeing the speed spike up (and dip down) in real time. Keeping the time estimate an average is probably a good idea, but I feel like an option to set the speed to real-time wouldn't cause any harm and would be really cool!
Thanks for considering this option :)
The text was updated successfully, but these errors were encountered: