On Wed, Mar 26, 2008 at 8:48 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
Won't this *dynamic* rate-limiting be decided by TCP-LP congestion control mechanism to use only idle bandwidth? And could someone tell me what problems I might face if I make it to work with yum?
Tomasz Torcz wrote:
>
>> > Module tcp_lp.ko will be autoloaded by kernel. So this setsockopt() call
>> > is ready to be put into yum-updatesd, just after socket creation.
>>
>> A good question then is how do you set congestion level off and not get the
>> kernel module loaded (if its not needed you wouldn't want it loading just to
>> have it do nothing). Does setting TCP_CONGESTION = 0 result in not loading the
>> module or does it just not limit traffic?
>
> That's not how it works. TCP has mechanisms for dealing with congested
> links. There is *always* some algorithm present in TCP stack which
> manipulates connection parameters to not overflow links. By default its
> reno (or cubic), but Linux kernel provides several others to *choose*
> from. This isn't a question of turning limiting ON or OFF.
>
> Anyway, after some more reading I see that TCP Low Priority is
> sender-side algorithm. I don not know if sending ACKs is impacted by
> congestion algorithms, and this is only thing for client to modify
Yes, yum is mostly receiving. An application can control receive
bandwidth simply by rate-limiting its reads from the socket, but it will
have no idea what an appropriate rate might be.
Won't this *dynamic* rate-limiting be decided by TCP-LP congestion control mechanism to use only idle bandwidth? And could someone tell me what problems I might face if I make it to work with yum?
Thanks.
PS: I am really new to this, please forgive me if any question asked doesn't make sense. :)
--
Regards,
Sunil Ghai
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
