From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Steve deRosier <derosier@gmail.com>,
sdnlabs Janakaraj <wsuprabhu@gmail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: testing tool for packet delay
Date: Tue, 20 Feb 2018 12:13:31 +0100 [thread overview]
Message-ID: <87tvubdick.fsf@toke.dk> (raw)
In-Reply-To: <CALLGbR+taP7GU4ftX5wFPvxD0BUsCiBDxjGXWeOJi9_nYLhEww@mail.gmail.com>
Steve deRosier <derosier@gmail.com> writes:
> On Mon, Feb 19, 2018 at 9:19 AM, sdnlabs Janakaraj <wsuprabhu@gmail.com> wrote:
>>
>> Hello All,
>>
>> I am working on delay analysis of packets in wireless stacks. I am
>> able to see lots of papers talk about therotical analysis. But I am
>> more interested in practical evaluation.
>>
>> I am reaching out to developers community to learn how they actually
>> evaluate the performance of the stack. In particular, I am looking for
>> ideas to evaluate the delay experienced by packets within the
>> mac802.11 stack.
>>
>
> Hi Prabhu,
>
> Sounds like an interesting project. More often my instrumentation
> focuses on aggregate performance and iperf throughput numbers suffices
> for most of that. Occasionally I utilize internal performance measures
> and/or data provided me by ftrace and related tools.
>
> If you're unfamiliar with it, I suggest you look at the Bufferbloat
> and Make-wifi-fast projects. I suspect that their data and techniques
> and tools might be of interest to you:
>
> https://www.bufferbloat.net/projects/make-wifi-fast/
Bufferbloat/make-wifi-fast community member checking in ;)
Basically, what we've been doing to analyse (and reduce) the latency of
the queueing system in the WiFi stack, is to put it under load and
measure how it behaves. This is not so much through the use of tracing
tools as it is an end-to-end black-box measurement approach.
The go-to mechanism for this is to run a latency measurement (either a
simple ICMP ping, or a UDP measurement flow using a tool such as
irtt[1]), then load the connection with one or more TCP flows and see
how it impacts latency. You can of course vary the number of flows,
diffserv markings, etc. to get different insights.
I'm the author of a test tool that automates a lot of this and which can
also collect a lot of statistics from the stack while doing so. The tool
is called Flent[2] and is open source. Feel free to try it out and ask
any questions that come up :)
-Toke
[1] https://github.com/peteheist/irtt/
[2] https://flent.org
next prev parent reply other threads:[~2018-02-20 11:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-19 17:19 testing tool for packet delay sdnlabs Janakaraj
2018-02-19 17:47 ` Steve deRosier
2018-02-20 11:13 ` Toke Høiland-Jørgensen [this message]
2018-02-20 22:06 ` sdnlabs Janakaraj
2018-02-20 22:53 ` Toke Høiland-Jørgensen
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=87tvubdick.fsf@toke.dk \
--to=toke@toke.dk \
--cc=derosier@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=wsuprabhu@gmail.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).