All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: netdev <netdev@vger.kernel.org>,
	Yuchung Cheng <ycheng@google.com>,
	Andreas Terzis <aterzis@google.com>, Mark Gordon <msg@google.com>
Subject: Re: [PATCH] netem: fix rate extension and drop accounting
Date: Wed, 04 Jul 2012 19:23:21 +0200	[thread overview]
Message-ID: <1341422601.2583.2393.camel@edumazet-glaptop> (raw)
In-Reply-To: <20120704165132.GA3455@nuttenaction>

On Wed, 2012-07-04 at 18:51 +0200, Hagen Paul Pfeifer wrote:
> OK, I will work on it tomorrow! But Eric, keep in mind that this accumulative
> behavior is intended: think about a hypothetical satellite link with a
> bandwidth (rate) of 1000 byte/s. If you send three 1000 byte consecutively
> packets. The first packet is delayed for 1 second, the second then is
> transmitted after 2 seconds, the third after three seconds and so on. So
> _this_ accumulative behavior is correct. Anyway, I will look at this tomorrow!
> 

I fear you did your tests with no delay on netem.

Try to setup a rate of 100kbit and a delay of 100ms and to really get
full bandwith (100kbit), I am afraid it doesnt work.

Your algo is OK only if no packets are in queue (obviously)

But if you have 2 or 3 packets, the delay are cumulative,
but the delay should be a fixed bias for each packet.


> Thanks Eric!
> 
> PS: one last question: what do you want to test? TBF and netem rate at the
> same time looks, mmhh, special ... ;-) I ask myself what link exhibit this
> characteristic?

TBF as a netem child was the usual way to have delay + rate before your
patch ?

Not sure why you find it special ?

  reply	other threads:[~2012-07-04 17:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03  9:25 [PATCH] netem: fix rate extension and drop accounting Eric Dumazet
2012-07-03  9:54 ` Eric Dumazet
2012-07-03 22:04   ` Hagen Paul Pfeifer
2012-07-04  5:58     ` Eric Dumazet
2012-07-04 16:51       ` Hagen Paul Pfeifer
2012-07-04 17:23         ` Eric Dumazet [this message]
2012-07-04 17:30           ` Hagen Paul Pfeifer
     [not found] ` <CAPVr9VP7DniPZj4vZi_myJWfL5JLYKYTXXtrXcKHo9LjEQzjYw@mail.gmail.com>
2012-07-16 23:26   ` Hagen Paul Pfeifer
2012-07-17  5:12     ` Eric Dumazet
     [not found]       ` <CAPVr9VMCYFO-7uEzO6ft2vpPhVvRgHB3EWJJG62OqGqux1LsZQ@mail.gmail.com>
2012-07-17 17:39         ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1341422601.2583.2393.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=aterzis@google.com \
    --cc=hagen@jauu.net \
    --cc=msg@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=ycheng@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.