From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
David Miller <davem@davemloft.net>,
Dave Taht <dave.taht@gmail.com>,
"John A. Sullivan III" <jsullivan@opensourcedevel.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next] netem: fix classful handling
Date: Thu, 29 Dec 2011 17:52:49 +0100 [thread overview]
Message-ID: <20111229165249.GB2948@hell> (raw)
In-Reply-To: <1325149922.2607.33.camel@edumazet-laptop>
* Eric Dumazet | 2011-12-29 10:12:02 [+0100]:
>> Also, the whole tfifo idea is only to support the wierd idea that
>> if doing random delay that packets should get reordered based on the
>> results of the random value; it was an behavior some users wanted
>> because that is what NISTnet did.
>
>tfifo supports a time ordered queuing, wich mimics some jitter in the
>network. This seems quite useful.
>
>I see what you suggest : adding 'time_to_send' in the generic qdisc cb.
>
>But it makes no sense if we attach a reordering qdisc, like SFQ :
>A 'high prio' packet will block the whole netem because we'll have to
>throttle since this packet time_to_send will be in the future, while
>many other elligible packets are in queue.
In other words netem jitter and a qdisc !tfifo will not work. Correct? The
rate extension also peak the last packet to get the reference time (assuming a
strict ordering):
[...]
now = netem_skb_cb(skb_peek_tail(list))->time_to_send;
[...]
We should avoid a different (unseeable) behavior depending on the queue
(tfifo, SFQ). Another point: operate netem and qdisc on the same computer can
lead to timing abnormalities. In our test setups we operate qdisc/tcp/whatever
setups and netem on more then on computer.
Hagen
next prev parent reply other threads:[~2011-12-29 16:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-18 5:12 netem and hierarchical ingress traffic shaping John A. Sullivan III
2011-12-18 19:55 ` Stephen Hemminger
2011-12-19 16:53 ` John A. Sullivan III
2011-12-23 17:33 ` Eric Dumazet
2011-12-23 17:39 ` Eric Dumazet
2011-12-23 17:54 ` Dave Taht
2011-12-23 18:28 ` Eric Dumazet
2011-12-23 18:54 ` Dave Taht
2011-12-23 19:07 ` Stephen Hemminger
2011-12-23 19:21 ` Eric Dumazet
2011-12-29 4:26 ` [PATCH net-next] netem: fix classful handling Eric Dumazet
2011-12-29 6:17 ` Stephen Hemminger
2011-12-29 9:12 ` Eric Dumazet
2011-12-29 16:52 ` Hagen Paul Pfeifer [this message]
2011-12-29 17:15 ` Eric Dumazet
2011-12-29 17:43 ` Hagen Paul Pfeifer
2011-12-29 18:10 ` Eric Dumazet
2011-12-29 18:25 ` Hagen Paul Pfeifer
2011-12-29 18:31 ` Stephen Hemminger
2011-12-29 18:36 ` Eric Dumazet
2011-12-30 22:12 ` David Miller
2011-12-23 19:36 ` netem and hierarchical ingress traffic shaping David Miller
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=20111229165249.GB2948@hell \
--to=hagen@jauu.net \
--cc=dave.taht@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jsullivan@opensourcedevel.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).