On Thu, 2007-01-25 at 01:06 +0100, Patrick McHardy wrote:
> Of course he has to, just like your "atm" parameter. In case
> of stabs it would be something like "stab atm".
The difference being with "atm" he is telling the kernel
he has an ATM line, but with STAB he is telling the
kernel how it sho
Russell Stuart wrote:
> Yuk! Now the user has to say whether he wants to use
> STAB's or not? Currently, apart from some debugging
> params to tc, the user isn't even aware that the
> traffic control is implemented in terms of RTAB's.
> That is how it should be - it is an implementation
> det
On Wed, 2007-01-24 at 17:38 +0100, Patrick McHardy wrote:
> > The two RTAB's are different. Thus you must send
> > different RTAB's to pre-STAB and post-STAB kernels.
> > How is "tc" to decide which one to send? I did add
> > code that checked uname once to solve a very
> > similar problem i
Russell Stuart wrote:
> On Sat, 2007-01-20 at 09:47 +0100, Patrick McHardy wrote:
>
>>Russell Stuart wrote:
>>
>>>b. There is no compatibility problem.
>>
>>Again, (b). You seem to have something in mind, it would be
>>easier if you would just explain exactly where you think there
>>is a problem.
On Sat, 2007-01-20 at 09:47 +0100, Patrick McHardy wrote:
> Russell Stuart wrote:
> > b. There is no compatibility problem.
>
> Again, (b). You seem to have something in mind, it would be
> easier if you would just explain exactly where you think there
> is a problem.
I though I had :(.
Conside
Russell Stuart wrote:
> On Fri, 2007-01-19 at 13:19 +0100, Patrick McHardy wrote:
>
>>[...]
>
> I don't understand - too many negates here
> without parens. Are you saying:
>
> a. Backward / Forward compatibility between the kernel
> and its user space tools isn't an issue, or
>
> b. The
On Fri, 2007-01-19 at 13:19 +0100, Patrick McHardy wrote:
> Russell Stuart wrote:
> > I thought that some degree of compatibility was
> > expected. At the very least the newest version
> > of "tc" must work on _any_ kernel as least as
> > well as the version it replaces did.
> >
> > I also tho
Russell Stuart wrote:
> On Thu, 2007-01-18 at 12:37 +0100, Patrick McHardy wrote:
>
>>>Or are you proposing tc behave differently on different
>>>kernel versions. (I have no problem with that, but
>>>isn't it officially frowned upon?)
>>
>>Yes. There is no way you can make this work on old kernel
On Thu, 2007-01-18 at 12:37 +0100, Patrick McHardy wrote:
> > Or are you proposing tc behave differently on different
> > kernel versions. (I have no problem with that, but
> > isn't it officially frowned upon?)
>
> Yes. There is no way you can make this work on old kernels,
> nobody expects that
On Thu, 2007-01-18 at 05:05 +0100, Patrick McHardy wrote:
> > Yesterday I was chatting about this at LCA 2007, and
> > it dawned on me that there is a problem with the dual
> > RTAB/STAB approach.
> >
> > Currently the lookup in the kernel is
> > time_to_transmit_a_packet = RTAB[packet_length_s
Russell Stuart wrote:
> On Thu, 2006-11-30 at 14:07 +0100, Patrick McHardy wrote:
>
>>Qdiscs don't use RTABs to measure rates but to calculate
>>transmission times. Transmission time is always related
>>to the length, the difference between our patches is that
>>you modify the RTABs in advance to
On Thu, 2006-11-30 at 14:07 +0100, Patrick McHardy wrote:
> Qdiscs don't use RTABs to measure rates but to calculate
> transmission times. Transmission time is always related
> to the length, the difference between our patches is that
> you modify the RTABs in advance to include the overhead
> in
First, sorry for letting you wait so long ..
Russell Stuart wrote:
> On Tue, 2006-10-24 at 18:19 +0200, Patrick McHardy wrote:
>
>>No, my patch works for qdiscs with and without RTABs, this
>>is where they overlap.
>
>
> Could you explain how this works? I didn't see how
> qdiscs that used RTA
On Tue, 2006-10-24 at 18:19 +0200, Patrick McHardy wrote:
> No, my patch works for qdiscs with and without RTABs, this
> is where they overlap.
Could you explain how this works? I didn't see how
qdiscs that used RTAB to measure rates of transmission
could use your STAB to do the same thing. At
On Tue, 24 Oct 2006, Patrick McHardy wrote:
Russell Stuart wrote:
On Mon, 2006-10-23 at 14:39 +0200, Patrick McHardy wrote:
The implementation may be different, but the intention and the
result is the same. I probably would mind less if it wouldn't
affect userspace compatibility, but we nee
Russell Stuart wrote:
> On Mon, 2006-10-23 at 14:39 +0200, Patrick McHardy wrote:
>
>>The implementation may be different, but the intention and the
>>result is the same. I probably would mind less if it wouldn't
>>affect userspace compatibility, but we need to carry this stuff
>>for ever even if
On Mon, 2006-10-23 at 14:39 +0200, Patrick McHardy wrote:
> The implementation may be different, but the intention and the
> result is the same. I probably would mind less if it wouldn't
> affect userspace compatibility, but we need to carry this stuff
> for ever even if we add another implementati
Russell Stuart wrote:
> On Thu, 2006-10-19 at 16:38 +0200, Patrick McHardy wrote:
>
>>I still think this patch shouldn't go in. There's no point in doing the
>>same thing twice, and I haven't heard a compelling argument why it has
>>to be done in a way that only helps qdiscs using rtabs while igno
On Thu, 2006-10-19 at 16:38 +0200, Patrick McHardy wrote:
> I still think this patch shouldn't go in. There's no point in doing the
> same thing twice, and I haven't heard a compelling argument why it has
> to be done in a way that only helps qdiscs using rtabs while ignoring
> statistics and estim
jamal wrote:
> The poor guy has been persistent and has some good ideas and we need to
> encourage him to stick around. Why dont you help him get the patch in
> the shape you think is reasonable? I know you are busy elsewhere and
> your patch has been a while since you last promised. I will try to
On Thu, 2006-19-10 at 16:38 +0200, Patrick McHardy wrote:
> jamal wrote:
> > ACKed-by: Jamal Hadi Salim
> >
> > When Patrick has his patch ready after this goes in we can revisit.
>
> NACK.
>
> I still think this patch shouldn't go in. There's no point in doing the
> same thing twice, and I have
jamal wrote:
> ACKed-by: Jamal Hadi Salim
>
> When Patrick has his patch ready after this goes in we can revisit.
NACK.
I still think this patch shouldn't go in. There's no point in doing the
same thing twice, and I haven't heard a compelling argument why it has
to be done in a way that only hel
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 17 Oct 2006 09:07:24 -0400
> ACKed-by: Jamal Hadi Salim
>
> When Patrick has his patch ready after this goes in we can revisit.
If anything it's too late to put this into 2.6.19 so I'll likely
therefore toss it into net-2.6.20 whenever I open that tree
On Tue, 2006-17-10 at 09:34 +1000, Russell Stuart wrote:
> The Linux traffic's control engine inaccurately calculates
> transmission times for packets sent over ADSL links. For
> some packet sizes the error rises to over 50%. This occurs
> because ADSL uses ATM as its link layer transport, and AT
The Linux traffic's control engine inaccurately calculates
transmission times for packets sent over ADSL links. For
some packet sizes the error rises to over 50%. This occurs
because ADSL uses ATM as its link layer transport, and ATM
transmits packets in fixed sized 53 byte cells.
This changes t
25 matches
Mail list logo
