Showing estimated time remaining on sync and other processes #2560

It would be nice if an estimate of the time remaining for some task were displayed in the bottom status bar along with the progress bar in some way, like a brief popup when the user hovers over or clicks the progress bar.

This would be very nice, but it's extremely hard to get right. It depends on some known but-hard-to-know properties (disk IO speed, IO vs CPU speed, network speed if not reindexing, ...), and some properties not under your control (the bandwidth of the peer you're fetching from, for example).

I don't think it's reasonable to do this with any accuracy.

@sipa It would always be possible to measure the time taken for one segment of the work to be completed and then calculate the the time for all the work to be completed.

Agreeded.

On Wed, Apr 24, 2013 at 5:36 AM, Pieter Wuille notifications@github.comwrote:

This would be very nice, but it's extremely hard to get right. It depends on some known but-hard-to-know properties (like number of CPUs used for verification, disk IO, network speed if not reindexing), and some properties not under your control (the bandwidth of the peer you're fetching from, for example).

I don't think it's reasonable to do this with any accuracy.

— Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/issues/2560#issuecomment-16914283 .

Felipe Micaroni Lalli

Movile Internet & Smartphones +55 19 8127-4903 felipe.micaroni@movile.com

@APerson241 Unfortunately it's not very, because the speed changes greatly in different segments, and the amount of the change depends on your cpu speed. The new progress indicator in git, however, is much better than the old one.

@gmaxwell That's a very good point, though it would seem that for certain tasks with a large number of identical or very similar blocks, such as syncing the transaction history, the change in time caused by differing speeds would throw the result off less. For the example of syncing, you could make the time estimate even more accurate by taking into account variables like the number of connections to the network (more connections = less speed).

If that's too expensive (speed-wise), a generic, constant estimate could always be used, taking into account a limited number of variables.