bandwidth 'depredation'
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
Quoted 23 lines · DervishD
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/
Quoted 6 lines · DervishD
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)?
Signature · 1 line
http://function.linuxpower.ca
Quoted 7 lines · DervishD
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
:.........................:
Hi Sean :)
Quoted 1 line
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
Quoted 8 lines · DervishD
Hi Sean :)
Quoted 1 line
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 Kristian :)
Quoted 1 line
Maybe QoS (Quality of Service) is the answer.
All of you say the same. I'll give it a try ;)
Quoted 8 lines
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
Quoted 11 lines · 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.
Quoted 10 lines · Giuliano Pochini
Quoted 8 lines · 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).
Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 8 lines · Alan Cox
Quoted 5 lines
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 :)
Quoted 2 lines
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
Hi Giuliano :)
Quoted 7 lines
Quoted 3 lines
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