On Mon, 10 Apr 2017, Rainer Canavan via curl-library wrote:

>> I'm not entirely sure why that is so, but I'd like to mention that the
>> CURLOPT_LOW_SPEED_TIME handling and its timeouts were just now changed, in
>> commit 29147ade0456a which landed just hours ago.
>
> I can't find that commit anywhere, is that 2d5711dc11 in the github
> repository?

Wow, I don't know how I got that weird hash (probably from a different/wrong
branch) but yes I meant 2d5711dc11.

>> When CURLOPT_LOW_SPEED_TIME is set, libcurl should now use no longer than
>> 1000ms timeouts.
>
> I've just merged 2d5711dc11 into 7.53.1, and I don't really see an
> improvement.

Then we clearly need to debug this more. Can you share code with us that
reproduces this behavior easily ?

> The other thing is that I would have expected CURLOPT_LOW_SPEED_TIME to be
> the actual interval over which the speed is measured, i.e. if a server does
> not send any data for 2 * CURLOPT_LOW_SPEED_TIME seconds, the transfer
> should always fail. The actual implementation uses progress.current_speed,
> which is averaged over longer periods with the result that bursty transfers
> are kept going.

It is an average speed over the last 5 seconds, yes (or less if the transfer
is younger). Transfer speeds with its bursts and what not is not that easy to
get "right" by everyone's view, but I think that this is a decent approach.

Well, that is *after* this recent fix because previously it was actually even
worse! =)

> That's perfectly fine, and probably more useful in reality than how I
> thought it would work, but I would say the documentation could be clearer.

Feel free to suggest improvements to the documentation!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html