Hello all :))
I've noticed that, when using certain programs like 'wget', the
bandwidth seems to be 'depredated' by them. When I download a file
with lukemftp or with links, the bandwidth is then distributed
between all IP clients, but when using wget or some ftp clients, it
is not distributed. BTW, I'm using an ADSL line (128 up / 256 down).
IMHO, the IP layer (well, in this case the TCP layer) should
distribute the bandwidth (although I don't know how to do this), and
the kernel seems to be not doing it.
I don't know if this is the intended behaviour or even if this is
a kernel fault or not, but I think that is not good ;)
Thanks :)
Ra?l
Build a kernel with traffic classifaction and CBQ, and use "tc".
See the howtos.
Sean
On Tue, Jun 11, 2002 at 09:44:46AM +0200, DervishD wrote:
> Hello all :))
>
> I've noticed that, when using certain programs like 'wget', the
> bandwidth seems to be 'depredated' by them. When I download a file
> with lukemftp or with links, the bandwidth is then distributed
> between all IP clients, but when using wget or some ftp clients, it
> is not distributed. BTW, I'm using an ADSL line (128 up / 256 down).
>
> IMHO, the IP layer (well, in this case the TCP layer) should
> distribute the bandwidth (although I don't know how to do this), and
> the kernel seems to be not doing it.
>
> I don't know if this is the intended behaviour or even if this is
> a kernel fault or not, but I think that is not good ;)
>
> Thanks :)
> Ra?l
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
DervishD <[email protected]> wrote:
> Hello all :))
>
> I've noticed that, when using certain programs like 'wget', the
> bandwidth seems to be 'depredated' by them. When I download a file
> with lukemftp or with links, the bandwidth is then distributed
> between all IP clients, but when using wget or some ftp clients, it
> is not distributed. BTW, I'm using an ADSL line (128 up / 256 down).
Maybe QoS (Quality of Service) is the answer. It does a lot of things for you, i.e. enabling a scheduler for your network, that shares your traffic correctly. But please don't ask me how it exactly works. I haven't enough time yet to get this nice piece working. You need iproute2-utils for this. (They should be shipped with your distri, "which tc" tells you.)
There're several HOWTOs about this topic. A good address is netfilter.kernelnotes.org where you can find the "Advanced Routing HOWTO" or the Unreliable Guides from Rusty.
Hope this helps.
*Kristian
:... [snd.science] ...:
:: _o)
:: http://www.korseby.net /\\
:: http://gsmp.sf.net _\_V
:.........................:
On Tue, 11 Jun 2002, DervishD wrote:
> IMHO, the IP layer (well, in this case the TCP layer) should
> distribute the bandwidth (although I don't know how to do this), and
> the kernel seems to be not doing it.
>
> I don't know if this is the intended behaviour or even if this is
> a kernel fault or not, but I think that is not good ;)
QoS (CONFIG_NET_SCHED)?
--
http://function.linuxpower.ca
On Tue, Jun 11, 2002 at 12:26:39PM +0200, DervishD wrote:
>
> Hi Sean :)
>
> >Build a kernel with traffic classifaction and CBQ, and use "tc".
>
> Oops :(( I thought that it was easier...
>
> Well, thanks. I'll take a look at the tc documentation :)
I should have added "QoS". In fact, you may be able to do some of this without
too much complexity.
Sean
Hi Sean :)
>Build a kernel with traffic classifaction and CBQ, and use "tc".
Oops :(( I thought that it was easier...
Well, thanks. I'll take a look at the tc documentation :)
Ra?l
Hi Kristian :)
>Maybe QoS (Quality of Service) is the answer.
All of you say the same. I'll give it a try ;)
>It does a lot of things for you, i.e. enabling a scheduler for your
>network, that shares your traffic correctly.
>But please don't ask me
>how it exactly works. I haven't enough time yet to get this nice
>piece working.
>You need iproute2-utils for this. (They should be
>shipped with your distri, "which tc" tells you.)
I'll have them. I use just 'ip' by now, but I have also 'tc'.
Thanks a lot for your answer :)
Raul
On 11-Jun-2002 DervishD wrote:
> Hello all :))
>
> I've noticed that, when using certain programs like 'wget', the
> bandwidth seems to be 'depredated' by them. When I download a file
> with lukemftp or with links, the bandwidth is then distributed
> between all IP clients, but when using wget or some ftp clients, it
> is not distributed. BTW, I'm using an ADSL line (128 up / 256 down).
>
> IMHO, the IP layer (well, in this case the TCP layer) should
> distribute the bandwidth (although I don't know how to do this), and
> the kernel seems to be not doing it.
No, IP doesn't balance anything. You have to filter the traffic with
QoS of traffic shapers to give different "priorities" to packets as
you like. Wget doesn't "grab" the bandwidth, it's the remote server
that fills it.
Bye.
On Tue, 11 Jun 2002, Giuliano Pochini wrote:
>
> On 11-Jun-2002 DervishD wrote:
> > Hello all :))
> >
> > I've noticed that, when using certain programs like 'wget', the
> > bandwidth seems to be 'depredated' by them. When I download a file
> > with lukemftp or with links, the bandwidth is then distributed
> > between all IP clients, but when using wget or some ftp clients, it
> > is not distributed. BTW, I'm using an ADSL line (128 up / 256 down).
> >
> > IMHO, the IP layer (well, in this case the TCP layer) should
> > distribute the bandwidth (although I don't know how to do this), and
> > the kernel seems to be not doing it.
>
> No, IP doesn't balance anything. You have to filter the traffic with
> QoS of traffic shapers to give different "priorities" to packets as
> you like. Wget doesn't "grab" the bandwidth, it's the remote server
> that fills it.
This is my understanding, too.
But so how is QoS going to change things? It's the output queue of
the router on the other side of the ADLS link that needs management
(and maybe you need to speak some protocol like RSVP), or am I missing
something? How can you control the rate of *incoming* packets per
connection / protocol?
.TM.
Hi Giuliano :)
>> IMHO, the IP layer (well, in this case the TCP layer) should
>> distribute the bandwidth (although I don't know how to do this), and
>> the kernel seems to be not doing it.
>No, IP doesn't balance anything. You have to filter the traffic with
>QoS of traffic shapers to give different "priorities" to packets as
>you like. Wget doesn't "grab" the bandwidth, it's the remote server
>that fills it.
Now I know it, but I don't understand how shaping the outgoing
traffic will help with my incoming traffic O:)
Thanks for answering :)
Ra?l
> But so how is QoS going to change things? It's the output queue of
> the router on the other side of the ADLS link that needs management
> (and maybe you need to speak some protocol like RSVP), or am I missing
> something? How can you control the rate of *incoming* packets per
> connection / protocol?
For tcp it works fine. You drop stuff late but it still triggers
backoffs as needed
On Wed, Jun 12, 2002 at 08:08:49AM +0100, Alan Cox wrote:
>> But so how is QoS going to change things? It's the output queue of
>> the router on the other side of the ADLS link that needs management
>> (and maybe you need to speak some protocol like RSVP), or am I missing
>> something? How can you control the rate of *incoming* packets per
>> connection / protocol?
> For tcp it works fine. You drop stuff late but it still triggers
> backoffs as needed
Some queues (like my dialup access queue once upon a time)
are pathologically overprovisioned, making for too much
delay and poor sharing, before drops bring the tcp flow in
line.
Since nobody runs TCP Vegas, my personal favorite trick is
to play with the receiver's advertised window size. With a
256kbps downstream rate DSL line, one could assert "I'll
never talk to anyone more than 0.2 seconds round trip away"
and decide that 256,000/8/5 = 6400 bytes is as large a
window as TCP needs, and that the default of 64K is
excessive. So, "echo 16636 >
/proc/sys/net/core/rmem_default" and experience lower
latency, higher-fairness networking. The bandwidth
available to the remote server is the same (limited by the
access link) but the extra packets it can queue in flight
are limited. Note that there may be a better way to set the
receive buffer space, and I forget if there's a halving in
there, which is part of why I said 'echo 16k', so you may
want to play around with some different values.
Or, do ugly things to the kernel to automatically tune the
advertised window based on the traffic mix and round trip
times to get a sort of managed receiver-side Vegas as in
http://www.ieee-infocom.org/2000/papers/600.ps (shameless
plug, but a fun little project when you want to read mail
and update Debian at the same time over a poorly managed
modem).
It's just an idea; people forget that the receiver does have
a way to limit the sender's rate in TCP without waiting for
a loss.
enjoy,
-neil
Hi Neil :)
>So, "echo 16636 > /proc/sys/net/core/rmem_default" and
>experience lower latency, higher-fairness networking.
Hey, thanks. I will try this first, before trying Traffic Control.
Ra?l