LARTC - Nov 2005 - has anyone tried adsl-optmizer kernel patches for dsl modems?

Hi

I''m using wondershaper like script. But noticed imperfect scheduling.

By googling, I found some patches that takes the aal5 atm overhead in 
the scheduling algorithms.
http://www.adsl-optimizer.dk/ADSL-optimizer/

Before trying it, has anyone tried these patches? they apply on 2.4.29 
kernel and 2.6.9 TC. I use centos4 with a 2.6 kernel, so I can''t try 
these easily.

Thanks

sophana wrote:
> Hi
> 
> I''m using wondershaper like script. But noticed imperfect
scheduling.
> 
> By googling, I found some patches that takes the aal5 atm overhead in 
> the scheduling algorithms.
> http://www.adsl-optimizer.dk/ADSL-optimizer/
> 
> Before trying it, has anyone tried these patches? they apply on 2.4.29 
> kernel and 2.6.9 TC. I use centos4 with a 2.6 kernel, so I can''t
try
> these easily.
They should be OK as long as you are sure about your overheads.

I use something similar and use ceil 286kbit while synced at 288kbit 
without problems.

If your modem is connected by eth rather than ppp then htb/whatever will 
see the packet size as ip len + 14 - so you need to account for that.

I think that produces a corner case (overhead < 14) where you would need 
to put in a negative number - I don''t think that will work, but
haven''t
tried.

Andy.

On Wednesday 16 November 2005 16:03, Andy Furniss wrote:
> sophana wrote:
> > Hi
> >
> > I''m using wondershaper like script. But noticed imperfect
> > scheduling.
> >
> > By googling, I found some patches that takes the aal5 atm overhead
> > in the scheduling algorithms.
> > http://www.adsl-optimizer.dk/ADSL-optimizer/
> >
> > Before trying it, has anyone tried these patches? they apply on
> > 2.4.29 kernel and 2.6.9 TC. I use centos4 with a 2.6 kernel, so I
> > can''t try these easily.
>
> They should be OK as long as you are sure about your overheads.
>
> I use something similar and use ceil 286kbit while synced at 288kbit
> without problems.
>
> If your modem is connected by eth rather than ppp then htb/whatever
> will see the packet size as ip len + 14 - so you need to account for
> that.
can you explain this a bit more please?
> I think that produces a corner case (overhead < 14) where you would
> need to put in a negative number - I don''t think that will work,
but
> haven''t tried.
should be easy to patch in. Overhead is only a simple variable which 
will be added in htb/* module for each paket. Only sign/unsign problem  
should be considered.

msc

Markus Schulz wrote:
>On Wednesday 16 November 2005 16:03, Andy Furniss wrote:
>  
>
>>I use something similar and use ceil 286kbit while synced at 288kbit
>>without problems.
>>    
>>
What thing similar do you use? I don''t understand why it is not in the 
kernel already.
>should be easy to patch in. Overhead is only a simple variable which 
>will be added in htb/* module for each paket. Only sign/unsign problem  
>should be considered.
>  
>
How?

The ppp over aal5 atm encapsulation is in almost all adsl lines isn''t
it?
Isn''t it standard?
This makes a huge number of lines in the world.
Are there other patches ?
or distributions that already include these patches?

Regards

On Wednesday 23 November 2005 14:23, Sophana Kok wrote:
> Markus Schulz wrote:
> >On Wednesday 16 November 2005 16:03, Andy Furniss wrote:
> >>I use something similar and use ceil 286kbit while synced at
> >> 288kbit without problems.
>
> What thing similar do you use? I don''t understand why it is not in
> the kernel already.
sounds like he has calculated the constant overhead for each htb-class 
and set the ceil value to according this. this is equivalent to the 
stuff from adsl-optimizer. in both ways you need to setup classes for 
packets with same average size or it won''t work. Most important is the 
class for ACK-only packets cause they have the biggest overhead. 
correct me if i''m wrong.
> >should be easy to patch in. Overhead is only a simple variable which
> >will be added in htb/* module for each paket. Only sign/unsign
> > problem should be considered.
>
> How?
this refers to the possible negativ overhead mentioned from Andy Furniss 
by use of pppoe. But i don''t understand whencever the -14 Bytes should 
come from. so i asked for explanation. 
If signed overhead is really needed, it can be easy added into the 
patches you meantioned (http://www.adsl-optimizer.dk/ADSL-optimizer/). 
Cause these patches only add a constant offset to a htb class which 
will be set with modified iproute tc utility.
> The ppp over aal5 atm encapsulation is in almost all adsl lines
isn''t
> it? Isn''t it standard?
yes, i think so. therefore i asked Andy to explain his objection.
> This makes a huge number of lines in the world.
> Are there other patches ?
> or distributions that already include these patches?
Don''t know a distribution which already include these patches.
But the effort for a selfmade kernel with these patches is maintainable.

msc

Markus Schulz wrote:
> On Wednesday 16 November 2005 16:03, Andy Furniss wrote:
> 
>>sophana wrote:
>>
>>>Hi
>>>
>>>I''m using wondershaper like script. But noticed imperfect
>>>scheduling.
>>>
>>>By googling, I found some patches that takes the aal5 atm overhead
>>>in the scheduling algorithms.
>>>http://www.adsl-optimizer.dk/ADSL-optimizer/
>>>
>>>Before trying it, has anyone tried these patches? they apply on
>>>2.4.29 kernel and 2.6.9 TC. I use centos4 with a 2.6 kernel, so I
>>>can''t try these easily.
>>
>>They should be OK as long as you are sure about your overheads.
>>
>>I use something similar and use ceil 286kbit while synced at 288kbit
>>without problems.
>>
>>If your modem is connected by eth rather than ppp then htb/whatever
>>will see the packet size as ip len + 14 - so you need to account for
>>that.
> 
> 
> can you explain this a bit more please?
It''s because htb uses skb->len for packet size and if you shape on
an
eth interface this is ip length + 14, but it''s just ip length if you 
shape on ppp/vlan etc.

You can see this by looking at htb counters and sending fixed size packets.
> 
> 
>>I think that produces a corner case (overhead < 14) where you would
>>need to put in a negative number - I don''t think that will
work, but
>>haven''t tried.
> 
> 
> should be easy to patch in. Overhead is only a simple variable which 
> will be added in htb/* module for each paket. Only sign/unsign problem  
> should be considered.
Yep  - you just need to be aware of it and I can''t recall it being 
mentioned in the thesis - I have only tested on 2.6 kernels.

Andy.

Sophana Kok wrote:
> Markus Schulz wrote:
> 
>> On Wednesday 16 November 2005 16:03, Andy Furniss wrote:
>>  
>>
>>> I use something similar and use ceil 286kbit while synced at
288kbit
>>> without problems.
>>>   
> 
> What thing similar do you use? I don''t understand why it is not in
the
> kernel already.
I use my own based on the tc tweak that Ed Wildgoose posted to the list, 
but patching htb aswell so it''s perfect (the tc alone patch is a cell 
too big for some packet sizes)
> 
>> should be easy to patch in. Overhead is only a simple variable which 
>> will be added in htb/* module for each paket. Only sign/unsign 
>> problem  should be considered.
>>  
>>
> How?
> 
> The ppp over aal5 atm encapsulation is in almost all adsl lines
isn''t it?
> Isn''t it standard?
In jeesper''s thesis there is a table - Knowing you overhead can be 
tricky - but you can test, best if your modem gives cell counters or 
even if it doesn''t on adsl you may be able to see differences in 
throughput/latency if you look hard enough.
> This makes a huge number of lines in the world.
> Are there other patches ?
> or distributions that already include these patches?
I don''t think so, patching is easy you need to test and know your 
overheads aswell.

Andy.

Markus Schulz wrote:
> On Wednesday 23 November 2005 14:23, Sophana Kok wrote:
> 
>>Markus Schulz wrote:
>>
>>>On Wednesday 16 November 2005 16:03, Andy Furniss wrote:
>>>
>>>>I use something similar and use ceil 286kbit while synced at
>>>>288kbit without problems.
>>
>>What thing similar do you use? I don''t understand why it is not
in
>>the kernel already.
> 
> 
> sounds like he has calculated the constant overhead for each htb-class 
> and set the ceil value to according this. this is equivalent to the 
> stuff from adsl-optimizer. in both ways you need to setup classes for 
> packets with same average size or it won''t work. Most important is
the
> class for ACK-only packets cause they have the biggest overhead. 
> correct me if i''m wrong.
Nothing to do with htb classes, though you are right about small packets 
  being a pain - they typically use 2 x 53 byte atm cells.

The patches make htb lookup the delay of one less than the aal5 length 
in a table that is generated by a patched tc so the delay returned is 
the delay of the packet when it is atm cells.
> 
> 
>>>should be easy to patch in. Overhead is only a simple variable which
>>>will be added in htb/* module for each paket. Only sign/unsign
>>>problem should be considered.
>>
>>How?
> 
> 
> this refers to the possible negativ overhead mentioned from Andy Furniss 
> by use of pppoe.
It''s pppoa, pppoe has > 14 overhead.

Andy.

Andy Furniss wrote:
>
> Nothing to do with htb classes, though you are right about small 
> packets  being a pain - they typically use 2 x 53 byte atm cells.
>
> The patches make htb lookup the delay of one less than the aal5 length 
> in a table that is generated by a patched tc so the delay returned is 
> the delay of the packet when it is atm cells.
You are right. He is calculating the exact overhead of pppoa inside the 
kernel (not pppoe because pppoe is not the point of congestion). He also 
modified tc so that overhead can be tweaked in the script.

I know the exact atm rate of my adsl line. So it should be possible to 
make an exact scheduling.

The most important application is VOIP on low rate adsl uploads because 
VOIP packets are small.

I still don''t understand why this is not included in the kernel and
tc...

My problem is that I have a 2.6.x kernel and his patch is for 2.4.x kernel.

Andy Furniss wrote:
> Markus Schulz wrote:
>
>> should be easy to patch in. Overhead is only a simple variable which 
>> will be added in htb/* module for each paket. Only sign/unsign 
>> problem  should be considered.
>
>
> Yep  - you just need to be aware of it and I can''t recall it being
> mentioned in the thesis - I have only tested on 2.6 kernels.
I''m sorry, but that does not seem such simple.
In pppoa (ppp over aal5), the packets are atm cell aligned, so the 
overhead depends on the packet size. It is not linear at all.