hi all,
after slicing and dicing, i found that i had cut and pasted bad syntax,
so i have solved the problem posted in my first message.
that said, i have found an issue in 9h and 9i of tcng running on a
bi-processor with redhat-8 up2date with 2.4.20 kernel.
here''s a small tcng cfg:
#define DEVICE eth0
#define UPLINK 512
dev DEVICE {
egress {
htb () {
class (rate UPLINK kbps) {
}
}
}
}
[root]# cat tc.bug | tcc
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 htb
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 64000bps
------------------------------------------------------^^^^^^^^
notice that the UPLINK of 512 kbps (arguably 524288 bps) has been
incorrectly calculated as 64000 bps
similarly, the following:
#define DEVICE eth0
#define UPLINK 64
dev DEVICE {
egress {
htb () {
class (rate UPLINK kBps) {
}
}
}
}
[root]# cat tc.bug | tcc
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 htb
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 64000bps
------------------------------------------------------^^^^^^^^
if i express the UPLINK in kilobytes/s, then the rate has been
incorrectly multiplied by 1000 instead equaling 64 * 8 * 1024 = 524288
have i missed something, or indeed there is a problem??
many thanks
charles
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello Charles,
: after slicing and dicing, i found that i had cut and pasted bad syntax,
: so i have solved the problem posted in my first message.
Where did you find the original (I''m hoping it''s not one of
mine). If so,
let me know, and I''ll fix it.
[ example snipped ]
: notice that the UPLINK of 512 kbps (arguably 524288 bps) has been
: incorrectly calculated as 64000 bps
You have not actually found a bug, but rather a historical strangeness
about the Linux traffic control system. For reasons of which I''m
ignorant, the syntax for the "tc" command uses bps for bytes/second.
So,
64000 bytes/second is actually 512 kilobits/second ("512 kbps" in
common
usage), but is 512 kbit to the "tc" tool. Here''s a brief
chart:
tc syntax tcng syntax
+----------------+----------------+
bytes/second | bps | Bps |
bits/second | bit | bps |
kilobytes/second | kbps | kBps |
kilobits/second | kbit | kbps |
+----------------+----------------+
Note that the tcng syntax is exactly the same sort of syntax we use in
general when discussing speed of WAN links. "It''s a 512 kbps
line" means
it''s 512 kilobits per second, but this would be 64000 bytes per second
if
we were writing a "tc" command line.
[ another example snipped ]
I expect that you''ll understand exactly what was happening in your
second
example now that you are looking at this chart.
: have i missed something, or indeed there is a problem??
I''m guessing that you just missed this oddity of command line tc
behaviour
but that the tcng syntax is doing exactly what you desire.
Best of luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
lartc@manchotnetworks.net
2003-Nov-28 07:43 UTC
Re: no bug in tcng; tc kbit v. tcng kbps was tcng error
hi martin, On Thu, 2003-11-27 at 20:58, Martin A. Brown wrote:> Hello Charles, > > : after slicing and dicing, i found that i had cut and pasted bad syntax, > : so i have solved the problem posted in my first message. > > Where did you find the original (I''m hoping it''s not one of mine). If so, > let me know, and I''ll fix it.indeed, i used some of your examples as well as those included in the tcng/examples-ng directory, and wshaper.htb to create the following (i''ll post it now as it is untested but functioning less or more) #define DEVICE eth0 #define DOWNLINK 1024 #define UPLINK 512 #include "fields.tc" #include "ports.tc" dev DEVICE { ingress { $policer = SLB( cir DOWNLINK kBps, cbs 60kB, mpu 0b ); class (<>) if SLB_ok($policer); drop if 1; } egress { class (<$high>) if tcp_ACK || ip_proto == IPPROTO_ICMP || ip_tos == 0x10 || tcp_dport == PORT_SSH || tcp_dport == 8080 || tcp_dport == 18082 || tcp_dport == 18083; class (<$medium>) if tcp_dport == PORT_HTTP || tcp_dport == PORT_SMTP ; class (<$low>) if 1; htb () { class (rate UPLINK bps, burst 6kB) { $high = class (prio 1, rate UPLINK kBps) { sfq (perturb 10 sec); }; $medium = class (prio 2, rate (0.9*UPLINK)kBps) { sfq (perturb 10 sec); }; $low = class (prio 3, rate (0.8*UPLINK) kBps) { sfq (perturb 10 sec); }; } } } }> [ example snipped ] > > : notice that the UPLINK of 512 kbps (arguably 524288 bps) has been > : incorrectly calculated as 64000 bps > > You have not actually found a bug, but rather a historical strangeness > about the Linux traffic control system. For reasons of which I''m > ignorant, the syntax for the "tc" command uses bps for bytes/second. So, > 64000 bytes/second is actually 512 kilobits/second ("512 kbps" in common > usage), but is 512 kbit to the "tc" tool. Here''s a brief chart: > > tc syntax tcng syntax > +----------------+----------------+ > bytes/second | bps | Bps | > bits/second | bit | bps | > kilobytes/second | kbps | kBps | > kilobits/second | kbit | kbps | > +----------------+----------------+ > > Note that the tcng syntax is exactly the same sort of syntax we use in > general when discussing speed of WAN links. "It''s a 512 kbps line" means > it''s 512 kilobits per second, but this would be 64000 bytes per second if > we were writing a "tc" command line.ah ha -- thanks for this!!!! much clearer now ... perhaps this table is worthy of inclusion in the howto or a compatibility option in tcng? curious also on your experience with ingress -- i noticed that using a Single Leaky Bucket, and playing with the cbs parameter can dramatically (obviously) affect the ingress policing. is there a general rule of thumb in calculating the cbs size based on the cir? cheers charles _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Martin A. Brown
2003-Dec-01 06:01 UTC
Re: no bug in tcng; tc kbit v. tcng kbps was tcng error
Charles, : #include "fields.tc" : #include "ports.tc" [ You don''t really need to explicitly include fields.tc and ports.tc, because they are implicitly included by tcc. ] [ some snipped stuff ] : ah ha -- thanks for this!!!! much clearer now ... Most certainly. I think this is one of the more confusing aspects of Linux traffic control. : perhaps this table is worthy of inclusion in the howto or a : compatibility option in tcng? It''s (now*) written in several places [0], [1], [2]*. Which HOWTO were you consulting? The LARTC HOWTO? It doesn''t (yet) cover tcng, to my knowledge. : curious also on your experience with ingress -- i noticed that using a : Single Leaky Bucket, and playing with the cbs parameter can : dramatically (obviously) affect the ingress policing. is there a : general rule of thumb in calculating the cbs size based on the cir? I don''t have a quick and easy answer....perhaps one of Stef''s graphs [3] will help you choose a bucket size. Because a larger bucket supports burstier traffic, it may be your choice in many situations. Others may want to prevent any bursting, and may deliberately wish to use a small bucket. This is also where some experimentation will lend a hand. Better to try a few bucket sizes, and see where you/your users are comfortable. -Martin [0] http://linux-ip.net/gl/tcng/node21.html [1] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/misc.html *[2] http://www.docum.org/stef.coene/qos/faq/cache/74.html [3] http://docum.org/ * added (at your suggestion) to the LARTC FAQ-o-Matic -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/