FreeFileSync Forum

Brought back to life, I re-read the thread. I think using 'maximum' value(s) in any algorithm is fundamentally flawed. As I suggested earlier, " If you store the max rate, a spike will destroy your estimation. If it spikes to 80MB/s for a second, it will say your last 800MB will take 10 seconds ...

Suggestion, as the estimated time is just that, an estimate, why not display a range
Remaining time for data size and also the remaining time based on file count, display the smaller one first.

So the display would be something like 5min - 3hr 35min

That way the user knows the range it could be ...

You can't do that because in order to calculate the calculated elapsed time for r, you have to call the formula again with starting conditions for the transfer, then again, then again. Recursive algorithms don't work without an exit condition, and so this would be a memory leak at best and ...

Here's some (cool?) idea: Maybe FFS should start recording some historical (per-device-)data: item count, bytes and total time of last syncs. Then assume some simple formula like

total time = A * item count + B * bytes

Then fine-tune the unkown parameters A and B based on the historical data ...

That algorithm is wrong though. The size left and files left are the same data, so you would be doubling the remaining time essentially. The better way to do the algorithm would be:
T = [(Size remaining/avg transfer rate) + (files remaining/avg file rate)] / 2
avg rates can be calculated based on ...

Hello!

I have a suggestion to improve the "time remaining" calculation with the following forumla:
total time left [s] = total size left [mb] / maximum transfer speed [mb/s] + total files left [files] / maximum speed [files/s]

The maximum speeds will be updated as soon the application gets a new ...