Sometimes it feels like you used the "time remaining" algorithm from Windows 95, such as when the database rebuild progress displays 1.5 minutes remaining for 10 minutes.
One thing I've learned over the course of building Armory is that those time-remaining bars are
very difficult to get right. Especially when it comes to things like downloading data that fluctuates in speed rapidly. I have an extensive background in signal processing, yet I still can't get it right.
On the other hand ,there is a flaw in my algorithm -- it seems to use
CPU-timings instead of wall-timings. Typically this results in the system reporting that it took 2 sec to move 1% of the bar, instead of 3.2 or whatever. This leads to very optimistic estimates. I've been meaning to go in and figure out what is causing that, but I haven't had it on my priority list for a while.
I figured out the set of conditions on my systems under which the time-remaining bars are accurate and not accurate.
Time-remaining is accurate(*) when there is sufficient memory allocated to the machine such that it doesn't have to use swap.
If the machine starts swapping, then the time to complete a blockchain scan increases (apparently) without bound, but the estimates do not.
That would fit with using CPU timings, because the process is not using using CPU while it's waiting for memory to be moved to and from swap.
* "accurate" means error less than 1 order of magnitude