[pacman-dev] [PATCH] pacman: add option --max-recv-speed

[Sami Kerola]

On 7 September 2013 22:36, Dave Reisner <d at falconindy.com> wrote:
> On Sat, Sep 07, 2013 at 10:29:31PM +0100, Sami Kerola wrote:
>> My dad was watching internet connected television, while I decided to
>> check fixes for Arch.  There were new kernel, some libreoffice stuff, and
>> so on making the download to be more than few megabytes.  When I
>> downloaded the packages television sound track was affected annoying way.
>> Obviosly my download was affecting a stream that had greater service
>> quality expectancy.  This patch will allow an user to polite and throttle
>> down bandwidth usage in benefit for others.
>>
>> Signed-off-by: Sami Kerola <kerolasa at iki.fi>
>> ---
>
> I've been extremely hesistant to accept patches that tune the downloader
> -- it really ought to be an invisible thing that "just works". If you
> really need this functionality, I'd suggest using XferCommand in
> /etc/pacman.conf.

Because the libcurl already has everything needed it is just a matter of using
what is provided. Therefore I do not see this as big change, but then again
XferCommand is an alternative which allows to do the same without changes
to pacman code.

>>  doc/pacman.8.txt     |  5 +++++
>>  lib/libalpm/alpm.h   |  5 +++++
>>  lib/libalpm/dload.c  |  4 ++++
>>  lib/libalpm/handle.c | 13 +++++++++++++
>>  lib/libalpm/handle.h |  1 +
>>  src/pacman/conf.c    |  1 +
>>  src/pacman/conf.h    |  2 ++
>>  src/pacman/pacman.c  |  6 ++++++
>>  8 files changed, 37 insertions(+)
>>
>> diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt
>> index 574995c..da8fa1b 100644
>> --- a/doc/pacman.8.txt
>> +++ b/doc/pacman.8.txt
>> @@ -362,6 +362,11 @@ Sync Options[[SO]]
>>       packages that are no longer installed; use two to remove all files
>>       from the cache. In both cases, you will have a yes or no option to
>>       remove packages and/or unused downloaded databases.
>> +
>> +*\--max-recv-speed* <bits>::
>> +     Define maximum transfer rate in bits per seconds. This option is
>> +     useful when network bandwidth is scarce resource, and other users
>> +     of the network has greater service expecations.
>
> One might argue that QoS on a network device is a far better mechanism
> for dictating this rather than hoping that clients tune it on their own.

I agree, it kernel QoS probably more correct, but not quick & easy way to
do limit transfer rate. Something like

/sbin/tc class add dev eth1 parent 1:0 classid 1:10 htb rate 512kbps
ceil 640kbps prio 0

seems to do the trick, if I am reading instructions correctly[1]. But that will
outbound http, not only pacman traffic. Making the traffic shape line smart
enough limit only targets from mirrorlist file feels a bit clumsy.

The other use for --max-recv-speed I can think of is when an user chucks update
to cron, and it does not matter if download takes a moment longer. From
system admin point of view it makes sense to do that, if you are managing
more than handful of installations, and you want to avoid them consuming
(a) bandwidth that was meant for client use, and (b) killing server providing
the packages as numerous servers run updates concurrently.

But since it feels pacman will not support native rate limiting, perhaps the
thing to do is to add the necessary XferCommand line to wiki[2].

[1] http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/
[2] https://wiki.archlinux.org/index.php/Pacman_Tips

-- 
Sami Kerola
http://www.iki.fi/kerolasa/