Pete Heist <[email protected]> writes:
> Thanks! I made most of your changes (-o was particularly broken, so this is a
> better solution), except:
>
> * I'm still thinking about whether to default durations to seconds or not. I'm
> using Go's default duration flag parsing, and I like the explicitness of
> seeing the units.
I also like explicitness, and rejecting the arg without it is ok by me.
> * I like that the JSON is written even after ctrl-C, so that interrupting a
> long
> test doesn't mean you lose all your results. But maybe if you're sending
> output to stdout, it's not a good idea (or even breaks some convention?)
>
> I changed it to ping-like behavior (although there is now -q for no per-packet
> results and -qq for no output at all). But just to explain the thought
> process,
> I felt that the default of five round trips in one second, which produces a
> reasonable approximation of all relevant stats in a short period of time, was
> better than waiting in anticipation for the next one second ping. In one
> second
> you could already be reviewing stats. :) Also, since I think IRTT will be
> typically used for lower intervals than ping, not defaulting to per-packet
> output made sense to me. I don't need to do things just because of tradition.
> However, I took your advice because we're all so accustomed to ping for so
> many
> years now, that what I like as a default might be uncomfortable or annoying to
> others, and I don't wish for people to get that feeling.
>
> If you do get some time, I'll try to turn around any changes ASAP even while
> my
> visitor is here. I'm looking forward to using Flent with IRTT to redo my
> second
> round of point-to-point WiFi tests. Open Mesh has also just released their
> first
> public beta with airtime fairness, so I'd like to give that a try.
Groovy.
> Also, If there's a reason I should do my tests with iperf2 instead, I'm all
> ears, as I'm a "scientist," not attached to my own work. :) I read that
> they're
Cross checking is always good.
> setting the thread priority to realtime, which likely reduces scheduling
> delays,
> but there's probably a cost to that. I experimented with Go's
So long as you can complete your work within a bound, realtime
scheduling is a win. I also tended to like timer_fds as those let you
know easily when you'd overrun a bound.
> runtime.LockOSThread() (it's there as the -thread option for both client and
> server) but since during one round of testing I saw 10ms outliers with that
> enabled, it's not the default. It does seem to reduce mean RTT somewhat
> though.
The *very* first thing I learned about GO was how to turn the garbage
collector off. I'm weird that way. I'd still suggest turning the garbage
collector off until after the end of a run.
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/106#issuecomment-337025131
_______________________________________________
Flent-users mailing list
[email protected]
http://flent.org/mailman/listinfo/flent-users_flent.org
