On Wed, 2006-08-09 at 07:33 -0400, jamal wrote:
> > Jamal - unless there are other outstanding issues I have
> > missed or someone has had second thoughts this means you
> > should be OK with the patch going in. Can we get it into
> > Dave M's tree now?
>
> Hi Russell,
>
> My apologies; at some
On Wed, 2006-09-08 at 08:01 +1000, Russell Stuart wrote:
> On Mon, 2006-07-31 at 09:06 +1000, Russell Stuart wrote:
> > It has gone quiet again. In my mind the one unresolved issue
> > is whether Patrick intended to remove RTAB with his patch.
> > If not, the ATM patch as it stands will have to go
On Mon, 2006-07-31 at 09:06 +1000, Russell Stuart wrote:
> It has gone quiet again. In my mind the one unresolved issue
> is whether Patrick intended to remove RTAB with his patch.
> If not, the ATM patch as it stands will have to go in.
>
> Patrick - it would be nice to hear from you.
It appear
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
Hello!
> It shouldn't be. Any decimal number can be expressed
> as a fraction, eg:
I remember this. :-) I stalled selecting corrects divisors
to fight over/underflows. Not becuase it was difficult,
just because did not see a reason to do this.
> But doing so would get rid of the table impleme
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 calculate
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 help the qdiscs that use
> > RTAB. So unless he proposes to r
Hello!
> Guess that Alexey wrote these RTAB lookup in a time where array lookups
> was faster... now we have that memory lookups are the bottleneck.
No, they were slower from the very beginning. If I remember correctly,
there is comment about this somewhere.
I just did not find any simple way t
Russell Stuart wrote:
- As it stands, it doesn't help the qdiscs that use
RTAB. So unless he proposes to remove RTAB entirely the ATM patch as
it will still have to go in.
Here is a very important point here:
The RTAB (rate-table) in the kernel is NOT aligned, this is the ONLY
reason wh
Andy Furniss wrote:
> Russell Stuart wrote:
>
>> - As it stands, it doesn't help the qdiscs that use RTAB. So unless
>> he proposes to remove RTAB entirely the ATM patch as it will still
>> have to go in.
>
>
> Hmm - I was just looking at the kernel changes to htb. The only
> difference is
Russell Stuart wrote:
> On Tue, 2006-07-18 at 22:46 +0100, Andy Furniss wrote:
>
>>FWIW I think it may be possible to do it Patricks' way, as if I read it
>>properly he will end up with the ATM cell train length which gets
>>shifted by cell_log and looked up as before. The ATM length will be in
Russell Stuart wrote:
On Tue, 2006-07-18 at 22:46 +0100, Andy Furniss wrote:
FWIW I think it may be possible to do it Patricks' way, as if I read it
properly he will end up with the ATM cell train length which gets
shifted by cell_log and looked up as before. The ATM length will be in
steps o
On Tue, 2006-07-18 at 22:46 +0100, Andy Furniss wrote:
> FWIW I think it may be possible to do it Patricks' way, as if I read it
> properly he will end up with the ATM cell train length which gets
> shifted by cell_log and looked up as before. The ATM length will be in
> steps of 53 so with cel
Russell Stuart wrote:
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.
Patrick seems to have a simple way to compensate generically for link
layer fragmenta
Russell,
I apologize i havent followed the latest discussion to the detail.
My understanding of Patricks work was it solved the ATM problem as well.
I think he is busy somewhere - lets give him an opportunity to respond
and i will try to catchup with the thread as well.
cheers,
jamal
On Tue, 2006
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.
> Patrick seems to have a simple way to compensate generically for link
> layer fragmentation, so i will not ar
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 descrip
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 of how the current patch addresses it.
> It is a trivial fix.
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
jamal wrote:
> On Tue, 2006-04-07 at 15:29 +0200, Patrick McHardy wrote:
>
>>Russell Stuart wrote:
>
> [..]
>
>>>Without seeing your actual proposal it is difficult to
>>>judge whether this is a reasonable trade-off or not.
>>>Hopefully we will see your code soon. Do you have any
>>>idea when?
On Tue, 2006-04-07 at 15:29 +0200, Patrick McHardy wrote:
> Russell Stuart wrote:
[..]
> > Without seeing your actual proposal it is difficult to
> > judge whether this is a reasonable trade-off or not.
> > Hopefully we will see your code soon. Do you have any
> > idea when?
>
> Unfortunately I s
Russell Stuart wrote:
> 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 t
On Sun, 2006-02-07 at 06:23 +0200, Patrick McHardy wrote:
[..]
> > - Any message to user space may be lost whether it has ifi_change or
> > not. You need some way to figure out a message was lost and declare your
> > state may be invalid. The -ENOBUFs is one way to discover stale state.
>
> Thats
Sorry, missed your reply so far.
>>Then what is the intent, it doesn't carry any other information?
>
>
> Generally it is a filter to what the ifi_flags reflect.
>>From an event architecture scalability perspective, it is useful to be
> able to look at what changed without having to query the so
Russell Stuart wrote:
> Without seeing your actual proposal it is difficult to
> judge whether this is a reasonable trade-off or not.
> Hopefully we will see your code soon. Do you have any
> idea when?
Probably not today, I'll try to get it into shape until tomomorrow.
-
To unsubscribe from this
On Mon, 2006-26-06 at 13:21 +0200, Patrick McHardy wrote:
> jamal wrote:
> > scalability issues abound when you have a gazillion things to look at.
> > There used or may still be a way to tell from looking at netlink socket
> > that an error occurred since last time - such as "a message was lost".
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
versu
jamal wrote:
> On Fri, 2006-23-06 at 16:32 +0200, Patrick McHardy wrote:
>
>>I don't think it should carry both old and new speed. Netlink
>>notifications usually provide a snapshot of the new state, but
>>no indication what changed, with one notable exception, the
>>ifi_change field, which IMO is
Russell Stuart wrote:
> 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
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 patc
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 eye
On Fri, 2006-23-06 at 16:32 +0200, Patrick McHardy wrote:
> jamal wrote:
> > If you do it in user space you will need a daemon of some form; this is
> > my preference but it seems a lot of people hate daemons - the standard
> > claim is it is counter-usability. Such people are forgiving if you bui
On Fri, 2006-23-06 at 22:37 +1000, Russell Stuart wrote:
> Sorry for the digest like reply :(
;-> I know this discussion has gone in a few directions already
and i am sure as you kept responding to the emails it became obvious.
Let me just jump to one point so we dont repeat a lot of the same th
Russell Stuart wrote:
> On Thu, 2006-06-22 at 14:29 -0400, jamal wrote:
>
> On Tue, 2006-06-20 at 03:04 +0200, Patrick McHardy wrote:
>
>>What about qdiscs like SFQ (which uses the packet size in quantum
>>calculations)? I guess it would make sense to use the wire-length
>>there as well.
>
>
jamal wrote:
> On Tue, 2006-20-06 at 17:09 +0200, Patrick McHardy wrote:
>
>>The thing I'm not sure about is whether this wouldn't be handled better
>>by userspace,
>
>
> If you do it in user space you will need a daemon of some form; this is
> my preference but it seems a lot of people hate da
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.
On Tue, 2006-20-06 at 17:09 +0200, Patrick McHardy wrote:
> jamal wrote:
> "Depend on bandwidth" is not the right term. All of TBF, HTB and HFSC
> provide bandwidth per time, but with TBF and HTB the relation between
> the amount of bandwidth is linear to the amount of time, with HFSC
> it is only
Dnia środa, 21 czerwca 2006 14:54, Patrick McHardy napisał:
> > I'd love to see this one implemented. I'm using HFSC more than a year and
> > it never provides proper QoS on ATM/ADSL links; low delays can never be
> > achieved even with significant throttling below the h/w link bandwidth.
>
> Mhh .
Krzysztof Matusik wrote:
> Dnia wtorek, 20 czerwca 2006 17:16, Patrick McHardy napisał:
>
>>The code wouldn't be very complicated, it just adds some overhead. If
>>you do something like I described in my previous mail the overhead for
>>people not using it would be an additional pointer test befor
Dnia wtorek, 20 czerwca 2006 17:16, Patrick McHardy napisał:
> jamal wrote:
> > On Tue, 2006-20-06 at 03:04 +0200, Patrick McHardy wrote:
> >>It would be nice to have support for HFSC as well, which unfortunately
> >>needs to be done in the kernel since it doesn't use rate tables.
> >>What about qd
jamal wrote:
> On Tue, 2006-20-06 at 03:04 +0200, Patrick McHardy wrote:
>
>>It would be nice to have support for HFSC as well, which unfortunately
>>needs to be done in the kernel since it doesn't use rate tables.
>>What about qdiscs like SFQ (which uses the packet size in quantum
>>calculations)
jamal wrote:
> On Tue, 2006-20-06 at 02:54 +0200, Patrick McHardy wrote:
>
>>jamal wrote:
>>
>>>- For further reflection: Have you considered the case where the rate
>>>table has already been considered on some link speed in user space and
>>>then somewhere post-config the physical link speed chan
On Tue, 2006-20-06 at 03:04 +0200, Patrick McHardy wrote:
> jamal wrote:
> > You are still speaking ATM (and the above may still be valid), but:
> > Could you for example look at the netdevice->type and from that figure
> > out the link layer overhead and compensate for it.
> > Obviously a lot mor
On Tue, 2006-20-06 at 02:54 +0200, Patrick McHardy wrote:
> jamal wrote:
> > - For further reflection: Have you considered the case where the rate
> > table has already been considered on some link speed in user space and
> > then somewhere post-config the physical link speed changes? This would
>
On Mon, 2006-06-19 at 22:35 -0700, Chris Wedgwood wrote:
> On Wed, Jun 14, 2006 at 11:40:04AM +0200, Jesper Dangaard Brouer wrote:
>
> > The Linux traffic's control engine inaccurately calculates
> > transmission times for packets sent over ADSL links. For some
> > packet sizes the error rises t
On Wed, Jun 14, 2006 at 11:40:04AM +0200, Jesper Dangaard Brouer 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 t
jamal wrote:
> You are still speaking ATM (and the above may still be valid), but:
> Could you for example look at the netdevice->type and from that figure
> out the link layer overhead and compensate for it.
> Obviously a lot more useful if such activity is doable in user space
> without any know
jamal wrote:
> - For further reflection: Have you considered the case where the rate
> table has already been considered on some link speed in user space and
> then somewhere post-config the physical link speed changes? This would
> happen in the case where ethernet AN is involved and the partner m
On Wed, 2006-14-06 at 14:55 +0200, Jesper Dangaard Brouer wrote:
> On Wed, 2006-06-14 at 08:06 -0400, jamal wrote:
> > - Have you tried to do a long-lived session such as a large FTP and
> > seen how far off the deviation was? That would provide some interesting
> > data point.
>
> The deviation
On Wed, 2006-14-06 at 14:55 +0200, Jesper Dangaard Brouer wrote:
> On Wed, 2006-06-14 at 08:06 -0400, jamal wrote:
> > - Have you tried to do a long-lived session such as a large FTP and
> > seen how far off the deviation was? That would provide some interesting
> > data point.
>
> The deviation
jamal wrote:
I have taken linux-kernel off the list.
Russell's site is inaccessible to me (I actually think this is related
to some DNS issues i may be having) and your masters is too long to
spend 2 minutes and glean it; so heres a question or two for you:
- Have you tried to do a long-lived s
On Wed, 2006-06-14 at 10:27 -0400, Phillip Susi wrote:
> Jesper Dangaard Brouer 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 A
Jesper Dangaard Brouer 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 ATM
transmits packets in fixed size
On Wed, 2006-06-14 at 08:06 -0400, jamal wrote:
> Russell's site is inaccessible to me (I actually think this is related
> to some DNS issues i may be having)
Strange, I have access to Russell's site. Maybe its his redirect
feature that confuses your browser, try:
http://ace-host.stuart.id.au
I have taken linux-kernel off the list.
Russell's site is inaccessible to me (I actually think this is related
to some DNS issues i may be having) and your masters is too long to
spend 2 minutes and glean it; so heres a question or two for you:
- Have you tried to do a long-lived session such as
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.
The following
56 matches
Mail list logo
