All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	netdev <netdev@vger.kernel.org>,
	netem@lists.linux-foundation.org
Subject: Re: [PATCH iproute2] tc/netem: loss gemodel options fixes
Date: Tue, 05 Aug 2014 11:29:16 -0700	[thread overview]
Message-ID: <5354.1407263356@localhost.localdomain> (raw)
In-Reply-To: <CAPh34meHr_7z4nznKBeKV6Y4Dypni72yM7bSOdkQ6hopsnjzGg@mail.gmail.com>

Hagen Paul Pfeifer <hagen@jauu.net> wrote:

>On 4 August 2014 21:37, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
>> I went ahead and applied these. They make sense and got no response.
>
>Wait Stephen,
>
>Jay do you compared your changes with the expected results? I mean did
>you run tests that the Markov chain model is _now_  working correctly
>(in all states)?
>
>The setup will be easy: send 10000 packets, capture the packets and
>'wc -l tcpdump -r trace.pcap' and compare to the expected number of
>packets for a given markov state setup. Enough bugs here where the
>should be no bugs at all. Some simple tests should be enough to get
>rid of them.

	I did test the changes when I originally submitted them, yes.
The kernel code is unmodified; what the patch changed is

	- the default for 1-k if not supplied as an option is documented
as 1-k=0, but was actually set to 1, i.e., drop everything in good state
if 1-k is not explicitly specified.

	- convert "1-h" to "h" as the kernel expects.  As I recall, I
originally noticed this when trying to specify small loss percentages in
the bad state, e.g., something like "netem loss gemodel 100 0 1" should
drop 1% in the bad state (1-h == 1%), but would instead drop 99%.

	I also posted some additional analysis:

From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
cc: netdev@vger.kernel.org, netem@lists.linux-foundation.org,
    Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH iproute2] tc/netem: loss gemodel options fixes
Date: Thu, 15 May 2014 12:46:39 -0700

Hagen Paul Pfeifer <hagen@jauu.net> wrote:

>Stephen, tomorrow I will take a look at Jay's patches.

	Just to make it clear what I believe is incorrect with regards
to the h and 1-h part:

net/sched/sch_netem.c:
[...]
                /* 4-states and Gilbert-Elliot models */
                u32 a1; /* p13 for 4-states or p for GE */
                u32 a2; /* p31 for 4-states or r for GE */
                u32 a3; /* p32 for 4-states or h for GE */
                u32 a4; /* p14 for 4-states or 1-k for GE */
[...]

	Note that a3 is "h for GE" vs a4 is "1-k for GE". Also, in
the actual drop function:

static bool loss_gilb_ell(struct netem_sched_data *q)
[...]
        case GOOD_STATE:
[...]
                if (prandom_u32() < clg->a4)
                        return true;
                break;
        case BAD_STATE:
[...]
                if (prandom_u32() > clg->a3)
                        return true;
[...]

	The test for clg->a3 is inverted as compared to the test for
clg->a4.  Hence, the kernel is using "h," not "1-h," and therefore tc
should pass in the value for h instead of 1-h as it does currently.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

  reply	other threads:[~2014-08-05 18:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-10 20:34 [PATCH iproute2] tc/netem: loss gemodel options fixes Jay Vosburgh
     [not found] ` <CAPh34mf4ahPyTDf-tEhsNKSFBL6GYjES9+TTvDjhMf2YLTr04Q@mail.gmail.com>
2014-05-15 19:46   ` Jay Vosburgh
2014-08-04 19:37     ` Stephen Hemminger
2014-08-05  8:09       ` Hagen Paul Pfeifer
2014-08-05 18:29         ` Jay Vosburgh [this message]
2014-08-05 21:25           ` Hagen Paul Pfeifer
2014-05-15 21:03 ` Stephen Hemminger

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=5354.1407263356@localhost.localdomain \
    --to=jay.vosburgh@canonical.com \
    --cc=hagen@jauu.net \
    --cc=netdev@vger.kernel.org \
    --cc=netem@lists.linux-foundation.org \
    --cc=stephen@networkplumber.org \
    /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.