Re: [LARTC] Patch to allow for the ATM "cell tax"

[Markus Schulz <msc@antzsystem.de>]

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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc