> On Nov 22, 2017, at 8:49 AM, Toke Høiland-Jørgensen
> <notificati...@github.com> wrote:
>
> Pete Heist <notificati...@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:
https://github.com/tohojo/flent/issues/106#issuecomment-346321260
_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org
