[adsl-qos] PPPoA support and other stuff.

[Andy Furniss]

Bartosz Oudekerk wrote:
> Andy Furniss is thought to have typed the following 
> text on Fri, 05 Nov, 2004 at 09:04:01PM +0000:
> 
> 
>>Bartosz Oudekerk wrote:
>>
>>>I don't really think that's correct, first of all the ip_pkt_len has a
>>>minimum lenght of 46 octets. 
>>
>>No it doesn't - I can send one cell with ping -s 10 (= ip_len 38)
>>
>>You're also forgetting to add the Ethernet
>>
>>>overhead "(6+6+2)",
>>
>>There is no ethernet overhead for pppoa.
>>
> 
> Well, I did some more reading now (to properly fund my arguments for
> proving you wrong), but found you're completely right.
> 
> 
>> and of a technical note, which doesn't matter for
>>
>>>this calcultion, but is an argument for another notation, with PPPoA,
>>>the 2 octets for PPP are added to the AAL5 payload, not the ethernet
>>>payload. This would make a notation like such:
>>>
>>>return 
>>>((((((6+6+2)+(((ip_pkt_len)<46)?46:(ip_pkt_len))+2)+(1+1+2+4))-1)/48)+1)*53;
>>>
>>>This also matches most (The last -/+1 shouldn't be added if the result
>>>already is divisible by 48[0], I think) of the numbers dslforum gives in
>>><URL:http://www.dslforum.org/aboutdsl/Technical_Reports/TR-043.pdf>
>>>
>>>With your calculation the numbers don't even come close.
>>
> Looking at it again, your numbers are correct, I don't really know what
> I messed up to get different data from your calculation. Probably
> introduced a typo somewhere, I appologise.
> 
> 
>>Yes sorry it should have been
>>
>>( (int)(((ip_pkt_len+10)-1)/48)+1) *53
>>
> 
> I don't really understand what the int (which stands for integer, I
> assume) is above.

Lol - that was just me looking for something wrong - the function and 
ip_pkt_len are ints anyway - so it's OK as is.

> 
> But you're completely right again, although I would write it (for
> clarity, no other reason) as
> 
> (((((ip_pkt_len+2)+(1+1+2+4))-1)/48)+1)*53;
> 
> Thanks for pointing out I was wrong and making me double-check
> everything.
> 
> In your first post, you mentioned using something else, in-kernel, now,
> would you be willing to share what that is?
> 

A while back Ed Wildgoose posted a patch on the LARTC list. While it's 
not perfect it does let you max your link alot better than without. It 
hacks the calculations TC uses to generate look up tables for queues.

I started looking into trying to get it perfect, but to do things 
perfectly you either need to have lookup tables 16x bigger ( ie one 
lookup per byte packet length) or you need to add ppp overhead (-1) to 
the call in the queues code aswell (eg HTB).

I may be trying HFSC soon, so I never bothered doing it - I think HFSC 
does it's own tables, so I would need to change those anyway.

Ed's settings are safe but a cell too long for some packet lengths.

Andy.

Here is Ed's origional post - I had to mess around a bit to get gcc 2.95 
to compile it. I run something similar with iproute-2.6.8 .

-----------------------------------------------------------------------

OK, here it is.  Near perfect bandwidth calculation for ADSL users. 
Patch iproute2 with the HTB stuff and then this:

It's still a hack (as far as I can tell) because we are patching the 
rates tables, and hence I think it is only loosly coupled with the 
actual calculation of bytes in each bucket.
However, it works very nicely for me!  I have only been lightly testing 
with downloading stuff (hence packet dropping to slow rates), and I can 
set the max download rate to within a few kbyte/sec of the maximum and 
still keep near min ping times.  I assume that the remaining sliver of 
bandwidth is taken up passing packets which arrive in a slight cluster, 
and for packets which I later need to drop (since I'm testing on an 
incoming interface and dropped packets don't count for bandwidth used 
calcs).  However, I seem to be able to get *extremely* close to the max 
with this patch

Obviously all the numbers are hard coded, but they should be suitable 
for all ATM users.  PPoE users will need to do something different (if 
someone can supply the details then I will see what we can do to make a 
more generic patch and use module params.

Note: That this code will probably affect the policer and CBQ modules in 
the same way as HTB, however, I don't have such a setup, so I can't test 
effectiveness (or detriment...).  Feedback appreciated

Note also that rates in your scripts will now be expressed in terms of 
the ATM bandwidth, ie you put in something like the bandwidth you paid 
for, but (of course) you get roughly (bw * 48/53) passing through (this 
is normal, it's the overhead of running ATM).


--- iproute2-2.4.7.20020116/tc/tc_core.c        2000-04-16 
18:42:55.000000000 +0100
+++ iproute2/tc/tc_core.c       2004-06-18 12:20:39.912974518 +0100
@@ -59,10 +59,19 @@
                while ((mtu>>cell_log) > 255)
                        cell_log++;
        }
+
+       // HACK - UK ATM Params
+       int encaps_cell_sz = 53;
+       int encaps_cell_overhead = 5;
+       int encaps_data_sz = encaps_cell_sz - encaps_cell_overhead;
+       int proto_overhead = 10; // PPP Overhead
+
        for (i=0; i<256; i++) {
-               unsigned sz = (i<<cell_log);
-               if (sz < mpu)
-                       sz = mpu;
+               unsigned sz = ((i+1)<<cell_log)-1;
+                sz = sz + proto_overhead;
+               sz = (  (int)((sz-1)/encaps_data_sz) + 1) * encaps_cell_sz;
+//             if (sz < mpu)
+//                     sz = mpu;
                rtab[i] = tc_core_usec2tick(1000000*((double)sz/bps));
        }
        return cell_log;

------------------------------------------------------------------------------------