The results of using youtube-dl to download at 50 kbytes/second:
Basically it uses max bandwidth for a bit, then stops. The average rate is indeed 50 kbytes/sec, but it’s 1 second of 300 kbytes/sec (max rate) followed by 6 seconds of none. Not exactly the intended effect.
I’m not clear on how much a user-space app can even do to throttle bandwidth on a TCP socket like this. I’d assumed they were stalling the pipe, only reading 60 kbytes/second, and the server is filling the pipe and something’s buffering. But that graph looks more like youtube-dl reading the whole buffer all at once, then sleeping a long time.
The code looks like it’s doing something reasonable. If I understand the main loop right, it reads block_size bytes (1024), then sleeps for a carefully calculated amount of time to maintain the rate. So it’s at least trying to read little bits in short intervals, I wonder why it’s not working? I should test it on a faster network and see if it does the same weird thing.
Nelson's log 