limit-rate revisited

Tweaks around handling of --limit-rate:

* tracing: trace outstanding timeouts by name
* multi: do not mark transfer as dirty that have
  an EXPIRE_TOOFAST set
* multi: have one static function to asses speed limits
* multi: when setting EXPIRE_TOOFAST remove the transfers
  from the dirty set
* progress: rename vars and comment on how speed limit
  timeouts are calculated, for clarity
* transfer: when speed limiting, exit the receive loop
  after a quarter of the limit has been received, not
  on the first chunk received.
* cf-ip-happy.c: clear EXPIRE_HAPPY_EYEBALLS on connect
* scorecard: add --limit-rate parameter to test with
  speed limits in effect
This commit is contained in:
Stefan Eissing 2025-09-02 15:16:21 +02:00
parent ad42850b23
commit c5fccfffc6
No known key found for this signature in database
10 changed files with 218 additions and 120 deletions

View file

@ -280,9 +280,10 @@ static CURLcode sendrecv_dl(struct Curl_easy *data,
if(bytestoread && data->set.max_recv_speed > 0) {
/* In case of speed limit on receiving: if this loop already got
* data, break out. If not, limit the amount of bytes to receive.
* The overall, timed, speed limiting is done in multi.c */
if(total_received)
* a quarter of the quota, break out. We want to stutter a bit
* to keep in the limit, but too small receives will just cost
* cpu unnecessarily. */
if(total_received >= (data->set.max_recv_speed / 4))
break;
if(data->set.max_recv_speed < (curl_off_t)bytestoread)
bytestoread = (size_t)data->set.max_recv_speed;
@ -958,3 +959,15 @@ CURLcode Curl_xfer_pause_recv(struct Curl_easy *data, bool enable)
Curl_conn_ev_data_pause(data, enable);
return result;
}
bool Curl_xfer_is_too_fast(struct Curl_easy *data)
{
struct Curl_llist_node *e = Curl_llist_head(&data->state.timeoutlist);
while(e) {
struct time_node *n = Curl_node_elem(e);
e = Curl_node_next(e);
if(n->eid == EXPIRE_TOOFAST)
return TRUE;
}
return FALSE;
}