Differences between version 18 and predecessor to the previous major change of TrafficShaping.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
Newer page: | version 18 | Last edited on Tuesday, July 19, 2005 11:48:02 am | by IanMcDonald | Revert |
Older page: | version 17 | Last edited on Friday, April 1, 2005 10:14:42 pm | by JohnMcPherson | Revert |
@@ -1,8 +1,8 @@
This describes traffic shaping under linux. This uses the __tc__ (traffic
-control) program from the iproute
package.
+control) program from the IpRoute
package.
-Make sure you have the correct kernel
support for "QoS". In your
+Make sure you have the correct [Kernel]
support for "QoS". In your
LinuxKernel .config file, you will probably need support for the
following:
# CONFIG_NET_SCHED
# CONFIG_NET_SCH_CBQ (support for the cbq class, used in this script)
@@ -286,4 +286,6 @@
If I look at the output of wget, its reasonably good at limiting a port 80 download to 10 - 12k/second, which is about right for what we asked. If i look at my ppp0 usage meter in gkrellm, it seems to be using more bandwidth than it should - spends a lot of time at 16 or 17 K/s incoming. Running iptraf on ppp0, in detailed statistics mode, shows that my incoming rate seems to be about 100kbit/sec, although it tends to be a bit higher than this normally. I also tested, and verified, that traffic not caught by the above script - eg, FTP traffic, still obtained full rate
In comparison with a by-port filter such as the one prior to the ingress script, I see a high level of fluctuation in the download rate, in all three test cases. Whether this is to do with some misconfiguration on my part I dont know.
+----
+See also NetEm for information on simulating loss and delay.