[packagekit] SetHints

Richard Hughes hughsient at gmail.com
Mon Dec 6 23:51:59 PST 2010


On 7 December 2010 00:36, Daniel Nicoletti <dantti85-pk at yahoo.com.br> wrote:
> The use case is that some users want to
> be able to tell how much bandwidth it should
> use, changing the download speed yourself
> can't be measured in in a good weight since
> you don't know the user's bandwidth.

Sure you do. The kernel knows how many packets we are dropping on the
floor, and so can do congestion management better than any static
policy.

> Also this option will go to the settings tab
> which most users don't care but those
> who have 3g connections or similar want to
> be able to use the internet while downloading
> packages.

I think your use case is flawed, to be honest. A better use case would be:

"Suzan wants to continue watching a video on youtube and talking to
her friends on pidgin after she just selected openoffice to be
installed."

Of course, if she selected it manually it's going to be downloading
packages at full speed, which may make her download lag. So the smart
thing to do would be (re-)set the "background" parameter to FALSE if
the kpackagekit window is not focused and the user is idle. This might
mean making a few changes so we can continue to call SetHints after
the transaction has started, but nothing major.

The alternative is to just use the "lp" socket parameter for Linux.
This uses idle bandwidth by setting congestion control algorithm to
'TCP Low Priority' which basically means that it only goes fast enough
to not starve the connection from other users.

Putting a static x kb/sec in a UI is a really bad way to solve this
problem, and will never be discovered or used by real end users. I'm
not sure what I would choose as a throttle value, as I go from a
superfast ethernet connection, to wifi, to mobile broadband all in a
typical day. I basically want the packaging system to work, and not
get in my way with what I want to achieve in that day or force me to
change settings that it could work out for itself.

Richard.



More information about the PackageKit mailing list