On Fri, Jun 21, 2024 at 9:54 AM Dmitry Karpov via curl-library < curl-library@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.html
