Re: CPS/throttle patches

[Richard Fuchs <dfx@gmx.at>]

Just a few notes...

On Wed, Jun 12, 2002 at 01:47:36AM -0500, Charlie Hubbard wrote:
[...]
> Also, it seems to me that when you first create the array,
> all the elements need to be initialized to something.  In my case, where
> I was planning to store gains in the array, I would initially set all
> the elements to the initial gain value (and set my accumulator to
> initial-gain * array-size).  But even for larger arrays that probably
> isn't such a big deal.

The array is initialized to all zeroes when the DCC struct is memset'd
after it's created. However, this isn't even necessary. I keep another
variable that specifies how many samples there are in the array at the
moment (how "full" the array is). It starts out as 0. When the first sample
is put into the array, it's increased to 1, and so on, until it reaches the
size of the array, from which point on old samples will be overwritten and
the fullness variable stays at its maximum value. That way I know exactly
which sample is the oldest sample, and which the newest in the array, and I
can do my calculations.

[...]
> I agree that the gains will always be
> multiples of the packet size but I'm not sure that hurts you. For
> example, pretend the TRUE CPS rate is 768 bytes per second.  If you were
> sampling at 1 second intervals, you would expect to see gains of 512
> bytes half the time and gains of 1024 bytes half the time.
[...]
> Using the "TCP" method, you probably won't get exactly 768 (it will
> depend on the initial value and in what order the 1024 and 512 byte
> packets arrived) but you will get something close to 768 and it will
> still track the true average over time.

Ah, I guess you're right. Looks like the formula I used when I tried this
approach was worse than I thought, because this was the main problem I had
(I think... My memory isn't the best).

[...]
> As you pointed out, sampling at a fixed rate also has the
> advantage that when the DCC stalls, you are still adding 0 bytes/sec
> into the CPS calculation once per second so the CPS value will
> automatically drop off.

This isn't an advantage, this is an absolute must. ;)

Anyway, I think it is possible to implement your TCP method if you take the
time between calls to the formula into account when calculating the average.
The CPS is probably going to go up and down a lot, but it does that anyway,
so it's no problem.

Here is a test case. Let's assume the CPS is currently at 468 (a random
number). We are now receiving exactly one 512-byte packet every 0.7
seconds, which means we've got a true CPS of 731. The goal is that the CPS
gradually increases from its current value, 486, to the real CPS within 10
seconds. Time and file positions are relative to the current values, i.e.
they start at 0.

time   pos     x      y      z
0.7    512     486           486
 1.0    512           472    471
1.4    1024    503           503
 2.0    1024          476    473
2.1    1536    519           520
2.8    2048    534           534
 3.0    2048          531    524
3.5    2560    548           549
 4.0    2560          529    521
4.2    3072    560           562
4.9    3584    572           574
 5.0    3584          578    568
5.6    4096    583           585

This table shows both of the two methods together. The indented rows show
the samples from the timed call of the function (i.e. whole seconds), and
the reported CPS for this method are in column y. The non-indented rows
represent the data whenever a packet is received (in 0.7-second intervals),
and the CPS for this method can be found in column x. Column z shows the CPS
with both methods combined. The formula would look something like this:

t = time passed since last call to formula
g = gain = advance in file position since last call to formula
a = size of the "averaging window" in seconds
z = z * (1 - t/a) + (g/t) * (t/a)

For example, in the case of the 5.6 row in the above table:

z = 568 * (1 - 0.6 / 10) + (512 / 0.6) * (0.6 / 10) = 585

You can even use this to calculate the CPS in second 5.6 relative to the
original situation (at time 0):

z = 486 * (1 - 5.6 / 10) + (4096 / 5.6) * (5.6 / 10) = 623

Not the same number of course, but still a good enough value IMHO. I will do
some more tests with this, and then try to implement it.

This thread is getting long. I didn't think CPS could be such a big deal. ;)

Richard

PS:

> (übrigens, dein Englisch ist ganz prima!  Bevor ich deine e-mail Adresse
> bemerkt habe, habe ich gedacht, dass du Amerikaner bist.)

Oh, vielen Dank! Eigentlich denke ich immer, dass ich einen ziemlichen Käse
daherrede, aber so schlimm kann's dann wohl doch nicht sein. ;)
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/