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

Toke Høiland-Jørgensen notifications at github.com
Fri Nov 17 16:58:02 EET 2017

Pete Heist <notifications at github.com> writes:

> The `-n` and `-timeouts` parameters have been added to the client, and are documented in the usage. Quick examples:
> ```
> tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n
> [Connecting] connecting to
> Error: no reply from server
> tron:~/src/github.com/peteheist/irtt:% echo $?
> 1
> tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n
> [Connecting] connecting to
> [Connected] connected to
> [NoTest] skipping test at user request
> tron:~/src/github.com/peteheist/irtt:% echo $?                                               
> 0
> ```


> I don't know how aggressive you want to go on open packet timeouts,
> but I set a minimum at 200ms so users won't be as tempted to abuse
> public servers. Default Linux TCP syn timeout looks to be hardcoded at
> 3s,6s,12s, etc. I think our default of 1s,2s,4s,8s is fine in this day
> and age. In flent, I think 250ms,500ms,1s,2s would be one way of being
> pretty sure whether a server is running or not in a reasonable amount
> of time (3.75s), but I don't know what actual the time constraints
> are.

I don't want to spend more than one second probing, so 250ms,500ms will
have to do.

> I took a quick look at the irtt runner in flent. Looks good, my only
> comment is that `-fill rand` and `-fillall` aren't necessary because
> there's no payload (whose length would be specified with `-l`). Seeing
> that though made me add a micro-optimization to not call Read with an
> empty slice on the Filler when there's no payload requested. So if you
> want to leave those params in anticipation of using `-l` later, it's
> probably fine.

Yeah, was mirroring what I'm doing with netperf. Haven't thought about
adding knobs yet, but setting the lengths seems useful.

> That makes me think, any reason we can't use irtt for the voip tests?
> There could be tests simulating some different codecs with different
> intervals and payload lengths, if we wanted:

That would be awesome! D-ITG is awful to setup, so having a replacement
for that would be good :)


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/20171117/65b863a5/attachment-0002.html>

More information about the Flent-users mailing list