[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CPS/throttle patches
On Tue, 2002-06-11 at 21:23, Richard Fuchs wrote:
>
> 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 don't think there is anything wrong with the array technique. I've
used myself (although in a different type of application) and I know it
can be made to work well. Like you said, the main disadvantage is the
additional memory used but, even for fairly good sized arrays, this is
pretty small. 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.
> 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.
I agree completely. The CPU issue only becomes an issue if you take a
naive approach to handling the array data.
[I reordered your paragraphs a little bit so I could respond point by
point]
> To make it correctly average in a specified amount of time, you need to
> call it in fixed intervals, say once a second.
Yes, if you sample once per second then you calculate the new CPS once
per second too. If you sample at some different interval (4 times a
second or once every two seconds say) then you need to normalize the
"newcps" value to bytes per second before you use it in the
calculation. Here is what I mean...
Assume you sample once every 250 milliseconds. With each short sample,
you need to first convert the gain during that interval to bytes per
second by dividing it by the interval time. So...
newcps = gain / 0.250
Then you can use "newcps" in the equation.
> 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
This works in the case where you sample on a per-packet basis too,
except if you do it on a per-packet basis, it is important that you can
accurately measure the time between packet arrivals because you will
need that time to normalize "newcps" to bytes/sec before you use it in
the equation.
> 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.
Are you sure this is true? 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. But, when
you average them out over 10 intervals (for instance) you still arrive
at a value of 768. Using the array method, this should give you exactly
768
(512*5 + 1024*5) / 10 = 768
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.
It's true that by always sampling at a fixed rate (once per second or
whatever) you can't update the CPS between the 1-second intervals but
I'm not sure that is a problem (1 second updates seems plenty fast
enough). 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.
Now keep in mind that I keep thinking about this problem in terms of
simply reporting a good, short-term CPS average. I think the above
ideas will work ok for that. The problem of rate limiting might be
different though. I just don't know.
(übrigens, dein Englisch ist ganz prima! Bevor ich deine e-mail Adresse
bemerkt habe, habe ich gedacht, dass du Amerikaner bist.)
Paydon
--
XChat-discuss: mailing list for XChat users
Archive: http://mail.nl.linux.org/xchat-discuss/