[Flent-users] [tohojo/flent] packet loss stats (#106)
notifications at github.com
Wed Nov 22 13:18:28 EET 2017
> On Nov 22, 2017, at 8:49 AM, Toke Høiland-Jørgensen <notifications at github.com> wrote:
> Pete Heist <notifications at github.com> writes:
> >> > And this likely takes the mean value of all transactions and
> >> > summarizes it at the end of the interval, then the calculated latency
> >> > was what was plotted in flent?
> >> Yup, that's exactly it :)
> > Ok, it’ll be interesting for me to look at the differences between the
> > two going forward. Naturally doing it the udp_rr way would probably
> > result in a smoother line. The other impacts on the test might be fun
> > to explore.
> Well the obvious one is that the netperf measurement uses more bandwidth
> as the latency decreases. Have been meaning to add that to the Flent
> bandwidth graphs, but now I'm not sure I'll even bother :P
True that, it ends up in a pretty tight loop with straight cabled GigE, as in my test bed...
> Also, the netperf measurement will stop at the first packet loss (later
> versions added in a timeout parameter that will restart it, but even
> with that we often see UDP latency graphs completely stopping after a
> few seconds of the RRUL test).
Yes, was noticing that before (one of our original motivations).
I know it’s a random connection, but I wonder how this would affect the throughput asymmetry I was seeing on the MBPs, for example. Would the driver/card grab airtime more aggressively when it’s transmitting many small packets, or do those get grouped together anyway? I can test it again when I get a chance, but I’m out of my league on the theory side here.
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Flent-users