Re: CPS/throttle patches

[Richard Fuchs <dfx@gmx.at>]

On Tue, Jun 11, 2002 at 07:14:47PM -0500, Charlie Hubbard wrote:
[...]
> 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

This is looking pretty good. I must admit, before I started using an array
to calculate the CPS, I was trying to figure out a formula that works like
the one you described. Of course I failed, and only got a half-working
result. However, it was enough to notice a few special behaviors of such an
attempt. Read on...

[...]
> 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.

The only disadvantage I can see is that it uses a bit of memory. The more
samples you store, the more memory you consume. For 3 minutes, sampled at
1-second intervals, you'd use around 4k of data for each DCC.

CPU usage really isn't an issue. Every time a new sample is recorded into
the array, the current file position is recorded (and NOT the gain between
samples), and hence all you have to do to get the CPS is "pos of last
sample - pos of first sample / time of last sample - time of first sample".
You never have to iterate through the whole array.

But let me assure you, I'm not interested in an honest-to-god CPS average
myself.

[...]
> 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!

I'll ask the key question now. When exactly will the new average CPS be
calculated? When is the "cps = 0.9 * cps + 0.1 * newcps" supposed to be
executed?

The problem is, the more often you issue this formula, the faster the CPS
will move to the new value. But let me explain first. I can imagine the
following two methods.

To make it correctly average in a specified amount of time, you need to
call it in fixed intervals, say once a second. Then you have the problem
that the gain will always be a multiple of the sender's block size, while
the time passed will always be exactly 1 second. With low CPS rates for
instance, you'll always see a gain (and hence a new CPS value) of 0, 512 or
1024 each second, and nothing in between. Plus, you could never update the
CPS between the 1-second intervals; you'd have to wait for the timed
function to be called.

The second method would be to call the function every time new data (i.e. a
packet) arrives. But in that case it wouldn't be a 10-second average any
more, it would be a 10-packet average. The smaller the packets are, and the
faster they arrive, the faster the CPS would change. Also, the gain would
still always be a multiple of the sender's packet size. If you want to get
the precise new CPS value, you'd have to use sub-second precision (i.e.
gettimeofday()). And, with this method, you have a serious problem when the
DCC stalls, i.e. no packets arrive any more. The CPS calculation function
simply would stop getting called. The CPS value would stand still, and not
go towards 0. The only way to achieve this is to call the CPS calculation
in timed intervals. And that would mean mixing this method's problems with
the first method's problems. It would be impossible to tell over which time
period or over what other value the CPS would be averaged.

I figured this all out after I implemented my (bad) formula. Maybe I have
overlooked something, and this method can be made work right, but I couldn't
think of a solution myself.

Richard
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/