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 :-)
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