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
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 remove
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 of
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
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 changes? This
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)? I guess
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
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 knowledge
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
15 matches
Mail list logo
