> Am 30.10.2025 um 14:46 schrieb Stefan Eissing <[email protected]>: > > > >> Am 30.10.2025 um 14:38 schrieb Cristian Rodríguez <[email protected]>: >> >> On Wed, Oct 29, 2025 at 10:47 PM Gleb Smirnoff via curl-library >> <[email protected]> wrote: >> >>> --- a/lib/transfer.c >>> +++ b/lib/transfer.c >>> @@ -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; >>> >>> Thanks! >> >> >> This is on an special BSD system or what? because on Linux this is the >> wrong way of doing it.. the kernel can ratelimit your transfers way >> more efficiently using SO_MAX_PACING_RATE > > That is for outgoing packets, right=
should have been with a question mark... -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
