[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CPS/throttle patches
On Wed, 2002-06-12 at 07:35, Richard Fuchs wrote:
>
> 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.
Ah I see! That sounds like a good way to do it. So really, there are
no big disadvantages to using the array method at all.
That is good news because I did a couple of tests last night that make
me think the "TCP" method may not be very good after all. After you
pointed out that the gains will always be multiples of the packet size,
I decided my earlier spreadsheet, with its randomized data, was not a
very good representation of what really happens during a DCC transfer. I
decided to test the CPS=768 case that I was talking about yesterday.
See the following two link:
http://mit.midco.net/chubbard16/xchat/stall.10.10.html
In this example I also introduced a period in the middle of the
"transfer" during which the DCC transfer stalls so we could see how the
CPS computed by the two methods dropped off and then recovered when the
transfer started again.
In this example, I used a 10-point array to compute the true averages
(dark red diamonds) and the constants 0.9 and 0.1 to compute the TCP
approximations (blue squares). There are two interesting things here.
First, the TCP numbers tend to oscillate up and down between two values
but the true average values are very stable. Also, you can see it takes
the TCP method much longer to return to the 768 level after the stall.
The array method gets back quickly.
In an effort to decrease the response time of the TCP method, I changed
the TCP constants to 0.8 and 0.2 (5 points) and the results of that can
be seen here.
http://mit.midco.net/chubbard16/xchat/stall.5.10.html
Now the TCP response time is much quicker and is about the same as the
array method. However, the up and down oscillations of the TCP numbers
is much worse than before. For the purposes of rate limiting, maybe the
oscillations aren't important, but if you were to use the TCP method to
actually display the current CPS to the screen, the continual jumping up
and down would bother me. The array method on the other hand is very
stable.
> 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
In your example the values don't seem to oscillate up and down as badly
as they did in the examples I link to above. Maybe that is because I
used only 512 and 1024 as gains and your gains are a bit more
realistic. I don't know, maybe there is still hope for the TCP method.
:-)
Also, I like the way you have combined the two techniques (once per
packet and once per second). It is reassuring to see that both ways give
similar numbers!
>
> This thread is getting long. I didn't think CPS could be such a big deal. ;)
>
LOL I agree! I think it has been interesting examining the two
methods. I've enjoyed it and I've learned a few things. I know this
probably isn't interesting to everyone though. My thanks to the rest of
the list members for tolerating our discussion!
Paydon
--
XChat-discuss: mailing list for XChat users
Archive: http://mail.nl.linux.org/xchat-discuss/