thr3ads.net - LARTC - Patch to allow for the ATM "cell tax" [Mar 2006]

If this information is useful, please help other people find it:
Share via:

Russell Stuart

2006-Mar-02 07:30 UTC

Patch to allow for the ATM "cell tax"

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

Markus Schulz

2006-Mar-02 13:37 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Markus Schulz

2006-Mar-02 13:51 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Andy Furniss

2006-Mar-02 15:49 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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 atm
Also 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.

Adam James

2006-Mar-02 19:54 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Andy Furniss

2006-Mar-02 21:35 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Russell Stuart

2006-Mar-02 22:18 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Stephen Hemminger

2006-Mar-02 22:23 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Jason Boxman

2006-Mar-02 22:45 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

:)

Russell Stuart

2006-Mar-02 23:44 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Jason Boxman

2006-Mar-03 00:27 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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 +1000
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.

Thanks.

-- 

Jason Boxman
http://edseek.com/ - Linux and FOSS stuff

Russell Stuart

2006-Mar-03 00:43 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Markus Schulz

2006-Mar-03 01:23 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Markus Schulz

2006-Mar-03 01:49 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Russell Stuart

2006-Mar-03 01:54 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Markus Schulz

2006-Mar-03 02:23 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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?

gentoo@databit7.com

2006-Mar-03 02:27 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Andreas Hasenack

2006-Mar-03 13:43 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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?

Jason Boxman

2006-Mar-03 16:18 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Andreas Hasenack

2006-Mar-03 16:45 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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

Jason Boxman

2006-Mar-03 18:45 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Andreas Hasenack

2006-Mar-03 19:34 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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 :)

Andy Furniss

2006-Mar-05 19:27 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Jesper Dangaard Brouer

2006-Mar-06 17:26 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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
-------------------------------------------------------------------

Jason Boxman

2006-Mar-13 18:09 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Russell Stuart

2006-Mar-14 00:34 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Jason Boxman

2006-Mar-14 00:49 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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
>                                           ----
>                                             20
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 ?

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

Russell Stuart

2006-Mar-14 01:26 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Adam James

2006-Mar-14 02:10 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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 atm
Why 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?

Andy Furniss

2006-Mar-14 13:14 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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
>                          -----
>                              6
I would say 2 + 8 = 10 for pppoa/vc mux

Andy.

Andy Furniss

2006-Mar-14 13:25 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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.

Russell Stuart

2006-Mar-14 23:28 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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_ 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

Andy Furniss

2006-Mar-15 00:29 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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_ direction
I 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.

Taylor, Grant

2006-Dec-06 18:59 UTC

head link

Re: Patch to allow for the ATM "cell tax"

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 atm
What 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. . . .

Reasonably Related Threads

Search for more maybe matching threads

LARTC - Mar 2006 - Patch to allow for the ATM "cell tax"

Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Re: Patch to allow for the ATM "cell tax"

Reasonably Related Threads