Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve speed limits, not based on average speeds anymore #971
Speed limits (from CURLOPT_MAX_RECV_SPEED_LARGE & CURLOPT_MAX_SEND_SPEED_LARGE)
Consider a download that goes on much slower than the limit for some time
So instead, we now use a "moving starting point" as reference, and every time at
No, it actually gives different - and less useful - results (and also,
But things aren't as good then, I believe it has to do with the fact
So having a "fixed" starting point to calculate the limit gives much
I don't get that. If the transfer pauses, the
But I agree that it would need to be duplicated (one for each direction) to be possible to be used for this.
So let me check if I understand your suggested algorithm (for a single direction).
Is that what you're proposing?
Well, depends, because the "current speed" is really an average over
Imagine this, with no transfer happening for the last 5s:
t : speed based on amount of data from t-5
It also wouldn't get to the actual current speed right away. That is,
Anyways, because the current speed is in fact the average over the last
Yes. It's a timestamp & amount of data received then, ofc, but yes
FYI, this was inspired from openssh's scp, because after trying to use
Ok, yes that all makes sense. Thanks for explaining. This approach has one additional benefit too: it will support changing the limits in run-time much better than it currently does. That is something that I keep hearing users ask for. I think it could make sense to actually document that fact as well in association with landing this patch.