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