Pete Heist <notifications@github.com> writes:

> Thanks! I made most of your changes (-o was particularly broken, so
> this is a better solution), except:

Cool!

> - 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.

Hmm, I see your point about explicit being better, but again it's
surprising. A compromise could be to detect it and warn the user
explicitly (i.e., instead of just printing out the whole help message
you could go "you specified a unitless duration. did you mean Xs?").

> - 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?)

This is a trade-off between not accidentally dropping data and not
having to clean up after a tool that you clearly just interrupted. I
would definitely say don't output the JSON to STDOUT when interrupted
(but the stats are fine). Writing to file, hmm, I dunno...

> 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.

Right, I see your point. But yeah, I think having it be an alternative
to ping for interactive use is a valid use case, and for that mirroring
what people are used to is probably better. Besides, if someone wants to
measure things more accurately, they are probably going to be fiddling
with the options anyways...

> 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 haven't tried out the iperf code yet, but from the discussion on the
list yours has several features that iperf is lacking, most notably the
handshake (but also way more detailed statistics). So I definitely don't
think your efforts are wasted :)

-Toke


-- 
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-336931544