Hello Toke, Thanks for sharing this information. I took a look at Flent yesterday and planning to test it by the weekend due to something things I have to catch up with. On Tue, Feb 20, 2018 at 6:13 AM, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > Steve deRosier <derosier@xxxxxxxxx> writes: > >> On Mon, Feb 19, 2018 at 9:19 AM, sdnlabs Janakaraj <wsuprabhu@xxxxxxxxx> 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