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
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
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
On Tue, 2006-03-14 at 13:14 +, 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
Russell Stuart wrote:
On Tue, 2006-03-14 at 13:14 +, 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
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
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
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
-
On Tue, 14 Mar 2006 11:26:12 +1000
Russell Stuart [EMAIL PROTECTED] 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
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
[EMAIL PROTECTED] 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
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?
___
LARTC
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
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
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
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
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
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
Hi,
On Thu, 2006-03-02 at 15:49 +, 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
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
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
On Fri, 03 Mar 2006 08:18:52 +1000
Russell Stuart [EMAIL PROTECTED] 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).
Stephen Hemminger said:
On Fri, 03 Mar 2006 08:18:52 +1000
Russell Stuart [EMAIL PROTECTED] 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
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
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
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
Am Donnerstag, 2. März 2006 20:54 schrieb Adam James:
Hi,
On Thu, 2006-03-02 at 15:49 +, 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
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
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
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
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
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.
32 matches
Mail list logo
