[Flent-users] [tohojo/flent] packet loss stats (#106)

Pete Heist notifications at github.com
Thu Nov 16 21:46:18 EET 2017

> On Nov 16, 2017, at 6:18 PM, Dave Täht <notifications at github.com> wrote:
> Pete Heist <notifications at github.com> writes:
> > Measurement-wise, I see similar results with netperf vs irtt in my Gbit LAN with
> > BQL and 'cake besteffort lan' test, with irtt having a slightly higher mean and
> > maximums, as might be expected. This is something I might be able to improve.
> > I'll try playing with chrt when I have time.
> >
> > On the positive side(?), with irtt, I don't see the 'latency locking' effect
> > that I see with netperf, where for whatever reason, certain flows would stay
> > more fixed in some position relative to the mean. Also, in these runs, the
> > download throughput was somewhat less with netperf, but not with irtt.
> My guess is you are seeing the difference between scheduling netperf and
> irtt in the cpus, and their effect on cache behavior, with the irtt
> version having a larger footprint and skewing the runs of netperf a tiny
> bit.

To be clear, it was the netperf UDP_RR version that showed the slightly lower download throughput. When irtt was running, it did not seem to affect total TCP throughput in either direction. In any case, after doing more runs, I see things can really differ from run to run with either tool in use, so I don’t want to read into this too much.

After more runs, I do see the general trend that the mean of netperf’s UDP_RR RTTs tend to be slightly less, and irtt tends to not affect the TCP flows as much. I’m going to have to do a _lot_ of runs and save all the results to say anything more statistically significant.

I did not find that "sudo chrt -r 99 ./irtt server” or locking goroutines to threads with “irtt server -thread” or a combination of the two had any immediately measurable impact.

We know that when Go makes a system call, it has a higher overhead than the equivalent call from native code due to its scheduler. We trade this off for other things. I think I’ll get in touch with the runtime team to see what if any optimizations can be made there, since they’re gathering input for what’s important to people in Go 2...

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flent.org/pipermail/flent-users_flent.org/attachments/20171116/312633ee/attachment-0002.html>

More information about the Flent-users mailing list