Daniel Stenberg wrote:
> On Thu, 22 Jan 2009, Yoav Steinberg wrote:
>
>> The problem is that since throttling is calculated based on cumulative
>> average during the entire transfer, the result of changing the speed
>> limit during a transfer is that we get a few seconds of no transfer at
>> all when reducing the limit or a few seconds of unlimited transfer
>> speed when increasings the limit. This leads to other problems like
>> the connection dying because of no transfer when reducing the speed.
>>
>> To solve this I guess I'll need to change the speed calculation based
>> on some sliding window average and not based on the entire transfer.
>> Before I start playing around with the transfer speed calculation code
>> to achieve this, I'd like to know why a cumulative average approach
>> was chosen in the first place.
>
> I think we did it that way simply because it was simple and not too wrong.
>
> I would agree that a sliding window probably is a better approach, and
> in case you want to change the speed limitation in the middle it'd be
> more or less required.
>

Looking at the Curl_pgrsUpdate() again, it seems there's a sliding
window already implemented for calculating the current_speed. Currently
current_speed is only used for checking the CURLOPT_LOW_SPEED_LIMIT
parameter. But it seems to me it can be used for the
CURLOPT_MAX_SEND/RECV_SPEED_LARGE parameters as well. This will result
in a more accurate calculation for bandwidth limiting, make code simpler
by reducing the speed calculation algorithms to one instead of the two
different approaches taken today, and enable changing the bandwidth
limitation while doing transfers.
Does that sound right?
Received on 2009-01-25