I have been trying to optimise my ADSL connections for VOIP.
Funny things were happening - for example increasing the ping
packet size by 50% had no effect, but then adding one byte
had a major effect. It took me a while to figure out that I
was seeing the effects of the fixed ATM cell size.
This is probably obvious to some of you. For the rest: ADSL
uses ATM as its transport. An ATM "packet" is called a cell.
A cell has a fixed length of 48 bytes of data, plus 5 bytes
of header. If there is not enough data to occupy the cell,
padding is added. Thus if you get unlucky there could be up
to 47 bytes of padding.
This 47 bytes isn''t really noticeable for large packets, such
as found in Web Traffic, as it is only 3% of the total packet
size. It isn''t even really noticeable for normal sources of
interactive traffic, because typical interactive traffic (eg
telnet, ssh & irc) is so low volume, and hence doesn''t take
up much of your link capacity. Thus in both cases the total
percentage of your link capacity devoted to carrying this
"padding" (aka wasted bandwidth) is low.
In VOIP the situation changes. Firstly, the packets are
small, occupying only 2 to 3 cells. Secondly, it saturates
the link. Thus if you are doing VOIP, up to 1/3 of your
links capacity can be this padding.
It is not difficult using tc as it stands to generate a
rate table does a fairly good job of estimating the
bandwidth used on your ADSL link by large packets, or by
small packets of a consistent size. You can''t do both.
You can play with the figures (overhead and base rate)
and get all sorts of trade offs. If you are prepared to
overestimate the links carrying capacity at some packet
sizes, (a serious error for VOIP), then you can get the
worst case error down to around 20%. If you don''t want
at overestimate link capacity under any circumstances,
the worst case error rises to a 40% underestimate.
The following patch to tc allows it to perform an exact
ATM / ADSL rate calculation. It adds one extra keyword
to the "tc class add htb ..." command line: "atm". There
isn''t a lot of spare bits hanging around to record this,
so the patch adds the feature at the expense of always
forcing the "overhead" parameter to be even.
With the patch, these commands will generate a correct
rate table for:
PPPoA + VC/Mux: tc class add htb ... overhead 10 atm
PPPoA + VC/LLC: tc class add htb ... overhead 18 atm
PPPoE + VC/Mux: tc class add htb ... overhead 34 atm
PPPoE + VC/LLC: tc class add htb ... overhead 42 atm
When using this command lines, you always specify the ADSL
link capacity as quoted by the modem. Eg, if you are
controlling incoming traffic on a 512k/128k link, you
specify the link speed as 512000bps.
For those of you running Debian sarge or unstable, you can
find a patched version of tc here:
http://www.stuart.id.au/russell/files/debian/sarge/iproute
diff -Nur iproute-20051007.keep/tc/q_htb.c iproute-20051007/tc/q_htb.c
--- iproute-20051007.keep/tc/q_htb.c 2006-03-02 14:50:51.000000000 +1000
+++ iproute-20051007/tc/q_htb.c 2006-03-02 15:50:31.000000000 +1000
@@ -349,6 +349,7 @@
" burst max bytes burst which can be accumulated during idle period
{computed}\n"
" mpu minimum packet size used in rate computations\n"
" overhead per-packet size overhead used in rate computations\n"
+ " atm include atm cell tax in rate computations\n"
" ceil definite upper class rate (no borrows) {rate}\n"
" cburst burst but for ceil {computed}\n"
@@ -416,7 +417,7 @@
unsigned buffer=0,cbuffer=0;
int cell_log=-1,ccell_log = -1;
unsigned mtu, mpu;
- unsigned char mpu8 = 0, overhead = 0;
+ unsigned char mpu8 = 0, overhead = 0, atm=0;
struct rtattr *tail;
memset(&opt, 0, sizeof(opt)); mtu = 1600; /* eth packet len */
@@ -440,9 +441,11 @@
}
} else if (matches(*argv, "overhead") == 0) {
NEXT_ARG();
- if (get_u8(&overhead, *argv, 10)) {
+ if (get_u8(&overhead, *argv, 10) || (overhead & 1)) {
explain1("overhead"); return -1;
}
+ } else if (matches(*argv, "atm") == 0) {
+ atm = 1;
} else if (matches(*argv, "quantum") == 0) {
NEXT_ARG();
if (get_u32(&opt.quantum, *argv, 10)) {
@@ -515,7 +518,7 @@
if (!cbuffer) cbuffer = opt.ceil.rate / get_hz() + mtu;
/* encode overhead and mpu, 8 bits each, into lower 16 bits */
- mpu = (unsigned)mpu8 | (unsigned)overhead << 8;
+ mpu = (unsigned)mpu8 | (unsigned)(overhead + atm) << 8;
opt.ceil.mpu = mpu; opt.rate.mpu = mpu;
if ((cell_log = tc_calc_rtable(opt.rate.rate, rtab, cell_log, mtu, mpu)) <
0) {
@@ -575,12 +578,16 @@
sprint_size(buffer, b1),
1<<hopt->rate.cell_log,
sprint_size(hopt->rate.mpu&0xFF, b2),
- sprint_size((hopt->rate.mpu>>8)&0xFF, b3));
+ sprint_size((hopt->rate.mpu>>8)&0xFE, b3));
+ if (hopt->rate.mpu & 0x100)
+ fprintf(f, "atm ");
fprintf(f, "cburst %s/%u mpu %s overhead %s ",
sprint_size(cbuffer, b1),
1<<hopt->ceil.cell_log,
sprint_size(hopt->ceil.mpu&0xFF, b2),
- sprint_size((hopt->ceil.mpu>>8)&0xFF, b3));
+ sprint_size((hopt->ceil.mpu>>8)&0xFE, b3));
+ if (hopt->ceil.mpu & 0x100)
+ fprintf(f, "atm ");
fprintf(f, "level %d ", (int)hopt->level);
} else {
fprintf(f, "burst %s ", sprint_size(buffer, b1));
diff -Nur iproute-20051007.keep/tc/tc_core.c iproute-20051007/tc/tc_core.c
--- iproute-20051007.keep/tc/tc_core.c 2006-03-02 14:50:51.000000000 +1000
+++ iproute-20051007/tc/tc_core.c 2006-03-02 15:48:38.000000000 +1000
@@ -43,6 +43,32 @@
}
/*
+ * Calculate the link layer frame size using into information encoded
+ * in the mpu.
+ */
+static unsigned frame_size(unsigned size, unsigned mpu) {
+ unsigned min_packet_size = mpu & 0xFF;
+ unsigned overhead = (mpu >> 8) & 0xFE;
+ unsigned atm_cell_tax = (mpu & 0x100) != 0;
+ const unsigned atm_header = 5;
+ const unsigned atm_payload = 48;
+
+ size += overhead;
+ if (size < min_packet_size)
+ size = min_packet_size;
+ if (atm_cell_tax) {
+ int cells = size / atm_payload;
+ int tail = size % atm_payload;
+ if (tail != 0) {
+ size += atm_payload - tail;
+ cells += 1;
+ }
+ size += atm_header * cells;
+ }
+ return size;
+}
+
+/*
rtab[pkt_len>>cell_log] = pkt_xmit_time
*/
@@ -50,23 +76,16 @@
unsigned mpu)
{
int i;
- unsigned overhead = (mpu >> 8) & 0xFF;
- mpu = mpu & 0xFF;
-
- if (mtu == 0)
- mtu = 2047;
if (cell_log < 0) {
+ if (mtu == 0)
+ mtu = 2047;
cell_log = 0;
while ((mtu>>cell_log) > 255)
cell_log++;
}
for (i=0; i<256; i++) {
- unsigned sz = (i<<cell_log);
- if (overhead)
- sz += overhead;
- if (sz < mpu)
- sz = mpu;
+ unsigned sz = frame_size(i<<cell_log, mpu);
rtab[i] = tc_core_usec2tick(1000000*((double)sz/bps));
}
return cell_log;
--
Regards,
Russell Stuart
Am Donnerstag, 2. März 2006 08:30 schrieb Russell Stuart:> I have been trying to optimise my ADSL connections for VOIP. > Funny things were happening - for example increasing the ping > packet size by 50% had no effect, but then adding one byte > had a major effect. It took me a while to figure out that I > was seeing the effects of the fixed ATM cell size.[ ADSL - ATM/AAL5/LLC Overhead description ] this stuff is well documented in Jesper Dangaard Brouer master thesis found at: http://www.adsl-optimizer.dk/thesis/ There exists also patches which do static overhead rate table calculation (incl. ATM Cell alignment) or per packet overhead calculation for htb or other qdiscs. Why you don''t use the existing overhead parameter? It''s useless to have two parameters which do the exact same thing (existing overhead and your atm). Only ATM Cell alignment must be added to rate table calculation. -- Markus Schulz
Am Donnerstag, 2. März 2006 14:37 schrieb Markus Schulz:> Am Donnerstag, 2. März 2006 08:30 schrieb Russell Stuart: > > I have been trying to optimise my ADSL connections for VOIP. > > Funny things were happening - for example increasing the ping > > packet size by 50% had no effect, but then adding one byte > > had a major effect. It took me a while to figure out that I > > was seeing the effects of the fixed ATM cell size. > > [ ADSL - ATM/AAL5/LLC Overhead description ] > > this stuff is well documented in Jesper Dangaard Brouer master thesis > found at: http://www.adsl-optimizer.dk/thesis/ > > There exists also patches which do static overhead rate table > calculation (incl. ATM Cell alignment) or per packet overhead > calculation for htb or other qdiscs. > > Why you don''t use the existing overhead parameter? It''s useless to > have two parameters which do the exact same thing (existing overhead > and your atm). > Only ATM Cell alignment must be added to rate table calculation.But it would be nice if this would be patched into upstream iproute source. Then there is no need of patching for qos at adsl links. -- Markus Schulz
Russell Stuart wrote:> The following patch to tc allows it to perform an exact > ATM / ADSL rate calculation.I probably haven''t read the patch properly - but I don''t think you can do it exactly without patching net/sched/sched_htb.c aswell. Specifically you need to add overhead - 1 before htb shifts the length to get the slot num (-1 because you need to get 48 and 49 payload length to map to different slots 47 and 48 do). The table should be filled according to this. It adds one extra keyword> to the "tc class add htb ..." command line: "atm". There > isn''t a lot of spare bits hanging around to record this, > so the patch adds the feature at the expense of always > forcing the "overhead" parameter to be even. > > With the patch, these commands will generate a correct > rate table for: > > PPPoA + VC/Mux: tc class add htb ... overhead 10 atm > PPPoA + VC/LLC: tc class add htb ... overhead 18 atm > PPPoE + VC/Mux: tc class add htb ... overhead 34 atm > PPPoE + VC/LLC: tc class add htb ... overhead 42 atmAlso remember that if you shape on ethX 14 bytes are already added to ip length when htb looks up rate, so pppoa/vcmux would need to be negative.> > When using this command lines, you always specify the ADSL > link capacity as quoted by the modem. Eg, if you are > controlling incoming traffic on a 512k/128k link, you > specify the link speed as 512000bps.You need to look at the atm user rate shown by your modem, for me in the past it was 288/576 this was sold as 250/500 by teleco and 256/512 by isp. You also need to back off a couple of kbit (egress - ingress more for different reasons) - one of my modems does cell qos bases on rate of whole cells/sec - don''t kmow how common that is. Also if you run exactly on the rate and queue formed when starting/restarting scripts it would not drain till the traffic stopped. Andy.
Hi, On Thu, 2006-03-02 at 15:49 +0000, Andy Furniss wrote:> Russell Stuart wrote: > > > The following patch to tc allows it to perform an exact > > ATM / ADSL rate calculation. > > I probably haven''t read the patch properly - but I don''t think you can > do it exactly without patching net/sched/sched_htb.c aswell. > Specifically you need to add overhead - 1 before htb shifts the length > to get the slot num (-1 because you need to get 48 and 49 payload length > to map to different slots 47 and 48 do). The table should be filled > according to this.As Markus mentioned in another post on this thread, Jesper Dangaard Brouer (http://www.adsl-optimizer.dk) has already written an iproute2 and Linux kernel patch that implements the above. ATM cell alignment is done in tc_core.c, and the per packet overhead is passed to the relevant kernel modules. I have made some very minor changes to the patches, so that they apply cleanly to iproute2-20051007 and kernel 2.6.15. You will find them attached to this mail.> > When using this command lines, you always specify the ADSL > > link capacity as quoted by the modem. Eg, if you are > > controlling incoming traffic on a 512k/128k link, you > > specify the link speed as 512000bps. > > You need to look at the atm user rate shown by your modem, for me in the > past it was 288/576 this was sold as 250/500 by teleco and 256/512 by isp. > > You also need to back off a couple of kbit (egress - ingress more for > different reasons) - one of my modems does cell qos bases on rate of > whole cells/sec - don''t kmow how common that is. Also if you run exactly > on the rate and queue formed when starting/restarting scripts it would > not drain till the traffic stopped.Setting the MTU to 1478 is probably a good idea to prevent excessive cell usage. Reasoning behind this being: 1488 is the largest multiple of 48 under 1500, less 2 bytes for the PPP header and 8 for the AAL5 footer. Perhaps you can confirm this isn''t way off the mark Andy? :) -- Adam James <ad@heliosphan.co.uk> _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Adam James wrote:> As Markus mentioned in another post on this thread, Jesper Dangaard > Brouer (http://www.adsl-optimizer.dk) has already written an iproute2 > and Linux kernel patch that implements the above. ATM cell alignment is > done in tc_core.c, and the per packet overhead is passed to the relevant > kernel modules. > > I have made some very minor changes to the patches, so that they apply > cleanly to iproute2-20051007 and kernel 2.6.15. You will find them > attached to this mail.Just remember to take 14 from your overhead if your modem is connected via eth rather than ppp etc. This means you need to put a negative overhead (can you?) if using pppoa/vcmux> Setting the MTU to 1478 is probably a good idea to prevent excessive > cell usage. Reasoning behind this being: 1488 is the largest multiple of > 48 under 1500, less 2 bytes for the PPP header and 8 for the AAL5 > footer. > > Perhaps you can confirm this isn''t way off the mark Andy? :)1478 is optimal if your overhead is 10 - I use it. For the pppoes I don''t think you gain much as you loose tcp data efficiency by using smaller packets. Andy.
On Thu, 2006-03-02 at 14:51 +0100, Markus Schulz wrote:> > Why you don''t use the existing overhead parameter? It''s useless to > > have two parameters which do the exact same thing (existing overhead > > and your atm). > > Only ATM Cell alignment must be added to rate table calculation.The overhead and atm options don''t do the "exact same thing". If the atm option is present, tc includes the atm cell alignment overheads in the rate table calculation. Otherwise it doesn''t. As atm cell overheads aren''t a fixed amount (they vary in a non-linear fashion between 6 and 202 bytes), you can''t use the overhead option to calculate them.> But it would be nice if this would be patched into upstream iproute > source. Then there is no need of patching for qos at adsl links.Yes. After posting my patch I went away and had a think, and realised that because of rounding issues my calculation of atm cell overhead would be wrong in some cases. The only fix I could think of was to modify the kernel. I was not aware of Jesper''s adsl-optimiser patches until you pointed them out just now. Having looked at them two things stand out: a. Jesper had already come across the rate calculation problem and had solved it. His solution and my intended solution are the same. The problem is caused by the scaling of the packet size prior to looking up the rate table. The easy solution is to add the overhead in the kernel, rather than having tc include the overhead in the pre-calculated rate table. This is what Jesper''s kernel patch does. (The rate table is indexed by packet size, and returns the amount of time required to send a packet of that size. It is a fixed size table of 256 entries (0..255). Since packets can be bigger than 255 bytes long, the packet size is first scaled so it will fit into the 0..255 range. Scaling is achieved by dividing the packet size by a power of 2 (ie 1, 2, 4, 8, etc). A scale factor of 8 handles packet sizes of 1024..2047, so this is what most links end up using.) If you don''t patch the kernel, the rate calculated by the kernel will be wrong around 10% of the time (as opposed to very nearly 100% of the time if you don''t use the patch at all). 2. Jasper didn''t make including the atm cell overhead optional - so it is included for all links, whether they use atm or not. Thus he doesn''t have an "atm" parameter. This means it isn''t general purpose, and could not be distributes as part of the standard tc package. In any case, apart from those two relatively minor differences the two patches are the identical in what they achieve and how they do it. Personally, I didn''t care much about any of this before VOIP because when it is all said and done, the 3% error you get for large packet sizes is easily accounted for by just adjusting the rate accordingly. That doesn''t work when the error rate rises to 40%, as it does for VOIP. As VOIP is going to become a significant part of internet traffic in the not too distant future, I think it is time to consider including some combination of these patches into the main line.
On Fri, 03 Mar 2006 08:18:52 +1000 Russell Stuart <russell-lartc@stuart.id.au> wrote:> On Thu, 2006-03-02 at 14:51 +0100, Markus Schulz wrote: > > > Why you don''t use the existing overhead parameter? It''s useless to > > > have two parameters which do the exact same thing (existing overhead > > > and your atm). > > > Only ATM Cell alignment must be added to rate table calculation. > > The overhead and atm options don''t do the "exact same > thing". If the atm option is present, tc includes the > atm cell alignment overheads in the rate table > calculation. Otherwise it doesn''t. > > As atm cell overheads aren''t a fixed amount (they vary > in a non-linear fashion between 6 and 202 bytes), you > can''t use the overhead option to calculate them. > > > But it would be nice if this would be patched into upstream iproute > > source. Then there is no need of patching for qos at adsl links. > >I will put it in iproute2 commands when a definitive set of patches is sent to me. So far, it still looks like it needs some fine tuning.
Stephen Hemminger said:> On Fri, 03 Mar 2006 08:18:52 +1000 > Russell Stuart <russell-lartc@stuart.id.au> wrote: > >> On Thu, 2006-03-02 at 14:51 +0100, Markus Schulz wrote: >> > > Why you don''t use the existing overhead parameter? It''s useless to >> > > have two parameters which do the exact same thing (existing overhead >> > > and your atm). >> > > Only ATM Cell alignment must be added to rate table calculation. >> >> The overhead and atm options don''t do the "exact same >> thing". If the atm option is present, tc includes the >> atm cell alignment overheads in the rate table >> calculation. Otherwise it doesn''t. >> >> As atm cell overheads aren''t a fixed amount (they vary >> in a non-linear fashion between 6 and 202 bytes), you >> can''t use the overhead option to calculate them. >> >> > But it would be nice if this would be patched into upstream iproute >> > source. Then there is no need of patching for qos at adsl links. >> >> > > I will put it in iproute2 commands when a definitive set of patches > is sent to me. So far, it still looks like it needs some fine tuning.I''ll test the patch from Russell Stuart in the next few days, I hope. I''d love to eventually see it in iproute2. :)
On Thu, 2006-03-02 at 14:23 -0800, Stephen Hemminger wrote:> I will put it in iproute2 commands when a definitive set of patches > is sent to me. So far, it still looks like it needs some fine tuning.Yes, they need some fine tuning. My ultimate goal here is to get something into the main line that makes tc/htb work well for VOIP. I don''t care whether it is my patch, or something else. Jesper''s patch is more mature, and as such is probably the better starting point. The only problem with using them is this statement on his web site: "Commercial use of my work including the ADSL-optimizer is not allowed without my knowledge and consent. The ADSL-optimizer will be released under the GNU public license." Coming from a Debian background, statements like this can be a problem. A statement somewhere that clarifies the patches are released under the GPL (and thus can be used commercially) need to be made somewhere. Either on the web site, or in the patch themselves. The combined issues from both sets of patches that need to be sorted are: 1. Changes to the kernel so the rate calculation can be 100% accurate. (Already in Jesper''s patch - I must verify it is backward compatible.) 2. Making the ATM calculation optional via a command line option. (Already in my patch.) 3. Allowing the overhead figure to be negative so that the patch will work with PPPoA. (This is an issue with both patches.) 4. Jesper clarifying the license on his patch.
On Thursday 02 March 2006 02:30, Russell Stuart wrote:> I have been trying to optimise my ADSL connections for VOIP. > Funny things were happening - for example increasing the ping > packet size by 50% had no effect, but then adding one byte > had a major effect. It took me a while to figure out that I > was seeing the effects of the fixed ATM cell size.<snip>> diff -Nur iproute-20051007.keep/tc/q_htb.c iproute-20051007/tc/q_htb.c > --- iproute-20051007.keep/tc/q_htb.c 2006-03-02 14:50:51.000000000 +1000 > +++ iproute-20051007/tc/q_htb.c 2006-03-02 15:50:31.000000000 +1000Any chance something like this can be applied to q_tbf? It''s been classful for a while and I find a tbf with a prio under it works quite well for my configuration. Jesper''s patch indicates untested support for other schedulers including tbf, so it''s certainly possible. Thanks. -- Jason Boxman http://edseek.com/ - Linux and FOSS stuff
On Thu, 2006-03-02 at 19:27 -0500, Jason Boxman wrote:> Any chance something like this can be applied to q_tbf? It''s been classful > for a while and I find a tbf with a prio under it works quite well for my > configuration. Jesper''s patch indicates untested support for other > schedulers including tbf, so it''s certainly possible.It would not be much more effort to add it to all qdisc''s it applies to, really. What happens is identical in all cases.
Am Donnerstag, 2. März 2006 20:54 schrieb Adam James:> Hi, > > On Thu, 2006-03-02 at 15:49 +0000, Andy Furniss wrote: > > Russell Stuart wrote: > > > The following patch to tc allows it to perform an exact > > > ATM / ADSL rate calculation. > > > > I probably haven''t read the patch properly - but I don''t think you > > can do it exactly without patching net/sched/sched_htb.c aswell. > > Specifically you need to add overhead - 1 before htb shifts the > > length to get the slot num (-1 because you need to get 48 and 49 > > payload length to map to different slots 47 and 48 do). The table > > should be filled according to this. > > As Markus mentioned in another post on this thread, Jesper Dangaard > Brouer (http://www.adsl-optimizer.dk) has already written an iproute2 > and Linux kernel patch that implements the above. ATM cell alignment > is done in tc_core.c, and the per packet overhead is passed to the > relevant kernel modules.once again i have thought about this topic and tried to built a rate table with exactly the same behaviour as the htb-overhead patch from Jesper. But now as static patch for iproute''s tc, without need for patching htb or other kernel modules. But in all my experiments i can''t calculate an equivalent rate table. It differs in behaviour from per packet calculated overhead. But i don''t see the difference in mathematics in both calculations. I think it must be possible, but can''t see my fault. With a rate table of at least one entry from zero (or 40b) to <mtu> it is possible. But, is it possible with only 256 rate table entries? I''ve attached a simple program, which implements three versions of calculations. Two of them use a rate table, at first the static version (without htb-overhead patch), second one with "simulated" kernel patch (like Jesper''s one) and at least a "realtime calculation" as a reference value. The second rate table is 100% equivalent to realtime calc. But the static version differs for some ip-length values from it. And i don''t understand why. Perhaps someone can point me to the difference? The program is only for testing rate tables calculations. It would be nice to do it without a htb or other qdisc module patch. And i think it should be possible :) -- Markus Schulz _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Am Donnerstag, 2. März 2006 23:18 schrieb Russell Stuart:> On Thu, 2006-03-02 at 14:51 +0100, Markus Schulz wrote: > > > Why you don''t use the existing overhead parameter? It''s useless > > > to have two parameters which do the exact same thing (existing > > > overhead and your atm). > > > Only ATM Cell alignment must be added to rate table calculation. > > The overhead and atm options don''t do the "exact same > thing". If the atm option is present, tc includes the > atm cell alignment overheads in the rate table > calculation. Otherwise it doesn''t.yes, i know the difference in overhead from AAL5/LLC/pppoe stuff and ATM Cell alignment.> As atm cell overheads aren''t a fixed amount (they vary > in a non-linear fashion between 6 and 202 bytes), you > can''t use the overhead option to calculate them. > > > But it would be nice if this would be patched into upstream iproute > > source. Then there is no need of patching for qos at adsl links. > > Yes. > > After posting my patch I went away and had a think, > and realised that because of rounding issues my > calculation of atm cell overhead would be wrong in > some cases. The only fix I could think of was to > modify the kernel.i have thought again about this topic and wrote a test program for rate table calculations. But until now without luck (see my other posting on lartc). It would be nice to do it without kernel patching.> I was not aware of Jesper''s adsl-optimiser patches > until you pointed them out just now. Having looked > at them two things stand out: > > a. Jesper had already come across the rate calculation > problem and had solved it. His solution and my > intended solution are the same. > > The problem is caused by the scaling of the packet > size prior to looking up the rate table. The > easy solution is to add the overhead in the kernel, > rather than having tc include the overhead in the > pre-calculated rate table. This is what Jesper''s > kernel patch does.yes, and it''s not (my|the) preferred way. Are you sure it can''t be done with static rate table?> > (The rate table is indexed by packet size, and > returns the amount of time required to send a packet > of that size. It is a fixed size table of 256 > entries (0..255). Since packets can be bigger than > 255 bytes long, the packet size is first scaled so > it will fit into the 0..255 range. Scaling is > achieved by dividing the packet size by a power of 2 > (ie 1, 2, 4, 8, etc). A scale factor of 8 handles > packet sizes of 1024..2047, so this is what most > links end up using.) > > If you don''t patch the kernel, the rate calculated by > the kernel will be wrong around 10% of the time (as > opposed to very nearly 100% of the time if you don''t > use the patch at all).the rate table difference varies with different overhead parameters. you can try it with my program (see my other lartc posting). But i think it must be possible to compensate this. But i can''t see my fault.> 2. Jasper didn''t make including the atm cell overhead > optional - so it is included for all links, whether > they use atm or not. Thus he doesn''t have an "atm" > parameter. This means it isn''t general purpose, and > could not be distributes as part of the standard tc > package.yes, thats important. But it would be better if we have this as boolean option rather than a second overhead argument. Add a boolean option for cell alignment and use existing overhead parameter for aal5/ppp/pppoe/llc stuff.> In any case, apart from those two relatively minor > differences the two patches are the identical in what > they achieve and how they do it.yes, except the slightly different rate tables you (and me) mentioned above.> Personally, I didn''t care much about any of this > before VOIP because when it is all said and done, the > 3% error you get for large packet sizes is easily > accounted for by just adjusting the rate accordingly.if we could do it better, we should do it :)> That doesn''t work when the error rate rises to 40%, as > it does for VOIP. As VOIP is going to become a > significant part of internet traffic in the not too > distant future, I think it is time to consider including > some combination of these patches into the main line.100% agree. -- Markus Schulz This is Linux Land- In silent nights you can hear the windows machines rebooting
On Fri, 2006-03-03 at 02:23 +0100, Markus Schulz wrote:> The second rate table is 100% equivalent to realtime calc. But the > static version differs for some ip-length values from it. And i don''t > understand why. > Perhaps someone can point me to the difference? > The program is only for testing rate tables calculations. > > It would be nice to do it without a htb or other qdisc module patch. And > i think it should be possible :)It is not possible. The basic operation performed by the kernel is, in pseudo code: time_to_send_packet = rate_table[packet_length(packet)] However, rate_table is always exactly 256 entries long. An MTU is around 1500 bytes, so a large packet this would index past the end of the table. This means the packet length must be scaled back to a value that fits within 0..255. Divisions are not allowed within the kernel, so the scaling is done using a right shift. In effect, for typical MTU''s, the packet_length is divided by 8. That is, 8 is the multiple of two (ie 8 = 2^N) such that (1500 / 8 < 256). So the rate table really looks like this: packet_length 0..7 = rate_table[0] packet_length 8..15 = rate_table[1] packet_length 16..23 = rate_table[2] packet_length 14..31 = rate_table[3] packet_length 32..39 = rate_table[4] packet_length 40..47 = rate_table[5] packet_length 48..55 = rate_table[6] : Now by pure luck, this works with an ATM cell, if we know the packet length accurately. It works because the boundary 40..47/48..55 is exactly where we want it to be - on a cell boundary. This is because 48 is evenly divisible by 16, and so our luck would continue up to MTU''s of 4095 (= 256 * 16 - 1). Now consider what happens if we include an overhead the kernel doesn''t know about. Lets say 2 bytes. Now our rate table looks like this: packet_length 2..9 = rate_table[0] packet_length 10..17 = rate_table[1] packet_length 18..25 = rate_table[2] packet_length 16..33 = rate_table[3] packet_length 35..41 = rate_table[4] packet_length 42..49 = rate_table[5] packet_length 50..57 = rate_table[6] : Now the cell boundary occurs within a single rate table entry, 42..49. There is no way that single rate table table entry can be correct for both 42..48, and 49, so it all falls in a heap. The simplest solution appears to be to make the kernel aware of the overhead. That way it can always compute the correct packet length before computing the atm cell overhead, and we are back to the original case where the atm payload length changed between rate table cells, and all is good again. That of course requires a patch to the kernel. But even without the patch you are still better off with having tc include the atm cell overhead in the rate table. It will be wrong about 10% of the time (4 packet lengths in 48), as opposed to being wrong all of the time.
Am Freitag, 3. März 2006 02:54 schrieb Russell Stuart:> On Fri, 2006-03-03 at 02:23 +0100, Markus Schulz wrote: > > The second rate table is 100% equivalent to realtime calc. But the > > static version differs for some ip-length values from it. And i > > don''t understand why. > > Perhaps someone can point me to the difference? > > The program is only for testing rate tables calculations. > > > > It would be nice to do it without a htb or other qdisc module > > patch. And i think it should be possible :) > > It is not possible. >[.. convincing reasons ..] okay, thanks. After writing some rate tables on a paper i''m really understand the problematic. We need a htb patch or bigger rate tables (#==mtu) :) -- Markus Schulz A: Because it breaks the logical sequence of discussion Q: Why is top posting bad?
On netBSD setting the MTU also seems to set the MRU, is this the case here to? should people have thier DSLAMs configured for the same MTU?> Just remember to take 14 from your overhead if your modem is connected > via eth rather than ppp etc. This means you need to put a negative > overhead (can you?) if using pppoa/vcmux > > > > Setting the MTU to 1478 is probably a good idea to prevent excessive > > cell usage. Reasoning behind this being: 1488 is the largest multiple of > > 48 under 1500, less 2 bytes for the PPP header and 8 for the AAL5 > > footer. > > > > Perhaps you can confirm this isn''t way off the mark Andy? :) > > 1478 is optimal if your overhead is 10 - I use it. > > For the pppoes I don''t think you gain much as you loose tcp data > efficiency by using smaller packets. > > Andy. > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >Robin-David Hammond KB3IEN www.aresnyc.org.
On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote:> Any chance something like this can be applied to q_tbf? It''s been classful > for a while and I find a tbf with a prio under it works quite well for mytbf qdisc is classfull?
On Friday 03 March 2006 08:43, Andreas Hasenack wrote:> On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote: > > Any chance something like this can be applied to q_tbf? It''s been > > classful for a while and I find a tbf with a prio under it works quite > > well for my > > tbf qdisc is classfull?It has been since like 2.6.9, yes. I was as surprised as you, but I use it with a leaf prio all the time and have for a year now. -- Jason Boxman http://edseek.com/ - Linux and FOSS stuff
On Fri, Mar 03, 2006 at 11:18:00AM -0500, Jason Boxman wrote:> On Friday 03 March 2006 08:43, Andreas Hasenack wrote: > > On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote: > > > Any chance something like this can be applied to q_tbf? It''s been > > > classful for a while and I find a tbf with a prio under it works quite > > > well for my > > > > tbf qdisc is classfull? > > It has been since like 2.6.9, yes. I was as surprised as you, but I use it > with a leaf prio all the time and have for a year now.If this is correct, then the docs are really in bad shape. They are not only outdated, but just plain wrong in many cases. But tbf is still not your regular classfull qdisc, or I''m missinterpreting things: # tc qdisc add dev eth0 handle 1: root tbf rate 300kbit burst 10k latency 10ms # tc class add dev eth0 classid 1:1 parent 1: tbf Error: Qdisc "tbf" is classless. or # tc qdisc add dev eth0 handle 1: root tbf rate 300kbit burst 10k latency 10ms # tc class add dev eth0 classid 1:1 parent 1: prio Error: Qdisc "prio" is classless. I''m using iproute2-2.6.15 and kernel-2.6.12
Andreas Hasenack said:> On Fri, Mar 03, 2006 at 11:18:00AM -0500, Jason Boxman wrote: >> On Friday 03 March 2006 08:43, Andreas Hasenack wrote: >> > On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote: >> > > Any chance something like this can be applied to q_tbf? It''s beenclassful for a while and I find a tbf with a prio under it works quite well for my>> > >> > tbf qdisc is classfull? >> >> It has been since like 2.6.9, yes. I was as surprised as you, but I use it >> with a leaf prio all the time and have for a year now. > > If this is correct, then the docs are really in bad shape. They are notonly outdated, but just plain wrong in many cases. Yes.> But tbf is still not your regular classfull qdisc, or I''m missinterpretingthings: tc qdisc add dev eth0 root handle 1: tbf rate ${RATE}kbit \ burst 1600 limit 1 tc qdisc add dev eth0 parent 1:1 handle 2: prio bands 4 tc qdisc add dev eth0 parent 2:1 handle 10: pfifo limit 10 tc qdisc add dev eth0 parent 2:2 handle 20: pfifo limit 10 tc qdisc add dev eth0 parent 2:3 handle 30: pfifo limit 10 tc qdisc add dev eth0 parent 2:4 handle 40: tbf rate \ $(($RATE-32))kbit burst 1600 limit 1 tc qdisc add dev eth0 parent 40:1 handle 33: sfq perturb 1 But, you''re right. Classful is probably the wrong way of saying it. Perhaps I meant you can attach a different queueing disipline besides using tbf. It''s more like tbf has a nested bfifo attached, which you can replace with anything you want since around 2.6.9. I guess I''m used to using prio and tbf, where you can attach various leaf qdiscs and have more leaf qdiscs attached. It''s certainly not the same thing as cbq, htb, or hfsc. Oops. My bad. It''s still a useful approach I find, though. For a single user I found a prio, but limited by tbf, works quite well for my DSL connection. The ATM "cell tax" is the final barrier I''m hoping to break down soon. I''ve just been too lazy to mess with it. I had Ed''s patch for DSL for `tc` a while ago, but I was too lazy to patch it back into recent Debian iproute packages and then rebuild.
On Fri, Mar 03, 2006 at 01:45:31PM -0500, Jason Boxman wrote:> Andreas Hasenack said: > > On Fri, Mar 03, 2006 at 11:18:00AM -0500, Jason Boxman wrote: > >> On Friday 03 March 2006 08:43, Andreas Hasenack wrote: > >> > On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote: > >> > > Any chance something like this can be applied to q_tbf? It''s been > classful for a while and I find a tbf with a prio under it works > quite well for my > >> > > >> > tbf qdisc is classfull? > >> > >> It has been since like 2.6.9, yes. I was as surprised as you, but I use it > >> with a leaf prio all the time and have for a year now. > > > > If this is correct, then the docs are really in bad shape. They are not > only outdated, but just plain wrong in many cases. > > Yes. > > > But tbf is still not your regular classfull qdisc, or I''m missinterpreting > things: > > tc qdisc add dev eth0 root handle 1: tbf rate ${RATE}kbit \ > burst 1600 limit 1 > tc qdisc add dev eth0 parent 1:1 handle 2: prio bands 4 > tc qdisc add dev eth0 parent 2:1 handle 10: pfifo limit 10 > tc qdisc add dev eth0 parent 2:2 handle 20: pfifo limit 10 > tc qdisc add dev eth0 parent 2:3 handle 30: pfifo limit 10 > tc qdisc add dev eth0 parent 2:4 handle 40: tbf rate \ > $(($RATE-32))kbit burst 1600 limit 1 > tc qdisc add dev eth0 parent 40:1 handle 33: sfq perturb 1 > > But, you''re right. Classful is probably the wrong way of saying it. > > Perhaps I meant you can attach a different queueing disipline besides using > tbf. It''s more like tbf has a nested bfifo attached, which you can replace > with anything you want since around 2.6.9. > > I guess I''m used to using prio and tbf, where you can attach various leaf > qdiscs and have more leaf qdiscs attached. It''s certainly not the same > thing as cbq, htb, or hfsc. Oops. My bad.Thanks for the example and the explanation, it was very helpful. It also means I can try new things :)
gentoo@databit7.com wrote:> > On netBSD setting the MTU also seems to set the MRU, is this the case > here to? should people have thier DSLAMs configured for the same MTU?It doesn''t set MRU - you can still receive a larger than MTU packet. I guess what you mean is MSS, if so yes Linux and Windows TCP also choose what tcp MSS to advertise by looking at the MTU on the interface. This means you get the tweak both ways. If you can''t change each LAN PC then you can do it with Linux iptables set mss, you can make it aysymmetric and have min limits this way aswell. The DSLAM is at the exchange. Doing it on the router by setting MTUs can cause problems and isn''t as good as doing each client/clamping. If you set the LAN facing interface of the router to less than the clients all the websites/networks that set DF and don''t respond to ICMP frag needed will expose their brokenness. FWIW the only time I see MRU is when I log on (pppoa) to my dsl connection. The other end asks for 32725 so the MTU on my ppp0 gets set to 32725 - it''s lucky I can''t really use it and tc doesn''t pick up on it, though the mtu bit of the atm/dsl hack I use hardcodes it. Andy.
On Fri, 3 Mar 2006, Russell Stuart wrote:> On Thu, 2006-03-02 at 14:23 -0800, Stephen Hemminger wrote: >> I will put it in iproute2 commands when a definitive set of patches >> is sent to me. So far, it still looks like it needs some fine tuning. > > Yes, they need some fine tuning. My ultimate goal here is > to get something into the main line that makes tc/htb work > well for VOIP. I don''t care whether it is my patch, or > something else. > > Jesper''s patch is more mature, and as such is probably the > better starting point. The only problem with using them > is this statement on his web site: > > "Commercial use of my work including the ADSL-optimizer > is not allowed without my knowledge and consent. The > ADSL-optimizer will be released under the GNU public > license." > > ... > > 4. Jesper clarifying the license on his patch.I''ll simply drop this license restriction. Now it is release 100% under GPL. I just held a technical talk about the ADSL-optimizer (4/3-2006) at linuxforum.dk. Where I promised the audience that I would try to get the patches to the kernel and TC into the main line. It seem work on this front is already in progress, Cool! :-) Hilsen Jesper Brouer -- ------------------------------------------------------------------- Master of Computer Science Cand. scient datalog Dept. of Computer Science, University of Copenhagen -------------------------------------------------------------------
Jesper Dangaard Brouer said:><snip>> I just held a technical talk about the ADSL-optimizer (4/3-2006) at > linuxforum.dk. Where I promised the audience that I would try to get the > patches to the kernel and TC into the main line. It seem work on this > front is already in progress, Cool! :-)I reread parts of your thesis last night. Excellent information. I finally patched my 2.6.15.5 kernel last night and use Stuart''s userspace `tc` patch and I''m up and running. So far, things are working extremely well and exceeding my expectations. I only wish I actually knew my PPPoATM overhead, but my modem won''t share. :) (I settled on the highest overhead number provided by Stuart in this thread, although I couldn''t match them up with the numbers presented in your thesis'' ATM overhead summary values so I''m confused.) http://edseek.com/archives/2006/03/13/linux-qos-tc-and-accounting-for-atm-overhead/ I setup the latest -rc of ipp2p and that''s working great against recent eMule / mldonkey traffic, too.
On Mon, 2006-03-13 at 13:09 -0500, Jason Boxman wrote:> I finally patched my 2.6.15.5 kernel last night and use Stuart''s userspace > `tc` patch and I''m up and running. So far, things are working extremely > well and exceeding my expectations. I only wish I actually knew my PPPoATM > overhead, but my modem won''t share. :) (I settled on the highest overhead > number provided by Stuart in this thread, although I couldn''t match them up > with the numbers presented in your thesis'' ATM overhead summary values so > I''m confused.)My calculations in that email were wrong for PPPoA - as someone else pointed out. This is how I calculated it for PPPoA: PPP overhead = 2 ATM AAL5 SAR overhead = 4 ----- 6 Those calculations are right as far as they go, but unfortunately, that isn''t the end of the story. On outbound traffic, ie on traffic your box is transmitting, the packet length reported by the kernel and thus used by htb''s rate calculations includes the layer 2 header. If your layer 2 is Ethernet, then this header is 14 bytes long. I had not allowed for this. For PPPoA this header is stripped off by your ADSL modem before the packet is transmitted over the wire. In effect that means the kernel has added 14 bytes of overhead that doesn''t exist. So the real story for PPPoA is: PPP overhead = 2 ATM AAL5 SAR overhead = 4 less Ethernet header added by kernel = -14 ---- -8 So you need to give a negative overhead figure to "tc". Unfortunately there is currently no way to do that. The same calculation for PPPoE is: PPP overhead = 2 PPPoE overhead = 6 Ethernet Header = 14 Ethernet CRC = 4 ATM AAL5 SAR = 8 less Ethernet header added by kernel = -14 ---- 20 It was also pointed out that inbound, there is also a overhead added to the packet size - a different one. However the "igress" policing feature isn''t commonly used, so that doesn''t matter. What does matter is the IMQ interface. For that interface the original figures I gave were correct - ie there is no header.
On Monday 13 March 2006 19:34, Russell Stuart wrote: <snip>> My calculations in that email were wrong for PPPoA - as > someone else pointed out. This is how I calculated it for > PPPoA: > > PPP overhead = 2 > ATM AAL5 SAR overhead = 4 > ----- > 6 > > Those calculations are right as far as they go, but > unfortunately, that isn''t the end of the story. On > outbound traffic, ie on traffic your box is transmitting, > the packet length reported by the kernel and thus used by > htb''s rate calculations includes the layer 2 header. If > your layer 2 is Ethernet, then this header is 14 bytes > long. I had not allowed for this. For PPPoA this header > is stripped off by your ADSL modem before the packet is > transmitted over the wire. In effect that means the kernel > has added 14 bytes of overhead that doesn''t exist. So > the real story for PPPoA is: > > PPP overhead = 2 > ATM AAL5 SAR overhead = 4 > less Ethernet header added by kernel = -14 > ---- > -8 > > So you need to give a negative overhead figure to "tc". > Unfortunately there is currently no way to do that. > > The same calculation for PPPoE is: > > PPP overhead = 2 > PPPoE overhead = 6 > Ethernet Header = 14 > Ethernet CRC = 4 > ATM AAL5 SAR = 8 > less Ethernet header added by kernel = -14 > ---- > 20So, instead of PPPoA + VC/Mux: tc class add htb … overhead 10 atm PPPoA + VC/LLC: tc class add htb … overhead 18 atm PPPoE + VC/Mux: tc class add htb … overhead 34 atm PPPoE + VC/LLC: tc class add htb … overhead 42 atm we have? PPPoE + VC/Mux: tc class add htb … overhead 20 atm ? PPPoA + ?: tc class add htb … overhead ? atm ? What''s the implication of a negative overhead value for PPPoA? Does that reduce the overhead per MTU such that it positively compensates for the standard 5 byte overhead per ATM cell for each packet? Obviously I don''t follow. -- Jason Boxman http://edseek.com/ - Linux and FOSS stuff
On Mon, 2006-03-13 at 19:49 -0500, Jason Boxman wrote:> So, instead of > > PPPoA + VC/Mux: tc class add htb … overhead 10 atm > PPPoA + VC/LLC: tc class add htb … overhead 18 atm > PPPoE + VC/Mux: tc class add htb … overhead 34 atm > PPPoE + VC/LLC: tc class add htb … overhead 42 atm > > we have? > > PPPoE + VC/Mux: tc class add htb … overhead 20 atm ? > PPPoA + ?: tc class add htb … overhead ? atm ?The complete table, for the _outbound_ direction going over an Ethernet link is: PPPoA + VC/Mux: tc class add htb … overhead -8 atm PPPoA + VC/LLC: tc class add htb … overhead 4 atm PPPoE + VC/Mux: tc class add htb … overhead 20 atm PPPoE + VC/LLC: tc class add htb … overhead 28 atm The complete table for incoming traffic on the IMQ device, regardless of the type of connection, is: PPPoA + VC/Mux: tc class add htb … overhead 10 atm PPPoA + VC/LLC: tc class add htb … overhead 18 atm PPPoE + VC/Mux: tc class add htb … overhead 34 atm PPPoE + VC/LLC: tc class add htb … overhead 42 atm I don''t know what the outbound table would be for a USB ADSL modem - but it is probably one of the two above. Unfortunately the driver for USB ADSL modems varies between devices, and it will depend on whether the USB connection looks like an ATM connection or an Ethernet connection. BTW, if it isn''t already obvious, avoid VC/LLC unless you have no choice.> What''s the implication of a negative overhead value for PPPoA? Does that > reduce the overhead per MTU such that it positively compensates for the > standard 5 byte overhead per ATM cell for each packet?If the 5 byte overhead were per packet sent by the Linux box it wouldn''t be a problem. Unfortunately, it is 5 bytes per 48 bytes (or part thereof) sent by the Linux box. There is no way to allow for it using the overhead parameter if the device is sending different size packets. This is one reason why the "atm" patch is needed.
On Tue, 14 Mar 2006 11:26:12 +1000 Russell Stuart <russell@stuart.id.au> wrote:> The complete table, for the _outbound_ direction going > over an Ethernet link is: > > PPPoA + VC/Mux: tc class add htb … overhead -8 atm > PPPoA + VC/LLC: tc class add htb … overhead 4 atm > PPPoE + VC/Mux: tc class add htb … overhead 20 atm > PPPoE + VC/LLC: tc class add htb … overhead 28 atm > > The complete table for incoming traffic on the IMQ > device, regardless of the type of connection, is: > > PPPoA + VC/Mux: tc class add htb … overhead 10 atm > PPPoA + VC/LLC: tc class add htb … overhead 18 atm > PPPoE + VC/Mux: tc class add htb … overhead 34 atm > PPPoE + VC/LLC: tc class add htb … overhead 42 atmWhy is the PPPoA VC/Mux overhead for outbound traffic 6 octets and 10 octets for inbound? My interpretation of RFC 2364 is that the AAL5 footer for VC multiplexed PPPoA is 8 octets, meaning a -4 overhead on incoming traffic. What am I missing?
Russell Stuart wrote:> On Mon, 2006-03-13 at 13:09 -0500, Jason Boxman wrote: > >>I finally patched my 2.6.15.5 kernel last night and use Stuart''s userspace >>`tc` patch and I''m up and running. So far, things are working extremely >>well and exceeding my expectations. I only wish I actually knew my PPPoATM >>overhead, but my modem won''t share. :) (I settled on the highest overhead >>number provided by Stuart in this thread, although I couldn''t match them up >>with the numbers presented in your thesis'' ATM overhead summary values so >>I''m confused.) > > > My calculations in that email were wrong for PPPoA - as > someone else pointed out. This is how I calculated it for > PPPoA: > > PPP overhead = 2 > ATM AAL5 SAR overhead = 4 > ----- > 6I would say 2 + 8 = 10 for pppoa/vc mux Andy.
Jason Boxman wrote:> Jesper Dangaard Brouer said: > > <snip> > >>I just held a technical talk about the ADSL-optimizer (4/3-2006) at >>linuxforum.dk. Where I promised the audience that I would try to get the >>patches to the kernel and TC into the main line. It seem work on this >>front is already in progress, Cool! :-) > > > I reread parts of your thesis last night. Excellent information. > > I finally patched my 2.6.15.5 kernel last night and use Stuart''s userspace > `tc` patch and I''m up and running. So far, things are working extremely > well and exceeding my expectations. I only wish I actually knew my PPPoATM > overhead, but my modem won''t share. :)You may be able to work it out if you can get a cell count from it. If not, if you have lowish uprate you can tell with ping times. I have 288kbit up and think it would be possible to plot out the min times from lots of ping samples with different packet lengths and see the steps from the bitrate latency of an extra cell. I am not sure if it would be as easy if you use interleave - I''m fast/fast and with one of my modems which gives small jitter I can see the effect quickly, my other modem adds jitter and would need lots of samples to judge. Andy.
On Tue, 2006-03-14 at 13:14 +0000, Andy Furniss wrote:> I would say 2 + 8 = 10 for pppoa/vc muxDam, yes - brain explosion. I have no idea why I wrote 4 for the AAL5 overhead. It is 8. So Jason, the tables should in the next email of been: The complete table, for the _outbound_ direction going over an Ethernet link is: PPPoA + VC/Mux: tc class add htb … overhead -4 atm <-- This line is different (was -8) PPPoA + VC/LLC: tc class add htb … overhead 4 atm PPPoE + VC/Mux: tc class add htb … overhead 20 atm PPPoE + VC/LLC: tc class add htb … overhead 28 atm The complete table for incoming traffic on the IMQ device, regardless of the type of connection, is: PPPoA + VC/Mux: tc class add htb … overhead 10 atm PPPoA + VC/LLC: tc class add htb … overhead 18 atm PPPoE + VC/Mux: tc class add htb … overhead 34 atm PPPoE + VC/LLC: tc class add htb … overhead 42 atm
Russell Stuart wrote:> On Tue, 2006-03-14 at 13:14 +0000, Andy Furniss wrote: > >>I would say 2 + 8 = 10 for pppoa/vc mux > > > Dam, yes - brain explosion. I have no idea why I wrote 4 > for the AAL5 overhead. It is 8. So Jason, the tables > should in the next email of been: > > The complete table, for the _outbound_ directionI am not sure about including inbound/outbound - I shape outbound on ppp0 and imq will add 0 whichever direction the traffic is headed. Whatever interface you shape on, you can check how long htb/whatever sees the packets as, by looking at the byte counters. Andy.
Russell Stuart wrote:> The following patch to tc allows it to perform an exact > ATM / ADSL rate calculation. It adds one extra keyword > to the "tc class add htb ..." command line: "atm". There > isn''t a lot of spare bits hanging around to record this, > so the patch adds the feature at the expense of always > forcing the "overhead" parameter to be even. > > With the patch, these commands will generate a correct > rate table for: > > PPPoA + VC/Mux: tc class add htb ... overhead 10 atm > PPPoA + VC/LLC: tc class add htb ... overhead 18 atm > PPPoE + VC/Mux: tc class add htb ... overhead 34 atm > PPPoE + VC/LLC: tc class add htb ... overhead 42 atmWhat would be the appropriate parameters for an RFC 1483 / 2684 LLC Encapsulation or VC Multiplexing? Would the values above adjusted for the removal of PPPoX compensate? Grant. . . .