iperf is a hot rod test. The UDP versions ignores congestion signals
entirely, and thus is completely irrelevant to bufferbloat.
Well I wasn't going to run it at full speed (whatever that might mean),
but limit it to a relatively low speed, to get the jitter measurements
for UDP in the hope
Some points worth making:
1) It is important to point out that (and how) fq_codel avoids starvation:
unpleasant as elephant flows are, it would be very unfriendly to never
service them at all until they time out.
2) fairness is not necessarily what we ultimately want at all; you'd
really like to
On Tue, 27 Nov 2012, Jim Gettys wrote:
2) fairness is not necessarily what we ultimately want at all; you'd
really like to penalize those who induce congestion the most. But we don't
currently have a solution (though Bob Briscoe at BT thinks he does, and is
seeing if he can get it out from
Thank you for the review and comments, Jim! I will apply them when
I get the pen back from Dave. And yes, that is the thing about
fairness -- there are a great many definitions, many of the most
useful of which appear to many to be patently unfair. ;-)
As you suggest, it might well be best to
On Tue, Nov 27, 2012 at 02:31:53PM -0800, David Lang wrote:
On Tue, 27 Nov 2012, Jim Gettys wrote:
2) fairness is not necessarily what we ultimately want at all; you'd
really like to penalize those who induce congestion the most. But we don't
currently have a solution (though Bob Briscoe at
On 28/11/2012, at 11:54 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Tue, Nov 27, 2012 at 02:31:53PM -0800, David Lang wrote:
On Tue, 27 Nov 2012, Jim Gettys wrote:
2) fairness is not necessarily what we ultimately want at all; you'd
really like to penalize those who induce
BTW, I've heard some use the term stochastic flow queueing as a
replacement to avoid the term fair. Seems like a more apt term anyway.
-Greg
On 11/27/12 3:49 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Thank you for the review and comments, Jim! I will apply them when
I get the
On Tue, Nov 27, 2012 at 04:53:34PM -0700, Greg White wrote:
BTW, I've heard some use the term stochastic flow queueing as a
replacement to avoid the term fair. Seems like a more apt term anyway.
Would that mean that FQ-CoDel is Flow Queue Controlled Delay? ;-)
Oliver Hohlfeld
oli...@net.t-labs.tu-berlin.de writes:
The jitter measurements you have in mind will give you an idea on the
jitter specific to the chosen traffic scenario, nothing more --- and
in particular not the VoIP quality (although low vs. high jitter could
/indicate/ certain
Jim Gettys j...@freedesktop.org wrote:
at an ISP, you must to be fair between customers; it is best to leave
the judgement of fairness at finer granularity (e.g. host and TCP flows)
to the points closer to the customer's systems, so that they can enforce
whatever definition of fair they need
On Wed, Nov 28, 2012 at 12:15:35PM +1300, Andrew McGregor wrote:
On 28/11/2012, at 11:54 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Tue, Nov 27, 2012 at 02:31:53PM -0800, David Lang wrote:
On Tue, 27 Nov 2012, Jim Gettys wrote:
2) fairness is not necessarily what we
It would be me that tries to say stochastic flow queuing with CoDel
as I like to be accurate. But I think FQ-Codel is Flow queuing with CoDel.
JimG suggests smart flow queuing because he is ever mindful of the
big audience.
On 11/27/12 4:27 PM, Paul E. McKenney wrote:
On Tue, Nov 27, 2012 at
I guess I just have to be grateful that people mostly agree on the acronym,
regardless of the expansion.
Thanx, Paul
On Tue, Nov 27, 2012 at 07:43:56PM -0800, Kathleen Nichols wrote:
It would be me that tries to say stochastic flow
13 matches
Mail list logo
