>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@xxxxxxxxx> wrote:
The problem is you need to decide what 40% of 'the bandwidth' actually is, andSunil 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.."
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.
Won't pretty much all mirrors supporting http handle that. The mirrors with ftp
> 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..
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@xxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Sunil Ghai
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
