The progress bar that doesn't convey any sense of progress (was Re: ...)

John Arbash Meinel john at arbash-meinel.com
Wed Dec 9 15:46:57 GMT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gordon Tyler wrote:
> Martin Pool wrote:
>> Gordon I see in that other branch you're scaling the rates to KB, GB,
>> etc.  I thought about this in the first cut and actually rejected it
>> (though I may be wrong) for a few reasons:
> 
>>  * things tend to flap from 900kB to 1MB/s creating noise to little real benefit
>>  * in most cases both speed and size will not be phone-number-long
>> measured in KB
>>  * if you measure total transfer in GB, it will stay stuck at 1GB for
>> a long time
>>  * I don't know if it will actually show up but it may slightly slow
>> things to do fp math in here
> 
> Good points.
> 
> 1. Could use rate history to give a weighting to one scale or the other.
> 2. Perhaps a fractional display? Although I suppose that's not really
> any better than just displaying it in KB all the time.
> 3. Updates are throttled to 2 per second.
> 
>> What did you think of actually using average rates?
> 
> The rates were always really low, like < 50KB/s, even after I tweaked it
> to only start measuring time once the first data is received. I think
> the problem is that during the whole process there are phases of data
> transfer and then CPU activity alternating. The transfer display
> essentially freezes during the CPU phases and then when it resumes, the
> elapsed time without data transfer affects the average rate. I don't
> feel like it's an accurate representation of the speed of data transfer.

It is arguably that this is accurate, though... As that is the average
transfer rate.

The simple averaging is just a first-order filter:

value = weight * value + (1-weight) * new_value

That doesn't require tracking anything. Commonly weight is around ~0.8.
That allows the current speed to eventually dominate, but still tracks
the overall value.

> 
> Maybe if the average is only over the last X number of seconds it would
> produce a better result. So it's not quite the instantaneous rate but
> it's not the overall average including dead spots either.
> 
> Ciao,
> Gordon

Certainly an option.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksfxnEACgkQJdeBCYSNAAMd1ACgzgWibvApDYRY0e/ix0EQn4XY
6ksAn03ar4c77/8Mel4xzuxhe3boEn2D
=qRaX
-----END PGP SIGNATURE-----



More information about the bazaar mailing list