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