Re: [Wget-dev] wget2 | WIP: Implemented limit-rate feature (!420)

[Tim Rühsen]

> please let me know if it is still an issue

No, let's keep it with that.

>  I have also updated the code and added a comment referencing where the 
> algorithm came from (it was influenced by rsync's sleep_for_bwlimit() 
> function)

Very good ! Even when rsync is GPL, such a note is well-thought.

```
$ src/wget2_noinstall --limit-rate=2.5k --progress=bar https://heise.de
Invalid byte specifier: 2.5k
```

> The speed will not print until the bytes ring buffer is full.

Maybe we can 'short-circuit' if the total size in the ring buffer reaches more 
than --limit-rate (if given) and if the second slot has been reached !?
 
>    Test actual download speed is approximately matching limit-rate
>    Test download speed is not affected when limit-rate is not set

This seems sufficient to me. What if we take an existing test, e.g. doing 
recursive downloads of a bunch of small files and add --limit-rate ? 
Balanced/tuned in a way that e.g. it can't take less than 2s. The same without 
--limit-rate should not take longer than a few milliseconds. Of course, the CI 
runner sometimes experience times of very slow operation... but we'll see how 
it works out.

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.com/gnuwget/wget2/merge_requests/420#note_162766032
You're receiving this email because of your account on gitlab.com.