[packagekit] Throttling yum backend

[Robin Norwood]

On Wed, 13 Feb 2008 20:27:01 +0000
Richard Hughes <hughsient at gmail.com> wrote:

> On Wed, 2008-02-13 at 14:46 -0500, Robin Norwood wrote:
> > Currently the yum backend is always throttled to "40%".  IIRC, the
> > idea behind this was to prevent PK from gobbling all of the user's
> > bandwidth.  However, that makes PK slower for *all* operations,
> > including interactive ones when I'm staring at the computer screen
> > waiting for stuff to happen.  I think the backend should only ask to
> > throttle for non-interactive sessions - like when the auto-updater
> > is running.
> 
> Sure. We need windows BITS :-)

Perfect!

> > We could also be smarter in different ways - for instance, no
> > throttling for searching and other queries, 90% throttle for
> > download+install packages, and 40% throttle for background usage.
> 
> Sure, we can certainly be smarter about it.
> 
> > Also, there are two ways to approach it - either explicit throttling
> > for backends that support it, where the client/engine send a
> > "Throttle 40" signal
> 
> Once we've started the backend command it's not easy to add extra
> parameters. Ideas welcome if so.
> 
> > implicit throttling where the client/engine gives the
> > backend some more information about the context ('Interactive mode'
> > or something), and the backend decides how to handle that.
> 
> Sure, but we can't just do this at method invocation, as the situation
> will change, e.g. the user minimizing the window.
> 
> Personally, I think telling the backend more information (and continue
> to do) is the only way we can do this.

I don't think trying to adjust the throttle in the middle of a backend
action is nearly as much of a win as picking a sane throttle before
beginning the action.  In fact...come to think of it, the biggest, most
annoying bandwidth-sucker is going to be the 'update-system' call.
That's the on that people are least likely to be staring at the screen
waiting for things to happen.  I think it would get us 75% of the way
there to just throttle that one, and leave everything else in
'unthrottled' mode.  For most other actions, I'm actually going to be
waiting for it to finish.

If you want to get fancier, we could do 'InteractiveMode' and...er...
'NoninteractiveMode' signals.  

Use cases?

1. Searching for a package.
  - Clearly I'm waiting for the UI to return, and want no throttling.

2. Getting details about a package.
  - Same as #1

3. Installing a package.
  - I'm probably installing it because I want to use it, ASAP.  I might
be staring at the UI, or I might have gone to do something else, but
still, I want the package and I want it now.  No throttling.

4. Updating a (single) package.
  - I'm updating it because I want to use the latest version.  Same as
#3.

5. Updating the system.
  - This is the interesting one.  It splits into three-ish cases:

  5a: Non-interactive, while I'm not using the computer
    - I don't care how much bandwidth you take (unless I'm serving or
      downloading something else, but even then, it's the OSes job to
      make sure one process doesn't swamp the others).
    - I don't really care how long it takes either - except that it
      would be nice if it was done before I got back.
    So I think a reasonable amount of throttling would be acceptable,
    but not really necessary. Maybe 75% - 100% (no throttling)

  5b: Non-interactive, while I'm doing something else with the computer.
    - I don't want you to take major amounts of bandwidth away from my
      internet browsing/wesnoth playing.
    - I might not care too much about how long it takes, but again, a
      reasonable amount of time is good.
    So maybe 40% - 75% throttling.

  5c: Interactive
    - I'm eagerly watching the progress bar.  I really want my system
      updated now.
    - As long as you don't take 'all' of my bandwidth, I want this done
      as fast as possible.
   Who does this?  The only possibility I can think of is when I'm
   downloading a bunch of security updates, and want them installed so
   I can reboot/restart services and know that I'm secure.


So, I think a really simple policy of no, or very little throttling
(90%) most of the time, and a moderate amount of throttling during the
'update system' call (60%-75%) will serve most users well.  A bit of a
value add if we bump the throttle to 90-100% when doing an 'update
system' that includes security updates.

I don't think this warrants an overly complex system.  I'd advocate
switching the current backends to do 90% throttle most of the time, and
60% throttle during update-system calls will get us close.  We can add
some sort of hint when doing an update-system that includes security
errata later.

(In case it isn't clear, 100% throttle is the same as 'do not
throttle'.)

 -RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching