Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Increase in CPU usage in 8.7.1 vs 8.6.0 for rate-limited downloads
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: David Pfitzner via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 21 Jun 2024 14:15:12 +0930
On Fri, Jun 21, 2024 at 9:54 AM Dmitry Karpov via curl-library <
curl-library_at_lists.haxx.se> wrote:
>
> - Given such an option, then when desired you could also use it to
> specify _more_ precision than the current default behavior provides.
>
> Actually, the current behavior is quite precise and stable.
>
> I tested it on a wide variety of download sizes and network speeds, and
> the measured speed deviations in all my test cases were always less than 2%.
> Not sure, if anyone would need more precise speed limits than that.
>
I disagree. If you see my other message I give formulas (confirmed by
testing) for the maximum timing error in each case, and even for 8.7.1 you
can have 100% error in the timing if you choose the "right" parameters.
>
> Whereas the new changes that added less precise speed limits in 8.6.0 but
> with a bit less CPU utilization introduced very varying throttled speeds
> with observed speed deviations above 20% in some cases.
> Such large and not stable speed deviations were obvious regression
> compared to the previous versions, like 7.84.
>
> I was thinking about build option because I couldn’t envision that some
> application would want to use both reliable and unreliable speed limits in
> different transfers.
> For me, it is either needed to use reliable speed limits in all
> application transfers (my case) or application doesn’t care about speed
> limit precision at all.
>
I disagree with the characterization of 8.6.0's timing as "reliable" and
8.7.1's as "unreliable". There is a continuum of accuracy, and they are
just at two points on that continuum (and somewhat arbitrary points, as far
as I can tell). I could imagine wanting different tolerance for different
transfers: For example, if you care more about the relative accuracy but
the configuration is for the absolute accuracy, then you might choose a
different tolerance for each transfer. But even without that, in my case I
would certainly want to specify the level of tolerance at run-time rather
than at compile time.
>
> Also, providing code for both precise and not precise speed limits on
> per-handle basis, will definitely increase the libcurl size, which may be
> critical for embedded systems (my case again).
>
Again, the timing accuracy is a continuum, not binary, and a new option
would be basically selecting a point on that existing continuum, so the
code size increase would be negligible, IMO.
-- David
Date: Fri, 21 Jun 2024 14:15:12 +0930
On Fri, Jun 21, 2024 at 9:54 AM Dmitry Karpov via curl-library <
curl-library_at_lists.haxx.se> wrote:
>
> - Given such an option, then when desired you could also use it to
> specify _more_ precision than the current default behavior provides.
>
> Actually, the current behavior is quite precise and stable.
>
> I tested it on a wide variety of download sizes and network speeds, and
> the measured speed deviations in all my test cases were always less than 2%.
> Not sure, if anyone would need more precise speed limits than that.
>
I disagree. If you see my other message I give formulas (confirmed by
testing) for the maximum timing error in each case, and even for 8.7.1 you
can have 100% error in the timing if you choose the "right" parameters.
>
> Whereas the new changes that added less precise speed limits in 8.6.0 but
> with a bit less CPU utilization introduced very varying throttled speeds
> with observed speed deviations above 20% in some cases.
> Such large and not stable speed deviations were obvious regression
> compared to the previous versions, like 7.84.
>
> I was thinking about build option because I couldn’t envision that some
> application would want to use both reliable and unreliable speed limits in
> different transfers.
> For me, it is either needed to use reliable speed limits in all
> application transfers (my case) or application doesn’t care about speed
> limit precision at all.
>
I disagree with the characterization of 8.6.0's timing as "reliable" and
8.7.1's as "unreliable". There is a continuum of accuracy, and they are
just at two points on that continuum (and somewhat arbitrary points, as far
as I can tell). I could imagine wanting different tolerance for different
transfers: For example, if you care more about the relative accuracy but
the configuration is for the absolute accuracy, then you might choose a
different tolerance for each transfer. But even without that, in my case I
would certainly want to specify the level of tolerance at run-time rather
than at compile time.
>
> Also, providing code for both precise and not precise speed limits on
> per-handle basis, will definitely increase the libcurl size, which may be
> critical for embedded systems (my case again).
>
Again, the timing accuracy is a continuum, not binary, and a new option
would be basically selecting a point on that existing continuum, so the
code size increase would be negligible, IMO.
-- David
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-06-21