> On Nov 16, 2017, at 6:18 PM, Dave Täht <notificati...@github.com> wrote:
>
> Pete Heist <notificati...@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:
https://github.com/tohojo/flent/issues/106#issuecomment-345040965
_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org
