tags 856473 + patch tags 868059 + patch tags 878602 + patch tags 879854 + patch thanks
diff --git a/debian/changelog b/debian/changelog index f3853334..bb0101b2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +iproute2 (4.14.1-0.1) UNRELEASED; urgency=medium + + * New upstream release (Closes: #856473, #868059, #878602, #879854) + + -- Julian Wollrath <jwollr...@web.de> Mon, 20 Nov 2017 10:51:35 +0100 + iproute2 (4.9.0-2) unstable; urgency=medium * Let uscan verify signature of upstream tarball diff --git a/debian/compat b/debian/compat index ec635144..f599e28b 100644 --- a/debian/compat +++ b/debian/compat @@ -1 +1 @@ -9 +10 diff --git a/debian/control b/debian/control index b98fbe81..499e3cf5 100644 --- a/debian/control +++ b/debian/control @@ -5,10 +5,9 @@ Maintainer: Alexander Wirt <formo...@debian.org> Homepage: https://wiki.linuxfoundation.org/networking/iproute2 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/pkg-iproute.git Vcs-Git: https://anonscm.debian.org/git/collab-maint/pkg-iproute.git -Standards-Version: 3.9.8 +Standards-Version: 4.1.1 Build-Depends: bison, - cm-super-minimal, - debhelper (>= 9), + debhelper (>= 10), flex, iptables-dev, libatm1-dev, @@ -17,13 +16,8 @@ Build-Depends: bison, libmnl-dev, libselinux1-dev, linux-libc-dev, - linuxdoc-tools, - lynx | lynx-cur, pkg-config, - texlive-fonts-recommended, - texlive-latex-base, - texlive-latex-extra, - texlive-latex-recommended + zlib1g-dev Package: iproute2 Priority: important @@ -54,23 +48,3 @@ Description: networking and traffic control tools - documentation traffic control. . This package contains the documentation for iproute. - -Package: iproute -Depends: iproute2, ${misc:Depends} -Architecture: all -Section: oldlibs -Priority: extra -Description: transitional dummy package for iproute2 - This is a transitional dummy package to get upgrading systems to install - the iproute2 package. It can safely be removed once no other package - depends on it. - -Package: iproute-doc -Depends: iproute2-doc, ${misc:Depends} -Architecture: all -Section: oldlibs -Priority: extra -Description: transitional dummy package for iproute2-doc - This is a transitional dummy package to get upgrading systems to install - the iproute2-doc package. It can safely be removed once no other package - depends on it. diff --git a/debian/doc/htb/htbfaq.htm b/debian/doc/htb/htbfaq.htm deleted file mode 100644 index 4ab2a78b..00000000 --- a/debian/doc/htb/htbfaq.htm +++ /dev/null @@ -1,141 +0,0 @@ -<html><head><title>HTB FAQ</title></head> -<body> -<h1><center>HTB FAQ</center></h1> -<center><address> -Martin Devera aka devik (de...@cdi.cz)<br> -Last updated: 7.7.2003 -</address></center> -<br> -<b>How to set single HTB up for more interfaces or for incoming packets</b> -<p> -You need IMQ for this because all qdisc can handle only outgoing -traffic on single interface. See -<a href="http://www.linuximq.net/";>http://www.linuximq.net/</a>. -<p> -<b>When HTB is used on machine with Apache (FTP, Samba, ...) server running - then downloading from it can't be limited precisely</b> -<p> -Try to add PFIFO with limit 10 under HTB classes. When you use default -(much larger PFIFO) or SFQ then TCP stack will back off itself as it -see too large memory used for outgoing packets. You can also play -with /proc/sys/net/ipv4/tcp_wmem. -<p> -<b>"HTB: mindelay=500, report it please !" messages in syslog</b> -<p> -This means that all indicated that some class should be ready -soon but when we looked for it we haven't found one which will -be ready in 5 seconds. -<br> -After this message you can see lines like -<pre> -kernel: htb*g j=154480191 -kernel: htb*r7 m=0 -kernel: htb*r6 m=0 -kernel: htb*r5 m=0 -kernel: htb*r4 m=0 -kernel: htb*r3 m=0 -kernel: htb*r2 m=0 -kernel: htb*r1 m=0 -kernel: htb*r0 m=0 -kernel: htb*c20110 m=2 t=636487 c=17888 pq=0 df=483328 ql=0 pa=0 f: -kernel: htb*c20220 m=1 t=-59999999 c=42404 pq=154487461 df=450560 ql=14 pa=40 f: -kernel: htb*c20001 m=2 t=5131 c=6439 pq=0 df=8192 ql=0 pa=0 f: -</pre> -If you decide to treat is as real bug then I'll need all of these. They -are logged under kernel.debug facility so often you need to add it so -your syslog.conf. These "htb*" are dump of internal state of all classes. -c20110 means class 2:110. *r lines are states of row activity bitsmasks. -*c indicates stet of all classes. You are interested in classes -with m=1 resp. m=0. These will become ready after time -c resp. -t whatever -is negative and smaller. -It is 59999999 us for class 2:110 above which is 59sec. It is way too much -and HTB will spill that error because it is > 5 sec. -<p> -<i>So what is the problem ?</i> Probably you have too small rate or ceil -for such class - you should use at least 4kbit for realiable operation -of HTB - it leads to max 3sec of delay for 1500 byte packets which seems -as reasonable value. -<br> -Also try <a href=v3/htb_3.7_delay_bug.patch>this</a> patch against 2.4.20. -(works against older too with one reject). It increases timeout to -10secs and makes errors more readable. -<i>I'm interested in your experiences (good or bad) with the patch !</i> -<br> -If you think it is not the case and you still get weird errors, contact -me with syslog data above and output of commands -<pre> -tc -s -d qdisc -tc -s -d class show dev your_htb_device1_here -tc -s -d class show dev your_htb_device2_here -... -</pre> - -<p> -<b>Why HTB sharing setup works with eth0 but on lo (loopback) - it exhibits weird rates ? -</b> -<p>Try to execute -<pre> -ifconfig lo mtu 1500 -</pre> -or use parameter mtu 16400 on "tc qdisc add" line. It is because -HTB reserves rate table for 1500 bytes long packets and loopback -uses 16384 as default. -<p> -<b>What's difference between kbps and kbit ? -</b> -<p> -1kbps=8kbit. Don't forget it ! -<p> -<b>What if sum of child rates is smaller than parent rate ? -</b> -<p> -It is like if you create unused child with remaining rate - the -rate difference is divided between other children. -<p> -<b>What if sum of child rates is greater than parent rate ? -</b> -<p> -Then interesting things can happen. Total rate delivered -by children can be higher that parent's rate (thus its rate -is not respected). However when sum of actual child rates are -under parent's rate then borrowing will occur like in regular case. -<p> -I use setup with 4 classes, parent has rate=ceil=6kbps, child -"mail" has rate=1kbps ceil=4kbps, "web" has rate=ceil=15kbps -and "other" has rate=2kbps ceil=4kbps. -HTB is attached to an PPP interface with compressed multilink pair -of modems which can go from 6kbps to cca 16kbps (depends on compresability -of data). When "web" traffic is present it can go as high as compression -allows while still allowing mail 1kbps and other 2kbps. -<br> -When "web" traffic is smaller than 6kbps then "mail" and "other" -can borrow more bw up to 4k each. -Parent's class it not set to 18k because then "mail" and "other" -could get as much as 8k which is more that link's minimum and -would saturate the link. Thus I set parent to 6k so that -"mail"+"other" are limited to 6k while "web" can go over. -<p> -You can do similar setup by using one more class and deeper hierarchy -but this is just to show you the possibility. -<p> -<b>"RTNETLINK answers: Invalid argument" and tc parameters are correct -</b> -<p> -Probably you use tc tool not suited for HTB in kernel. Reread -main HTB page section Downloads. -<p> -<b>All packets are dropped when "default" is set to nonleaf -</b> -<p> -Yes. Default kwyword must point to leaf or be 0 (so unclassified -packets go thru directly). If you want to "direct" other packets -to non-leaf do it by catch all filter with the largest "pref". -<p> -<b>What tool was used to create graphs in HTB manual ? -</b> -<p> -It is proprietary tool called ethloop -(<a href=http://luxik.cdi.cz/~devik/qos/ethloop/>luxik.cdi.cz/~devik/qos/ethloop/</a>). - -</body></html> diff --git a/debian/doc/htb/userg.htm b/debian/doc/htb/userg.htm deleted file mode 100644 index 8abc7bdb..00000000 --- a/debian/doc/htb/userg.htm +++ /dev/null @@ -1,449 +0,0 @@ -<html><head><title>HTB manual - user guide</title></head> -<body> -<h1><center>HTB Linux queuing discipline manual - user guide</center></h1> -<center><address> -Martin Devera aka devik (de...@cdi.cz)<br> -Manual: devik and Don Cohen<br> -Last updated: 5.5.2002 -</address></center> -<br> -New text is in red color. Coloring is removed on new text -after 3 months. Currently they depicts HTB3 changes<p> -<p> -<ul> -<li><a href=#intro>1. Introduction</a> -<li><a href=#sharing>2. Link sharing</a> -<li><a href=#hsharing>3. Sharing hierarchy</a> -<li><a href=#ceiling>4. Rate ceiling</a> -<li><a href=#burst>5. Burst</a> -<li><a href=#prio>6. Priorizing bandwidth share</a> -<li><a href=#stats>7. Understanding statistics</a> -<li><a href=#err>8. Making, debugging and sending error reports</a> -</ul> -<a name=intro><h2>1. Introduction</h2> - -HTB is meant as a more understandable, intuitive and faster replacement for the -CBQ qdisc in Linux. Both CBQ and HTB help you to control the -use of the outbound bandwidth on a given link. Both allow you to use -one physical link to simulate several slower links and to send different -kinds of traffic on different simulated links. In both cases, you have -to specify how to divide the physical link into simulated links and how -to decide which simulated link to use for a given packet to be sent. -<p> -This document shows you how to use HTB. -Most sections have examples, charts (with measured data) and -discussion of particular problems. -<p> -This release of HTB should be also much more scalable. See -comparison at HTB home page. -<p> -<b>Please read:</b> tc tool (not only HTB) uses shortcuts to denote units -of rate. <b>kbps</b> means kilo<b>bytes</b> and <b>kbit</b> means -<b>kilobits</b> ! This is the most FAQ about tc in linux. -<p> - -<a name=sharing><h2>2. Link sharing</h2> -<img src=Ag2Leaf3flat.gif align=right> - -<i>Problem: We have two customers, A and B, both connected to the -internet via eth0. We want to allocate 60 kbps to B and 40 kbps to A. -Next we want to subdivide A's bandwidth 30kbps for WWW and 10kbps -for everything else. Any unused bandwidth can be used by any class -which needs it (in proportion of its allocated share).</i> -<p> -HTB ensures that <b> the amount of service provided to each class is -at least the minimum of the amount it requests and the amount assigned -to it</b>. When a class requests less than the amount assigned, the -remaining (excess) bandwidth is distributed to other classes which request -service.<p> -Also see document about HTB internals - it -describes goal above in greater details. -<p> -<i>Note: In the literature this is called "borrowing" the excess bandwidth. -We use that term below to conform with the literature. We mention, however, -that this seems like a bad term since there is no obligation to repay the -resource that was "borrowed". -</i> -<p> -The different kinds of traffic above are represented by classes in -HTB. The simplest approach is shown in the picture at the right. -<br> -Let's see what commands to use: -<pre> -tc qdisc add dev eth0 root handle 1: htb default 12 -</pre> -This command attaches queue discipline HTB to eth0 and gives it the -"handle" <b>1:</b>. -This is just a name or identifier with which to refer to it below. -The <b>default 12</b> -means that any traffic that is not otherwise classified will be assigned -to class 1:12. -<p> -<i>Note: -In general (not just for HTB but for all qdiscs and classes in tc), -handles are written x:y where x is an integer identifying a qdisc and -y is an integer identifying a class belonging to that qdisc. The handle -for a qdisc must have zero for its y value and the handle for a class -must have a non-zero value for its y value. The "1:" above is treated -as "1:0". -</i> -<p> -<pre> -tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps -tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps -tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps -tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps -</pre> -<p> -The first line creates a "root" class, 1:1 under the qdisc 1:. -The definition of a root class is one with the htb qdisc as its parent. -A root class, like other classes under an htb qdisc allows its children -to borrow from each other, but one root class cannot borrow from another. -We could have created the other three classes directly under the htb qdisc, -but then the excess bandwidth from one would not be available to the others. -In this case we do want to allow borrowing, so we have to create an extra -class to serve as the root and put the classes that will carry the real data -under that. These are defined by the next three lines. -The <b>ceil</b> parameter is described below. -<p><i>Note: Sometimes people ask me why they have to repeat <b>dev eth0</b> -when they have already used <b>handle</b> or <b>parent</b>. The reason -is that handles are local to an interface, e.g., eth0 and eth1 could each -have classes with handle 1:1.</i> -<p> -We also have to describe which packets belong in which class. -This is really not related to the HTB qdisc. See the tc filter -documentation for details. The commands will look something like this: -<pre> -tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ - match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10 -tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ - match ip src 1.2.3.4 flowid 1:11 -</pre> -(We identify A by its IP address which we imagine here to be 1.2.3.4.) -<p><i>Note: The U32 classifier has an undocumented design bug which causes -duplicate entries to be listed by "tc filter show" when you use U32 -classifiers with different prio values.</i> -<img src=flatnp.gif align=right> -<p> -You may notice that we didn't create a filter for the 1:12 class. -It might be more clear to do so, but this illustrates the use of the default. -Any packet not classified by the two rules above (any packet -not from source address 1.2.3.4) will be put in class 1:12. -<p> -Now we can optionally attach queuing disciplines to the leaf classes. -If none is specified the default is pfifo. -<pre> -tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5 -tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5 -tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10 -</pre> -That's all the commands we need. Let's see what happens if we send -packets of each class at 90kbps and then stop sending packets of one -class at a time. Along the bottom of the graph are annotations -like "0:90k". The horizontal position at the center of the label -(in this case near the 9, also marked with a red "1") indicates the -time at which the rate of some traffic class changes. -Before the colon is an identifier for -the class (0 for class 1:10, 1 for class 1:11, 2 for class 1:12) and -after the colon is the new rate starting at the time where the -annotation appears. For example, the rate of class 0 is changed to -90k at time 0, 0 (= 0k) at time 3, and back to 90k at time 6. -<p> -Initially all classes generate 90kb. Since this is higher than any -of the rates specified, each class is limited to its -specified rate. At time 3 when we stop sending class 0 packets, the -rate allocated to class 0 is reallocated to the other two -classes in proportion to their allocations, 1 part class 1 to 6 parts class 2. -(The increase in class 1 is hard to see because it's only 4 kbps.) -Similarly at time 9 when class 1 traffic stops its bandwidth is -reallocated to the other two (and the increase in class 0 is similarly hard -to see.) At time 15 it's easier to see that the allocation to class 2 is -divided 3 parts for class 0 to 1 part for class 1. At time 18 both class 1 and -class 2 stop so class 0 gets all 90 kbps it requests. -<p> -It might be good time to touch concept of <b>quantums</b> now. In fact when -more classes want to borrow bandwidth they are each given some number of -bytes before serving other competing class. This number is called quantum. -You should see that if several classes are competing for parent's bandwidth -then they get it in proportion of their quantums. It is important to know -that for precise operation quantums need to be as small as possible and -larger than MTU. -<br> -Normaly you don't need to specify quantums manualy as HTB chooses precomputed -values. It computes classe's quantum (when you add or change it) as its -rate divided by <b>r2q</b> global parameter. Its default value is 10 -and because typical MTU is 1500 the default is good for rates from -15 kBps (120 kbit). For smaller minimal rates specify r2q 1 when -creating qdisc - it is good from 12 kbit which should be enough. If -you will need you can specify quantum manualy when adding or changing -the class. You can avoid warnings in log if precomputed value would be -bad. When you specify quantum on command line the r2q is ignored for -that class. -<p> -This might seem like a good solution if A and B were not different -customers. However, if A is paying for 40kbps then he would probably -prefer his unused WWW bandwidth to go to his own other service rather -than to B. This requirement is represented in HTB by the class hierarchy. - -<img src=Ag2Leaf3hier.gif align=right> -<a name=hsharing><h2>3. Sharing hierarchy</h2> -The problem from the previous chapter is solved by the class hierarchy -in this picture. Customer A is now explicitly represented by its own -class. Recall from above that -<b> the amount of service provided to each class is at least the -minimum of the amount it requests and the amount assigned to it</b>. -This applies to htb classes that are not parents of other htb classes. -We call these leaf classes. -For htb classes that are parents of other htb classes, which we call -interior classes, the rule is that -<b> the amount of service is at least the minumum of the amount assigned -to it and the sum of the amount requested by its children</b>. -In this case we assign 40kbps to customer A. That means that if A -requests less than the allocated rate for WWW, the excess will be used -for A's other traffic (if there is demand for it), at least until the sum is -40kbps. -<p> -<i>Notes: Packet classification rules can assign to inner nodes too. Then -you have to attach other filter list to inner node. Finally you should -reach leaf or special 1:0 class. The rate supplied for a parent should be the sum -of the rates of its children. </i> -<p>The commands are now as follows: -<pre> -tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps -tc class add dev eth0 parent 1:1 classid 1:2 htb rate 40kbps ceil 100kbps -tc class add dev eth0 parent 1:2 classid 1:10 htb rate 30kbps ceil 100kbps -tc class add dev eth0 parent 1:2 classid 1:11 htb rate 10kbps ceil 100kbps -tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps -</pre> -<img src=hiernp.gif align=right> -<p> -We now turn to the graph showing the results of the hierarchical solution. -When A's WWW traffic stops, its assigned bandwidth is reallocated to A's -other traffic so that A's total bandwidth is still the assigned 40kbps.<br> -If A were to request less than 40kbs in total then the excess would be given to B. - -<a name=ceiling><h2>4. Rate ceiling</h2> -The <b>ceil</b> argument specifies the maximum bandwidth that a class -can use. This limits how much bandwidth that class can borrow. -The default ceil is the same as the rate. (That's why we had to specify -it in the examples above to show borrowing.) -We now change the <b>ceil 100kbps</b> for classes 1:2 (A) and 1:11 -(A's other) from the previous chapter to <b>ceil 60kbps</b> and -<b>ceil 20kbps</b>. -<p> -The graph at right differs from the previous one at time 3 (when WWW -traffic stops) because A/other is limited to 20kbps. Therefore customer -A gets only 20kbps in total and the unused 20kbps is allocated to B.<br> -The second difference is at time 15 when B stops. Without the ceil, -all of its bandwidth was given to A, but now A is only allowed to use -60kbps, so the remaining 40kbps goes unused. -<img src=hiernpceil.gif align=right> -<p> -This feature should be useful for ISPs because they probably want to -limit the amount of service a given customer gets even when other -customers are not requesting service. (ISPs probably want customers -to pay more money for better service.) -Note that root classes are not allowed to borrow, so there's really no -point in specifying a ceil for them. -<p> -<i>Notes: The ceil for a class should always be at least as high as the rate. -Also, the ceil for a class should always be at least as high as the ceil of -any of its children.</i> - -<a name=burst><h2>5. Burst</h2> - -Networking hardware can only send one packet at a time and only at -a hardware dependent rate. Link sharing software can only use this -ability to approximate the effects of multiple links running at -different (lower) speeds. Therefore the rate and ceil are not really -instantaneous measures but averages over the time that it takes to send -many packets. What really happens is that the traffic from one class -is sent a few packets at a time at the maximum speed and then other -classes are served for a while. - -The <b>burst</b> and <b>cburst</b> parameters control the amount of data -that can be sent at the maximum (hardware) speed without trying to serve -another class. -<p> -If <b>cburst</b> is smaller (ideally one packet size) it shapes bursts to not exceed -<b>ceil</b> rate in the same way as TBF's peakrate does.<p> -When you set <b>burst</b> for parent class smaller than for some child -then you should expect the parent class to get stuck sometimes (because -child will drain more than parent can handle). HTB will remember these -negative bursts up to 1 minute. -<p> -You can ask <b>why I want bursts</b>. Well it is cheap and simple way -how to improve response times on congested link. For example www traffic -is bursty. You ask for page, get it in burst and then read it. During -that idle period burst will "charge" again. -<p> -<i>Note: The burst and cburst of a class should always be at least -as high as that of any of it children.</i> -<p> -<img src=hiernpburst.gif align=right> -On graph you can see case from previous chapter where I changed burst -for red and yellow (agency A) class to 20kb but cburst remained -default (cca 2 kb).<br> -Green hill is at time 13 due to burst setting on SMTP class. -A class. It has underlimit since time 9 and accumulated 20 kb of burst. -The hill is high up to 20 kbps (limited by ceil because it has cburst -near packet size).<br> -Clever reader can think why there is not red and yellow hill at time -7. It is because yellow is already at ceil limit so it has no space -for furtner bursts.<br> -There is at least one unwanted artifact - magenta crater at time 4. It -is because I intentionaly "forgot" to add burst to root link (1:1) class. -It remembered hill from time 1 and when at time 4 blue class wanted to -borrow yellow's rate it denied it and compensated itself. -<p> -<b>Limitation:</b> when you operate with high rates on computer with low -resolution timer you need some minimal <b>burst</b> and <b>cburst</b> to -be set for all classes. Timer resolution on i386 systems is 10ms and -1ms on Alphas. -The minimal burst can be computed as max_rate*timer_resolution. So that -for 10Mbit on plain i386 you needs burst 12kb.<p> -If you set too small burst you will encounter smaller rate than you set. -Latest tc tool will compute and set the smallest possible burst when it -is not specified. - -<img src=hierprio.gif align=right> -<a name=prio><h2>6. Priorizing bandwidth share</h2> -Priorizing traffic has two sides. First it affects how the excess bandwidth -is distributed among siblings. Up to now we have seen that excess bandwidth -was distibuted according to rate ratios. Now I used basic configuration from -chapter 3 (hierarchy without ceiling and bursts) and changed priority of all -classes to 1 except SMTP (green) which I set to 0 (higher).<br> -From sharing view you see that the class got all the excess bandwidth. The -rule is that <b>classes with higher priority are offered excess bandwidth -first</b>. But rules about guaranted <b>rate</b> and <b>ceil</b> are still -met.<p> -There is also second face of problem. It is total delay of packet. It is relatively -hard to measure on ethernet which is too fast (delay is so neligible). But -there is simple help. We can add simple HTB with one class rate limiting to -less then 100 kbps and add second HTB (the one we are measuring) as child. Then we -can simulate slower link with larger delays.<br> -For simplicity sake I use simple two class scenario: -<pre> -# qdisc for delay simulation -tc qdisc add dev eth0 root handle 100: htb -tc class add dev eth0 parent 100: classid 100:1 htb rate 90kbps - -# real measured qdisc -tc qdisc add dev eth0 parent 100:1 handle 1: htb -AC="tc class add dev eth0 parent" -$AC 1: classid 1:1 htb rate 100kbps -$AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps prio 1 -$AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps prio 1 -tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 2 -tc qdisc add dev eth0 parent 1:11 handle 21: pfifo limit 2 -</pre> -<img src=priotime.gif align=right> -<i>Note: HTB as child of another HTB is NOT the same as class under -another class within the same HTB. It is because when class in HTB can send -it will send as soon as hardware equipment can. So that delay of underlimit -class is limited only by equipment and not by ancestors.<br> -In HTB under HTB case the outer HTB simulates new hardware equipment with -all consequences (larger delay)</i> -<p> -Simulator is set to generate 50 kbps for both classes and at time 3s it -executes command: -<pre> -tc class change dev eth0 parent 1:2 classid 1:10 htb \ - rate 50kbps ceil 100kbps burst 2k prio 0 -</pre> -As you see the delay of WWW class dropped nearly to the zero while -SMTP's delay increased. When you priorize to get better delay it always -makes other class delays worse.<br> -Later (time 7s) the simulator starts to generate WWW at 60 kbps and SMTP at 40 kbps. -There you can observe next interesting behaviour. When class is overlimit -(WWW) then HTB priorizes underlimit part of bandwidth first.<p> -<b>What class should you priorize ?</b> Generaly those classes where -you really need low delays. The example could be video or audio -traffic (and you will really need to use correct <b>rate</b> here -to prevent traffic to kill other ones) or interactive (telnet, SSH) -traffic which is bursty in nature and will not negatively affect -other flows.<br> -Common trick is to priorize ICMP to get nice ping delays even on fully -utilized links (but from technical point of view it is not what you want when -measuring connectivity). - -<a name=stats><h2>7. Understanding statistics</h2> -The <b>tc</b> tool allows you to gather statistics of queuing disciplines in Linux. -Unfortunately statistic results are not explained by authors so that you often can't -use them. Here I try to help you to understand HTB's stats.<br> -First whole HTB stats. The snippet bellow is taken during simulation from chapter 3. -<pre> -# tc -s -d qdisc show dev eth0 - qdisc pfifo 22: limit 5p - Sent 0 bytes 0 pkts (dropped 0, overlimits 0) - - qdisc pfifo 21: limit 5p - Sent 2891500 bytes 5783 pkts (dropped 820, overlimits 0) - - qdisc pfifo 20: limit 5p - Sent 1760000 bytes 3520 pkts (dropped 3320, overlimits 0) - - qdisc htb 1: r2q 10 default 1 direct_packets_stat 0 - Sent 4651500 bytes 9303 pkts (dropped 4140, overlimits 34251) -</pre> -First three disciplines are HTB's children. Let's ignore them as PFIFO -stats are self explanatory.<br> -<i>overlimits</i> tells you how many times the discipline delayed a packet. -<i>direct_packets_stat</i> tells you how many packets was sent thru direct queue. -Other stats are sefl explanatory. Let's look at class' stats: -<pre> -tc -s -d class show dev eth0 -class htb 1:1 root prio 0 rate 800Kbit ceil 800Kbit burst 2Kb/8 mpu 0b - cburst 2Kb/8 mpu 0b quantum 10240 level 3 - Sent 5914000 bytes 11828 pkts (dropped 0, overlimits 0) - rate 70196bps 141pps - lended: 6872 borrowed: 0 giants: 0 - -class htb 1:2 parent 1:1 prio 0 rate 320Kbit ceil 4000Kbit burst 2Kb/8 mpu 0b - cburst 2Kb/8 mpu 0b quantum 4096 level 2 - Sent 5914000 bytes 11828 pkts (dropped 0, overlimits 0) - rate 70196bps 141pps - lended: 1017 borrowed: 6872 giants: 0 - -class htb 1:10 parent 1:2 leaf 20: prio 1 rate 224Kbit ceil 800Kbit burst 2Kb/8 mpu 0b - cburst 2Kb/8 mpu 0b quantum 2867 level 0 - Sent 2269000 bytes 4538 pkts (dropped 4400, overlimits 36358) - rate 14635bps 29pps - lended: 2939 borrowed: 1599 giants: 0 -</pre> -I deleted 1:11 and 1:12 class to make output shorter. As you see there -are parameters we set. Also there are <i>level</i> and DRR <i>quantum</i> -informations.<br> -<i>overlimits</i> shows how many times class was asked to send packet -but he can't due to rate/ceil constraints (currently counted for leaves only).<br> -<i>rate, pps</i> tells you actual (10 sec averaged) rate going thru class. It -is the same rate as used by gating.<br> -<i>lended</i> is # of packets donated by this class (from its <b>rate</b>) and -<i>borrowed</i> are packets for whose we borrowed from parent. Lends are always -computed class-local while borrows are transitive (when 1:10 borrows from 1:2 which -in turn borrows from 1:1 both 1:10 and 1:2 borrow counters are incremented).<br> -<i>giants</i> is number of packets larger than mtu set in tc command. HTB will -work with these but rates will not be accurate at all. Add mtu to your tc (defaults -to 1600 bytes).<br> - -<a name=err><h2>8. Making, debugging and sending error reports</h2> -<font color=red date=30.12.2002> -If you have kernel 2.4.20 or newer you don't need to patch it - all -is in vanilla tarball. The only thing you need is <b>tc</b> tool. -Download HTB 3.6 tarball and use tc from it. -</font><p> -You have to patch to make it work with older kernels. Download kernel source and -use <b>patch -p1 -i htb3_2.X.X.diff</b> to apply the patch. Then use -<b>make menuconfig;make bzImage</b> as before. Don't forget to enable QoS and HTB.<br> -Also you will have to use patched <b>tc</b> tool. The patch is also -in downloads or you can download precompiled binary.<p> -If you think that you found an error I will appreciate error report. -For oopses I need ksymoops output. For weird qdisc behaviour add -parameter <b>debug 3333333</b> to your <b>tc qdisc add .... htb</b>. -It will log many megabytes to syslog facility kern level debug. You -will probably want to add line like:<br> -<b>kern.debug -/var/log/debug</b><br> -to your /etc/syslog.conf. Then bzip and send me the log via email -(up to 10MB after bzipping) along with description of problem and -its time. -</body></html> diff --git a/debian/gbp.conf b/debian/gbp.conf deleted file mode 100644 index d7638261..00000000 --- a/debian/gbp.conf +++ /dev/null @@ -1,13 +0,0 @@ -[DEFAULT] -debian-branch = master -upstream-branch = upstream -pristine-tar = True -compression = xz -sign-tags = True - -[buildpackage] -#tarball-dir = ../tarballs/ -#export-dir = ../build-area/ - -[import-orig] -upstream-vcs-tag = v%(version)s diff --git a/debian/iproute2-doc.docs b/debian/iproute2-doc.docs index a3bb3538..ab1a32b8 100644 --- a/debian/iproute2-doc.docs +++ b/debian/iproute2-doc.docs @@ -1,4 +1 @@ -README* doc/Plan -debian/htb/* -doc/*.tex doc/*.dvi doc/*.ps doc/*.sty -doc/*.txt doc/*.html +README* diff --git a/debian/iproute2-doc.install b/debian/iproute2-doc.install index 6dd90fcd..6fa78e2b 100644 --- a/debian/iproute2-doc.install +++ b/debian/iproute2-doc.install @@ -1,2 +1 @@ -debian/doc/htb/* /usr/share/doc/iproute2-doc/htb usr/share/doc/iproute2/* /usr/share/doc/iproute2-doc diff --git a/debian/patches/0001-Add-moo-feature.patch b/debian/patches/0001-Add-moo-feature.patch deleted file mode 100644 index 81c4f4ef..00000000 --- a/debian/patches/0001-Add-moo-feature.patch +++ /dev/null @@ -1,39 +0,0 @@ -From: Alexander Wirt <formo...@debian.org> -Date: Mon, 10 Jun 2013 11:47:00 +0200 -Subject: Add moo feature - ---- - ip/ip.c | 15 +++++++++++++++ - 1 file changed, 15 insertions(+) - ---- a/ip/ip.c -+++ b/ip/ip.c -@@ -68,6 +68,20 @@ - return 0; - } - -+static int do_moo(int argc, char **argv) -+{ -+ -+fprintf(stderr, -+"\n" -+" _ __ ___ ___ ___\n" -+"| '_ ` _ \\ / _ \\ / _ \\\n" -+"| | | | | | (_) | (_) |\n" -+"|_| |_| |_|\\___/ \\___/\n" -+"\n\n" -+"P.S. no real cows were harmed for this moo\n"); -+ exit(1); -+} -+ - static const struct cmd { - const char *cmd; - int (*func)(int argc, char **argv); -@@ -98,6 +112,7 @@ - { "netns", do_netns }, - { "netconf", do_ipnetconf }, - { "help", do_help }, -+ { "moo", do_moo }, - { 0 } - }; - diff --git a/debian/patches/0002-txtdocs.patch b/debian/patches/0002-txtdocs.patch deleted file mode 100644 index 590a232a..00000000 --- a/debian/patches/0002-txtdocs.patch +++ /dev/null @@ -1,42 +0,0 @@ -From: Debian iproute2 Maintainers <ah-ipro...@debian.org> -Date: Mon, 10 Jun 2013 11:47:00 +0200 -Subject: txtdocs - ---- - doc/Makefile | 9 ++++++++- - 1 file changed, 8 insertions(+), 1 deletion(-) - ---- a/doc/Makefile -+++ b/doc/Makefile -@@ -14,6 +14,7 @@ - PAGESPERPAGE=2 - - HTMLFILES=$(subst .sgml,.html,$(shell echo *.sgml)) -+TXTFILES=$(subst .sgml,.txt,$(shell echo *.sgml)) - DVIFILES=$(subst .ps,.dvi,$(PSFILES)) - PDFFILES=$(subst .ps,.pdf,$(PSFILES)) - -@@ -28,6 +29,8 @@ - - pdf: $(PDFFILES) - -+txt: $(TXTFILES) -+ - print: $(PSFILES) - $(LPR) $(PSFILES) - -@@ -65,9 +68,13 @@ - %.html: %.sgml - $(SGML2HTML) $< - -+%.txt: %.html -+ lynx -nolist -dump $< > $@ -+ -+ - install: - install -m 0644 $(shell echo *.tex) $(DESTDIR)$(DOCDIR) - install -m 0644 $(shell echo *.sgml) $(DESTDIR)$(DOCDIR) - - clean: -- rm -f *.aux *.log *.toc $(PSFILES) $(DVIFILES) *.html *.pdf -+ rm -f *.aux *.log *.toc $(PSFILES) $(DVIFILES) *.html *.pdf $(TXTFILES) diff --git a/debian/patches/series b/debian/patches/series deleted file mode 100644 index 960fe255..00000000 --- a/debian/patches/series +++ /dev/null @@ -1,2 +0,0 @@ -0001-Add-moo-feature.patch -0002-txtdocs.patch diff --git a/debian/rules b/debian/rules index e5d74670..c30d7f5f 100755 --- a/debian/rules +++ b/debian/rules @@ -2,8 +2,8 @@ DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ') -DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) -DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) CROSS := @@ -17,7 +17,6 @@ endif override_dh_clean: dh_clean make distclean - -rm -f doc/*.txt override_dh_shlibdeps: dh_shlibdeps -a -Xq_atm.so -Xm_xt.so -Xm_ipt.so @@ -27,11 +26,4 @@ override_dh_auto_configure: $(CROSS) dh_auto_configure override_dh_auto_build: - $(MAKE) -C doc all txt $(MAKE) KERNEL_INCLUDE=./include $(CROSS) - -# bump version of the transitional packages... -override_dh_gencontrol: - dh_gencontrol -piproute -- -v1:$(DEB_VERSION) - dh_gencontrol -piproute-doc -- -v1:$(DEB_VERSION) - dh_gencontrol --remaining-packages
pgp6TPFqV2Oc8.pgp
Description: Digitale Signatur von OpenPGP
