transport speed indication could be "smoother"

[Jelmer Vernooij]

  affects bzr

The transport speed indicator fluctuates a lot at the moment; it
would be nice if it could use historic data a little bit to be
"smoother"; perhaps just showing the average of the last X speeds?

[John A Meinel (jameinel)]

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

Jelmer Vernooij wrote:
> Public bug reported:
>
>
> affects bzr
>
> The transport speed indicator fluctuates a lot at the moment; it
> would be nice if it could use historic data a little bit to be
> "smoother"; perhaps just showing the average of the last X speeds?

Right now it does a 0.2s average. I found that 0.5s worked well for what
I expected. (My guess is that 0.2 is short enough that we get some
initial small-bytes read and processed, and then a lot of lag before we
get the next big-bytes processed.)

Any further than that, and I would use a first-order filter (rate =
old_rate * X + new_rate * (1-X))

So the quick fix is to just change the "0.2s" to "0.5s" and see what you
think:

=== modified file 'bzrlib/ui/text.py'
- --- bzrlib/ui/text.py 2009-01-21 05:49:18 +0000
+++ bzrlib/ui/text.py 2009-02-12 18:19:37 +0000
@@ -219,7 +219,7 @@
         now = time.time()
         if self._transport_update_time is None:
             self._transport_update_time = now
- - elif now >= (self._transport_update_time + 0.2):
+ elif now >= (self._transport_update_time + 0.5):
             # guard against clock stepping backwards, and don't update too
             # often
             rate = self._bytes_since_update / (now -
self._transport_update_time)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmUaFAACgkQJdeBCYSNAAMMQwCfcdMSzDWUt4e7+yrxbMZPG5Ui
BOoAoJt3fti7weL+/77LbhpEN1liuukE
=xDbH
-----END PGP SIGNATURE-----

[Jelmer Vernooij (jelmer)]

On Thu, Feb 12, 2009 at 12:20:00PM -0600, John Arbash Meinel wrote:
> Jelmer Vernooij wrote:
> > Public bug reported:
> > The transport speed indicator fluctuates a lot at the moment; it
> > would be nice if it could use historic data a little bit to be
> > "smoother"; perhaps just showing the average of the last X speeds?
> Right now it does a 0.2s average. I found that 0.5s worked well for what
> I expected. (My guess is that 0.2 is short enough that we get some
> initial small-bytes read and processed, and then a lot of lag before we
> get the next big-bytes processed.)

> Any further than that, and I would use a first-order filter (rate =
> old_rate * X + new_rate * (1-X))

> So the quick fix is to just change the "0.2s" to "0.5s" and see what you
> think:
Yeah, that's significantly better, though still not optimal. A
first-order filter sounds like a better idea, though I don't feel like
implementing that atm :-)

Cheers,

Jelmer