[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CPS/throttle patches
On Tue, 2002-06-11 at 01:47, Peter Zelezny wrote:
>
> That sounds even simpler. Though, I think it's better to start the
> rate/cps as the gain at time(1), so the rate is almost right even in the first
> ten seconds.
Good point! That's a good idea
>
> Allthough, I can't figure out why I get different numbers.
>
> time pos gain
> 1 4096 4096 cps = 4096
> 2 8192 4096 cps = 0.833*(4096) + 0.166*(4096) = 4096
> 3 10000 1808 cps = 0.833*(4096) + 0.166*(1808) = 3714
> 4 12000 2000 cps = 0.833*(3714) + 0.166*(2000) = 3427
> 5 17000 5000 cps = 0.833*(3427) + 0.166*(5000) = 3688
> 6 20000 3000 cps = 0.833*(3688) + 0.166*(3000) = 3572
Well the TCP estimation isn't calculating a true average. It's
calculating a "smoothed" approximation to the instantaneous transfer
rate based on the last N points (6 in your example). This will equal
the true average only when the initial value is already at the true
average and the next six points are all separated by the true-average
gain. That's probably not something that happens very often (ever?) in
real life.
However, with that said, the TCP estimation still does a decent job of
following the true average over time. I did a spreadsheet with faked up
data to show you what I mean.
http://mit.midco.net/chubbard16/xchat/ave06.html
For the data, I computed each successive gain as 3000 + r where 'r' is a
random value between 0 and 2000. This puts the long term average gain
at about 4000 CPS but also has a lot of variation between individual
gains. I then used these gain numbers to compute a column with the
current 6-point TCP approximation and a column with the true 6-point
average values at each point. These are what appear in the plot (the
blue square markers are the TCP stuff and the dark-red diamonds are the
true average stuff). As you can see, they track one another fairly
closely throughout the "transfer" (I used my starting TCP value the same
as my first measured gain like you suggested). However, if you are
interested in the honest to God average of the last 6 points, my
technique doesn't get you there :-(
I think both methods work ok and your method definitely works better if
you need/want the honest to God short-term average. The "array" method
may have some slight disadvantages when used for long averaging
intervals. I know this discussion started as a look at CPS rate
limiting, and very short averaging intervals (6 points) is probably just
what you want in that case. However, if we were just talking about CPS
rate reporting in general, I would prefer the short-term averaging
interval be more like three minutes (or actually, it would be nice if I
could set it).
Assuming you sample at 1 second intervals, A three minute averaging
interval would mean each connection would need a 180 element array. For
bigger arrays, recomputing the sum of all the array elements becomes
unacceptably expensive if you are actually planning to sum up all the
elements each time. Fortunately, there is an easier way. Treat the
array as a queue and maintain a separate accumulator. Basically, each
time you get a new gain value, take the value off the head of the queue
(i.e. the oldest value in the array) and subtract it from the
accumulator. Then add the new gain value to the accumulator and stick
it on the tail of the queue (it gradually slides toward the head of the
queue during the course of the averaging interval). The short-term
average is always the accumulator divided by the size of the array. I've
done this many times while processing sound files (there we were
computing a short term average power) over large arrays (~8000 elements)
and it works well.
Of course in the TCP method (nobody knows why I insist on calling it
that) you wouldn't need to deal with the arrays at all. Just set
(1/180) and (1 - (1/180)) as your new averaging constants and everything
just works. If a short term averaging interval were used for general
CPS reporting purposes (i.e. not necessarily for rate limiting) I think
the TCP method works good. Especially if the length of the averaging
interval is large. No arrays to allocate and initialize when creating a
new connection!
But I digress. I've said a lot more on this than I originally planned
to but I've never been quite satisfied with the way various programs
report CPS. It is usually either the total average CPS (i.e. total
bytes transferred divided by total time) or it's the instantaneous
transfer rate (last measured gain divided by sampling interval). If I
had to pick between one or the other I would rather see the total
average CPS I guess, only because the instantaneous CPS jumps around so
badly it's not very useful. However, what I would really like to see is
two numbers; the total average CPS and a short-term average CPS computed
over some interval on the order of two or three minutes (user settable
would be cooler :-)). The short-term interval is reasonably stable
(doesn't jump around like the instantaneous rate) and it gives you a
good idea of how the transfer is currently doing. By comparing it to the
total average you can see if the connection is currently doing better or
worse than it has over all and get some idea of how much better or
worse.
OK, I'll stop blathering now.
Paydon
--
XChat-discuss: mailing list for XChat users
Archive: http://mail.nl.linux.org/xchat-discuss/