[quote="elez"]You're correct, Ivan.
My personal hunch is that with KTorrent, the cause of this instability is 10% REAL instability and 90% "GUI" instability.
[quote]

The GUI just displays the current speed, though you can increase the update interval (by default it is half a second, maybe we should make that one second).

That would view the jumpyness less often, but the jumpyness is just as much. Though this would make it somewhat less noticeable, which is good i think.

Hmm, not sure, i think if you feel there is something you can improve in this area in the future, i would do this yes.

stoeptegel wrote:That would view the jumpyness less often, but the jumpyness is just as much. Though this would make it somewhat less noticeable, which is good i think.

@stoeptegel: You're right. The jumpyness would be less often but it will still jump.

@George: It would actually be counterproductive, in my view, to increase the update intervals, since we would not only get some random speed that came from averaging a non representative 2 seconds, but we'd also have harder time to average a few results in our heads to estimate the real average speed (because we'll have to wait longer for them to be updated).

Nowadays, when I want to estimate the average speed when I use KTorrent, I just look at the speed displayed for about 5 seconds and try to average it in my head.
I think this is the time to mention that the AVERAGE speed is THE statistic us humans need to make our estimations to when the file finishes downloading.

George, I think you know better then I do that internet speed is something with a very stochastic behaviour, especially with p2p networks. As far as I know, the best simple way to beat it when trying to display the speed to us humans is to average. (Think what YOU'RE trying to do in your head when you're trying to assume your current speed, you AVERAGE. Let your computer do it!)

F.Y.I. When internet speeds become much much faster, if you think about it, we might even need to average, say, 10 seconds, because we might get jumps from 20 to 2000, then back to 100 etc etc.

Also, how does KTorrent calculate the remaining time for a file to download? It uses the current speed (if it's doing it like most other p2p applications). I can guarantee that it'll give a MUCH better (and more stable) estimate of the remaining time. (I'm not at home now, I'm using my g/f's wind*ws computer so I can't check to see right now if KTorrent's "remaining time" is as jumpy as the speed is but if it is, increasing the averaging time will help)

George, to quote the shirt I was wearing a couple of days ago, Just do it

You'll be happy you did...

Elez

The best way to implement this would be sampling via an FIFO queue.

Lets say you sample every half a second and we want to average 10 seconds, you would have a queue of 20 in length. Then every second we average the entire queu's vales to update the gui's display. This gives you a better "averaging" like elez wants while still maintaining a constant sampling of data rate the developer wants.

Of course this should all be able to be fine tuned by the user with settings such as:

Sample Rate (every X seconds) : 0.5
Averaging Queue Length: 20
Update GUI Interval (every X seconds): 1.0

Matt

You mean sampling the 2 second average ?

mattlant wrote:The best way to implement this would be sampling via an FIFO queue.

Lets say you sample every half a second and we want to average 10 seconds, you would have a queue of 20 in length. Then every second we average the entire queu's vales to update the gui's display. This gives you a better "averaging" like elez wants while still maintaining a constant sampling of data rate the developer wants.

Of course this should all be able to be fine tuned by the user with settings such as:

Sample Rate (every X seconds) : 0.5
Averaging Queue Length: 20
Update GUI Interval (every X seconds): 1.0

Matt

If I understood you correctly, this is no different then averaging the last 10 seconds every 0.5 second, meaning, this should do the trick just as well. I'm all for it since (again, if I understood correctly) it is mathematically identical to what I suggested.

Cheers,
Elez

I guess, I just tried to put it in more technical programming sense. Its easy enough to implement this type of thing.

mattlant wrote:I guess, I just tried to put it in more technical programming sense. Its easy enough to implement this type of thing.

Well, we're in luck. KTorrent ALREADY uses a good mechanism for calculating speed, only it's averaging the last 2 seconds of throughput to calculate it.

My mission is for KTorrent to do exactly what it's doing right now, only with at least 5 seconds averaging.

Vote "yes" on prop. 5 second averaging!

elez wrote: Vote "yes" on prop. 5 second averaging!

OK, I have increased the interval to 5 seconds.

George wrote:OK, I have increased the interval to 5 seconds.

YEEEEEEEEEEEEEEEEEE HAAAAAAAAAAAAW!
You will all see the benefit of this improvement!

When will this take affect? at the next 2.0.x?

Thanks, George!
Elez

elez wrote:

George wrote:OK, I have increased the interval to 5 seconds.

YEEEEEEEEEEEEEEEEEE HAAAAAAAAAAAAW!
You will all see the benefit of this improvement!

When will this take affect? at the next 2.0.x?

Thanks, George!
Elez

At the moment we have no 2.0.3 planned.