Updates using idle bandwidth

Sunil Ghai sunilkrghai at gmail.com
Tue Mar 4 20:32:41 UTC 2008


>problem is you need to decide what 40% of 'the bandwidth' actually is, and
>in general you do not know that if you're not paying attention to what
maximum
>has been achieved.  Anything else is a guess.  If you really want users to
feel
>like all their extra bandwidth is getting used without interfering with
traffic
>they want to move you cannot guess there, because tcp will back down on
both
>connections as soon as it detects congestion if they aren't prioritized.
 You
>would need a mechanism to remember how fast a user's connection really is.

Yep, setting priority is necessary otherwise the solution will not work and
I think I'll face more problems while implementing but I want to work on
this because me and many people have been facing the same problem for a long
time. Just waiting to get over with my university exams, then I'll start
working, perhaps through Google Summer of Code..

On Mon, Mar 3, 2008 at 4:37 PM, Andrew Farris <lordmorgul at gmail.com> wrote:

> Sunil Ghai wrote:
> >> I'm not clear on whether the 'throttle' and 'bandwidth' configuration
> would
> >> apply to yum-updatesd.  It would still not be a dynamic adjustment but
> if
> > users
> >> knew how this worked it might be a good enough solution.
> >
> > That would not be the solution in real sense. What if someone wants to
> > download another important file? A mechanism is needed to stop
> downloading
> > the updated packages when the file is being downloaded. When it is done,
> we
> > can resume updating the system.
> >
> >> We have TCP Low Priority� congestion algorithm in kernel. yum-updatesd
> >> should request it on downloading socket via setsockopt(), as per commit
> >> bc0efe7b46174fa3cadf00ac64e4a751cc4619fd .
> >
> > This might help me. Could you please provide me some more pointers?
> >
> >> One problem I see with this is that bandwidth statistics from are reset
> > when
> >> you reboot the machine. Unless you keep the machine up all the time it
> will
> > lose track
> >> of the exact amount of bandwidth used up. Maybe another daemon will
> need to
> > keep track of
> >> this?
> > We actually don't need this kind of thing. For example, if currently 60%
> of
> > the bandwidth is in usage, 40% is idle, we can use this idle bandwidth
> to
> > download updated packages.Once the list of updated packages has been
> > prepared, we can start downloading them and if the user shuts down the
> > machine, next time we can resume downloading the packages where we left
> off.
> > In this way user would never feel that the system is actually being
> updated,
> > he or she will just get the message that "The system has been updated.."
>
> The problem is you need to decide what 40% of 'the bandwidth' actually is,
> and
> in general you do not know that if you're not paying attention to what
> maximum
> has been achieved.  Anything else is a guess.  If you really want users to
> feel
> like all their extra bandwidth is getting used without interfering with
> traffic
> they want to move you cannot guess there, because tcp will back down on
> both
> connections as soon as it detects congestion if they aren't prioritized.
>  You
> would need a mechanism to remember how fast a user's connection really is.
>
> > Problem is this requires server support from where the packages are
> coming.
> > Each repository server would require to support asynchronous file
> > transfer..I am doubtful here..
>
> Won't pretty much all mirrors supporting http handle that.  The mirrors
> with ftp
> probably won't, so users may need to manually set their chosen mirror to
> make
> use of what you're trying to do?
>
> --
> Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
>  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B
> 1DF3
> No one now has, and no one will ever again get, the big picture. - Daniel
> Geer
> ----
> ----
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Sunil Ghai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080304/b791e958/attachment.htm>


More information about the fedora-devel-list mailing list