From: Julio Kriger <juliokriger@gmail.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: "David S. Miller" <davem@davemloft.net>,
netdev@oss.sgi.com, netem@osdl.org
Subject: Re: [PATCH] netem: fix logic bug in reorder conditional
Date: Tue, 24 May 2005 14:27:44 -0300 [thread overview]
Message-ID: <682bc30a05052410277a9652a1@mail.gmail.com> (raw)
In-Reply-To: <20050524095707.678f77ba@dxpl.pdx.osdl.net>
On 5/24/05, Stephen Hemminger <shemminger@osdl.org> wrote:
> On Tue, 24 May 2005 12:41:11 -0300
> Julio Kriger <juliokriger@gmail.com> wrote:
>
> > > > 2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me
> > > > a negative number. This value is addes to cb->time_to_send, so it
> > > > could change it to a negative value. Should we only accept positives
> > > > number before add it to cb->time_to_send? or will
> > > > q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a
> > > > special way so it will be handled "before" other packages alrealy on
> > > > the queue but with gretaer time_to_send?
> > >
> > > probably should bound the value to 0 before the addition, to avoid large
> > > wraparound problems, but since enqueue checks for for time it will work
> > > as long as delta less than 2^32/2.
> > >
> >
> > I think the value should be restricted to be positive and greater than
> > zero. Becuase if a negative number is allowed we will be "losing"
> > packages to be reordered, hence we will not be reordering, say 25%, of
> > packages instead we will be reordering about 15%.
> > In other words, packages that should be reordered will not be
> > reordered because its new time to send will be the same as the old
> > time to send.
> > Regards,
> > Julio
>
> The problem is that the user specification (latency 50ms +/- 300ms with reordering)
> is problematic. Just like specifying reordering without delay (and a fast connection).
I agree with you. Maybe changing the actual parameters to a "range"
could be a better solution. Say "I want delay a package between 50 and
300 ms with correlation of 50% and normal distribution". The code
should not change too much, I think.
Regards,
Julio
--
----------------------------
Julio Kriger
mailto:juliokriger@gmail.com
next prev parent reply other threads:[~2005-05-24 17:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-19 22:12 [PATCH] (3/3) netem: allow random reordering Stephen Hemminger
2005-05-20 20:28 ` [Netem] " Julio Kriger
2005-05-23 17:25 ` Stephen Hemminger
2005-05-21 15:05 ` Julio Kriger
2005-05-21 23:00 ` Julio Kriger
2005-05-23 17:43 ` [PATCH] netem: fix logic bug in reorder conditional Stephen Hemminger
2005-05-23 20:55 ` Julio Kriger
2005-05-23 21:00 ` Stephen Hemminger
2005-05-24 15:41 ` Julio Kriger
2005-05-24 16:57 ` Stephen Hemminger
2005-05-24 17:27 ` Julio Kriger [this message]
2005-05-24 22:26 ` [PATCH] (3/3) netem: allow random reordering (with fix) Stephen Hemminger
2005-05-25 22:08 ` David S. 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=682bc30a05052410277a9652a1@mail.gmail.com \
--to=juliokriger@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@oss.sgi.com \
--cc=netem@osdl.org \
--cc=shemminger@osdl.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 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).