This tutorial shows you how to setup QOS configuration when you are using Coyote or BrazilFW init scripts. It shows you how to setup correct upstream and downstream values and contains information about other QOS configuration options.
QOS is an attempt to control computer network traffic in order to optimize or guarantee performance, low-latency, and/or bandwidth. QOS (Traffic shaping) deals with concepts of classification, queue disciplines, enforcing policies, congestion management, and fairness.
Traffic shaping provides a mechanism to control the amount and volume of traffic being sent into a network (bandwidth throttling), and the rate at which the traffic is being sent (rate limiting). For this reason, traffic shaping schemes need to be implemented at the network edges to control the traffic entering the network. It also may be necessary to identify traffic flows at the ingress point (the point at which traffic enters the network) with a granularity that allows the traffic-shaping control mechanism to separate traffic into individual flows and shape them differently.
Basic QOS configuration is made in Web-admin configuration interface from "QOS configuration" panel. If you choose Coyote (BrazilFW) QOS init scripts, the configuration screen will look like this (click for large picture) ...
Now we will describe what the configuration options meen.
QOS configuration script init type. You can either use Wondershaper configuration or Coyote Linux (BrazilFW) QOS scripts configuration. This tutorial focuses on the second option. You can choose between default config and manual class config.
Real value of your downstream bandwidth..not the value your ISP pretends you have. For QOS to function properly it's very important to setup you downstream and mainly upstream maximal values properly. The correct values is almost every time even lower than the maximum value you download/upload from internet. The explanation of this effect is quite simple. QOS works on the principle of prioritizing some packet on the packet queue. Because the interface between you Coyote(BrazilFW) router and Cable/ADSL/Modem or whatever is a lot faster than your internet connection, if you setup you upstream/downstream speed too high, the queue is not build at the Coyote(BrazilFW) router but at Cable modem for example and QOS does not work.
Same as downstream bandwidth, only for upstream values. We will look how to setup correct values later.
How many percent of total bandwidth (Real Upstream Bandwidth) is used for connections made directly from internet to your Coyote Linux (BrazilFW) router. For example remote administration over the internet, Web server of FTP server on your Coyote Linux (BrazilFW)
Theese are percentage values of bandwidth reserved for priority classes. Ig there is not other traffic, the bandwidth is borrowed to lower priority classes.
Burst size is the limit of transfered data that can be transfered at full speed before any shaping occurs. It's goot for WWW traffic which mades requests in bursts.
It's the time for upstream/downstream values tweaking. First measure your free line latency. You will need your ISP's gateway address. If you don't know it run command prompt on your windows workstation and issue following command.
C:\Documents and Settings\Dolly22>tracert www.google.com the output should look something like this: Tracing route to www.google.akadns.net [188.8.131.52] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms coyote.sporilov.czf [192.168.0.1] 2 10 ms 10 ms 12 ms ac2.mistral.cz [184.108.40.206] 3 18 ms 10 ms 12 ms 1hopsem-v103.dkm.cz [220.127.116.11] ...ISP's gateway address is first public ip address in you tracert list, in my case it's ac2.mistral.cz [18.104.22.168]. You can use any address from your traceroute, but the closer the better (but DO NOT use your coyote linux IP address /by default 192.168.0.1/).
Now measure your free line latency with command
C:\Documents and Settings\Dolly22>ping -n 20 ac2.mistral.cz the output should look something like this: Pinging ac2.mistral.cz [22.214.171.124] with 32 bytes of data: Reply from 126.96.36.199: bytes=32 time=306ms TTL=254 Reply from 188.8.131.52: bytes=32 time=219ms TTL=254 Ping statistics for 184.108.40.206: Packets: Sent = 20, Received = 20, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 8ms, Maximum = 37ms, Average = 14msNote average ping value somewhere. Now look at this info from wonder shaper readme, it has some information what minimal latency you can expect on your connection (when full uploading with QOS enabled). Following text uses MTU term, you can read it from ifconfig output.
substitute eth1 with your inet interface ... brazilfw# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:A0:C9:C5:4B:B7 inet addr:220.127.116.11 Bcast:18.104.22.168 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ^^^^^^^^ ...Now here we go ...
Uplink speed | Expected latency due to upload -------------------------------------------------- 32 | 234ms 64 | 117ms 128 | 58ms 256 | 29ms So to calculate your effective latency, take a baseline measurement (ping on an unloaded link), and look up the number in the table, and add it. That is about the best you can expect. This number comes from a calculation that assumes that your upstream keystroke will have at most half a full sized packet ahead of it. This boils down to: mtu * 0.5 * 10 -------------- + baseline_latency kbit The factor 10 is not quite correct but works well in practice.Count your theoretical mimimal latency and we can start with tweaking. Full up your internet upstream with some transfer (upload to fast ftp server, ...), open command line on your windows workstation and start command
ping -t ac2.mistral.cz ^^^^ substitute with your ISP's gateway output of this command look like this (it goes on forever :)) ... ... Reply from 22.214.171.124: bytes=32 time=159ms TTL=62 Reply from 126.96.36.199: bytes=32 time=179ms TTL=62 Reply from 188.8.131.52: bytes=32 time=347ms TTL=62 Reply from 184.108.40.206: bytes=32 time=283ms TTL=62 Reply from 220.127.116.11: bytes=32 time=329ms TTL=62 ...Your ping values should be quite high now, it's because you have initialized your upstream value with true line upstream. Now slowly lower your real upstream value and see what happens to your pings in other window.
You will have to RELOAD QOS configuration after every change.
Lower the UPSTREAM value, until your pings drop somewhere to theoreticaly computed latency value. Then free your upstream and repeat the same steps for DOWNSTREAM value (fill up downstream and slowly lower DOWNSTREAM value until the pings drop down).
Now save your coyote configuration and voila, you should have QOS set up and running.