On Wed, 2011-05-04 at 14:24 -0500, Grant Taylor wrote:
All in favor?
Any one against?
In favour.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
On Wed, 2011-05-04 at 13:06 -0500, Grant Taylor wrote:
Seeing that now messages seem to be flowing in a timely manner, I'd
suggest that we give this list a week to a month probation to see if
it has straightened up it's act.I'd also like a comment from the list
maintainer or a moderator in
On Wed, 2007-07-25 at 15:14 +0200, Edouard Thuleau wrote:
I use the patch
(http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate
the packet scheduling on ATM/ADSL link and i think I've found a bug.
I tried to write to the author but he didn't answer me.
Sorry. :( I have now.
On Thu, 2007-06-28 at 12:28 +0200, Marek Michalkiewicz wrote:
Do you have an updated version of your patches for the latest
kernel (soon to be 2.6.22), iptables and iproute? Or can the
current patches be safely applied (with some merging by hand,
but no significant changes) to the latest
On Thu, 2007-06-28 at 18:35 +0200, Roel van Meer wrote:
Hi list,
I have a quick question about the priority mapping of tos bits. The manpage
of tc-prio shows a nice table with tos bits and the band they
are mapped to:
TOS Bits MeansLinux PriorityBand
On Fri, 2007-06-01 at 13:24 +0200, Michal Soltys wrote:
TC's syntax, particulary u32 filter, is far more rich than what man,
howto or command's help provides. I've been looking for information
about the uses of 'offset' parameter, or more detailed explanation of a
few other/relevan options,
On Thu, 2006-07-20 at 14:56 +1000, Russell Stuart wrote:
On Wed, 2006-07-19 at 16:50 +0200, Patrick McHardy wrote:
Please excuse my silence, I was travelling and am still catching up
with my mails.
Sorry. Had I realised you were busy I would of
waited.
- As it stands, it doesn't
. I agree the flexibility of making STAB
variable length is a good idea, and comes at 0 cost in
the kernel.
Andy Furniss wrote:
Russell Stuart wrote:
The kernel will have to do a shift and a division
for each packet, which I assume is permissible.
I guess that is for others to decide
On Thu, 2006-07-20 at 01:00 +0400, Alexey Kuznetsov wrote:
Hello!
So you really do exist? I thought it was just
rumour.
Well, if fixed point arithmetics is not a problem.
It shouldn't be. Any decimal number can be expressed
as a fraction, eg:
0.00123 = 123/10
Which can be calculated
On Sat, 2006-06-24 at 10:13 -0400, jamal wrote:
And yes, I was arguing that the tc scheme you describe would not be so
bad either if the cost of making a generic change is expensive.
snip
Patrick seems to have a simple way to compensate generically for link
layer fragmentation, so i will not
On Fri, 2006-07-07 at 10:00 +0200, Patrick McHardy wrote:
Russell Stuart wrote:
Unfortunately you do things in the wrong order for ATM.
See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html
for an overview of the problem, and then the attached email for
a detailed description
On Tue, 2006-07-04 at 15:29 +0200, Patrick McHardy wrote:
Unfortunately I still didn't got to cleaning them up, so I'm sending
them in their preliminary state. Its not much that is missing, but
the netem usage of skb-cb needs to be integrated better, I failed
to move it to the qdisc_skb_cb so
On 26/06/2006 9:10 PM, Patrick McHardy wrote:
5. We still did have to modify the kernel for ATM. That was
because of its rather unusual characteristics. However,
it you look at the size of modifications made to the kernel
verses the size made to the user space tool, (37 lines
On Fri, 2006-06-23 at 17:21 +0200, Patrick McHardy wrote:
Not really. The randomization doesn't happen by default, but it doesn't
influence this anyway. SFQ allows flows to send up to quantum bytes
at a time before moving on to the next one. A flow that sends 75 * 20
byte will in the eyes of
On 25/06/2006 12:13 AM, jamal wrote:
You can actually stop reading here if you have gathered the view at
this point that i am not objecting to the simple approach Patrick is
going with...
Perhaps this is my problem. I am not sure I understand
what Patrick is proposing. I can wait for his
On Thu, 2006-06-22 at 14:29 -0400, jamal wrote:
Russell,
I did look at what you sent me and somewhere in those discussions i
argue that the changes compensate to make the rate be a goodput
instead of advertised throughput.
I did see that, but didn't realise you were responding to
me. A
On Thu, 2006-06-15 at 11:49 +0200, Martin Devera wrote:
At time of HTB implementation I needed to reach 100MBit speed on
relatively slow box. The hysteresis was a way. On other side I used
hand-made TSC based measure tool to compute exact (15%) performance
gain. Today I'd measure it using
for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
This is a combined effort of Jesper Brouer and Russell
Stuart, to get these patches into the upstream kernel.
Let the discussion start about what we need
for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart [EMAIL PROTECTED]
Signed-off-by: Jesper Dangaard Brouer [EMAIL PROTECTED]
---
diff -Nurp iproute2.orig/include/linux
On Fri, 2006-03-17 at 09:34 -0500, jamal wrote:
If you are unable to do this then I will. I just dont have time until this
Sunday.
I will not respond to any further emails which do not contain data - instead
I am going to produce mine.
After that wrist-slap I spent some time putting together
On Fri, 2006-03-17 at 09:34 -0500, jamal wrote:
- the 2.4 algorithm performs very poorly for 8 bits if you use a
standard mask for ALL cases except when you use a lot of memory, most of
which is _wasted_, in which case it performs equally. There are only 8
masks in an 8 bit ranging from
On Thu, 2006-03-16 at 08:51 -0500, jamal wrote:
BTW, in this example, the new hash I suggested would be as good
as the 2.6 case.
Yes, if you used 256 buckets per hash table ;-
No - you haven't understood what the new algorithm does.
It will get the same performance of the 2.6 version
snipMuch discussion bashing this issue to death./snip
(sorry, jamal - this one is CC'ed to lartc.)
Here is are revised versions of the 2 as yet unapplied
patches.
PATCH 1
===
[Has been applied.]
PATCH 2
===
In tc, the u32 sample clause uses the 2.4 hashing algorithm.
The hashing
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
On Sat, 2006-03-11 at 08:11 -0500, jamal wrote:
On my machine tc does not parse filter sample for the u32
filter. Eg:
tc filter add dev eth2 parent 1:0 protocol ip prio 1 u32 ht 801: \
classid 1:3 \
sample ip protocol 1 0xff match ip protocol 1 0xff
Illegal sample
On Mon, 2006-03-13 at 10:04 -0800, Stephen Hemminger wrote:
The memset fix is in current CVS. I just wasn't going to take the
patch that looked at utsname to decide what hash to use.
Stephen, could you describe your objections to it please?
___
On Mon, 2006-03-13 at 13:50 -0800, Stephen Hemminger wrote:
On Tue, 14 Mar 2006 07:43:57 +1000
Russell Stuart [EMAIL PROTECTED] wrote:
On Mon, 2006-03-13 at 10:04 -0800, Stephen Hemminger wrote:
The memset fix is in current CVS. I just wasn't going to take the
patch that looked
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 Sat, 2006-03-11 at 08:11 -0500, jamal wrote:
On Fri, 2006-10-02 at 12:33 +1000, Russell Stuart wrote:
This patch adds a divisor option to tc's sample
clause:
While this looks right - can we have more test data with tc filter ls
both before and after your fix? Specify divisor of 256
On Sat, 2006-03-11 at 10:56 -0500, jamal wrote:
Right - take a look at the use of hashkey with varying divisors to see
where the 2.4 folding breaks[1]. Note you should be able to use hashkey
instead of sample and it would work fine.
snip
[1] Essentially, if you teach u32 in 2.4 to spread
List admins. Can you fix the issue described below,
ie jamal's posts to the lists bouncing, please?
Forwarded Message
From: Russell Stuart [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Stephen Hemminger [EMAIL PROTECTED], netdev@vger.kernel.org
Subject: Re: [PATCH] TC: bug
On Sun, 2006-03-05 at 10:16 +0100, Andreas Klauer wrote:
htb class parent 1: classid 1:10 rate 80% ceil 100%
To my understanding, a root class that has a higher ceil than rate
can always use bandwidth up to it's ceil. Thus it would be more
correct to set the rate to 100% here
On Mon, 2006-03-06 at 02:19 +0100, Andreas Klauer wrote:
The revised class structure is now:
htb class parent 1: classid 1:10 rate 80% ceil 100%
htb class parent 1:10 classid 1:11 rate 100% ceil 100%
htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf]
On Fri, 2006-02-24 at 07:27 +1000, Russell Stuart wrote:
On Thu, 2006-02-23 at 10:23 +0100, Andreas Klauer wrote:
Another way of indirect headroom would be to hard limit the Web class,
i.e. give the Web class a lower ceil than the other classes. This way,
there is bandwidth that the Web
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 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 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
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
));
}
return cell_log;
--
Regards,
Russell Stuart
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
I am trying to do ingress flow control with htb + imq,
and as could be expected it isn't working well.
It works a lot better when I keep the htb ceiling well
below what the link can actually carry - I guess because
htb gets to throttle the TCP fast start before it causes
packets to be dropped.
On Thu, 2006-02-23 at 19:49 -0800, gypsy wrote:
Two more things. HTTP is a bursty protocol, so you need to think about
the burst and cburst parameters you give it.
I had already figured out that I had to send burst as small as
possible. I recall reading both value is the
If you want to
Sorry for the mess posted before. I hit send by mistake.
On Thu, 2006-02-23 at 19:49 -0800, gypsy wrote:
Two more things. HTTP is a bursty protocol, so you need to think about
the burst and cburst parameters you give it.
I had already figured out that I had to sent burst as
small as
PATCH 1
===
On my machine tc does not parse filter sample for the u32
filter. Eg:
tc filter add dev eth2 parent 1:0 protocol ip prio 1 u32 ht 801: \
classid 1:3 \
sample ip protocol 1 0xff match ip protocol 1 0xff
Illegal sample
The reason is a missing memset. This patch fixes
I have found a few bugs in tc, and have produced patches
for them. Two require changes to tc, one to the kernel.
Where should I post these patches?
--
Regards,
Russell Stuart
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi
44 matches
Mail list logo
