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

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2111 bytes --]

Pete Heist <notifications@github.com> writes:

> An update:
>
> - JSON is working, sample attached in case there are comments /
> wishes.

Lots of data; don't think I'll parse all of it in Flent. My thought
would be to save:

For each data point: RTT, OWD (in both directions), IPDV.
For the whole test:
- Min/max/mean/median RTT values.
- Packet size and/or bit rate
- Most of the params object, probably

A few comments about the data format:

- I'm guessing all values are nanoseconds? Are the absolute times in
  UTC?

- The data points are missing sequence numbers; makes it hard to infer
  loss, and to relate IPDV to RTT values.
  
- Why are the IPDV values in a separate array?

- Some of the 'params' are not terribly useful:
  - What are the local and remote addresses of? Is this where the server
    listens? I'm guessing the client doesn't connect to 0.0.0.0 at
    least... Would be better to know the values that were actually used.

  - Similarly, it would be more useful to know whether packets were actually sent
    as IPv4 or IPv6, rather than what was selected.

- Which fields are guaranteed to be present and which can be blank?

- What is the send and receive rates? Are they always the same? And in
  which direction? Do they include packet loss?

- I sort of get why there are so many time stamps in the beginning, but
  I think 'first_send_time/first_sent_time' is bound to be confusing at
  some point; is it really necessary to include both? I'm assuming those
  are timestamps on each side of the send() call?

> - Median (where possible) and stddev are working.

Cool.

> - pflag adds 160K to executable, passing for now.

Yeah, the binary size of Go apps is a PITA. Is this stripped size? Flent
can obviously work with both styles of flags, I just personally thing
the Go defaults are annoying; just be aware that once you release,
changing is going to break backwards compatibility.

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

[-- Attachment #1.2: Type: text/html, Size: 5994 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 4634 bytes --]

Pete Heist <notifications@github.com> writes:

>> - The data points are missing sequence numbers; makes it hard to infer
>> loss, and to relate IPDV to RTT values.
>
> Yes, because the seqno is just the array index. I’ll add the seqno
> explicitly to make it easier to consume.

So what happens if a packet is lost? There'll be an empty element in the
array? That's... unusual... ;)

>> - Some of the 'params' are not terribly useful:
>> - What are the local and remote addresses of? Is this where the server
>> listens? I'm guessing the client doesn't connect to 0.0.0.0 at
>> least... Would be better to know the values that were actually used.
>
> Yes, I can get the actual local address and fix that. The remote
> address would be there but I removed it manually as I usually don’t
> post internal IPs if I remember to remove them. BTW, I may have an
> option to keep out any “internal” info, like hostnames and IPs.
>
> Come to think of it I’d rather have params be params (what was
> supplied to the API), then I can have something separate after Dial
> has occurred with resolved addresses, actual IP version, etc. Likewise
> it can be the case that the server doesn’t support the timestamp mode
> you requested, or the length of the packet, or it doesn’t support DSCP
> or DF (in the case of Windows), etc. It would be good to know both
> what you asked for and what you actually got.

Presumably the caller knows what is being asked for, so the important
thing is what will actually be used. Depends a little bit on what you
envisage the output being used for; if you plan on storing it by itself,
then the supplied parameters might be useful to include. But for Flent's
usage, the command line options are stored in the data file...

>> - Similarly, it would be more useful to know whether packets were actually sent
>> as IPv4 or IPv6, rather than what was selected.
>> - Which fields are guaranteed to be present and which can be blank?
>
> I’m omitting some that can be blank, but I see that it may be easier
> for consumption if I include everything instead of documenting what
> may or may not be there.

Well, whether they are omitted or can be blank, it'll be important to
know what to expect :)

>> - What is the send and receive rates? Are they always the same? And in
>> which direction? Do they include packet loss?
>
> They’re based on:
>
> - for send, the total UDP payload data written to the socket between
> right before the first send and right after the last send
>
> - for receive, the total UDP payload data received from the socket
> between right after the first receive and right after the last receive
> (dups not included)
>
> They may differ due to packet loss.

Right, that's what I assumed; and that seems reasonable.

> BTW, later I want to have the server return the total data received
> for a flow to distinguish between upstream and downstream packet loss
> (and maybe some bits with a window into which packets were lost).

Yup, that could be useful :)

> I do not include duplicates in received data, which raises a point. I
> consider duplicates something you shouldn’t see unless there is a
> problem or misconfiguration somewhere, so other than having a
> duplicate counter and warning about them I don’t include them in other
> stats (bytes received, bitrate, RTT/ OWD, etc). If that’s misguided,
> if seeing duplicates is an ordinary thing on the open Internet, let me
> know and I may reconsider what I do with the stats.

Meh, don't think duplication is a huge concern over the public internet.
Probably save to ignore for now...

> I was eyeballing it before, plus that was before I added the json
> package, which may or may not have dependencies in common, now it's:
>
> Unstripped increase: 153600 bytes
> Stripped increase: 108544 bytes
>
> It’s not important enough to me now for the size.
>
> Adding the JSON encoder was a relative “whopper” at around 250K
> unstripped (also eyeballed). If I’m looking for somewhere to cut, I
> could later find another encoder or just write JSON by hand. I did
> some gyrations to avoid pulling in regexp in a couple of cases. :)

Huh, that's quite impressive (and not in a good way). But then it
probably can't run on the tiniest of devices anyway since there's no
MIPS support in Go (last I looked anyway)...

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

[-- Attachment #1.2: Type: text/html, Size: 11650 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 581 bytes --]

Pete Heist <notifications@github.com> writes:

> Also, I hope the time I've invested is still useful, given the iperf2
> team's post about suddenly adding isochronous support for their
> latency test. :) Anyway, I'll finish what I've started. The handshake
> is working and it's a matter of wrapping up (a number of) details...

I'm sure it will be. Looking forward to the code dump ;)

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

[-- Attachment #1.2: Type: text/html, Size: 2626 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1739 bytes --]

Pete Heist <notifications@github.com> writes:

> Thanks again both for your kind help and feedback on this. I hope it's
> useful, and if not, it sure was fun anyway!

Very nice, and definitely useful! :)

Took it for a quick spin on localhost, some oddities from my initial
fiddling:

- On first run I expected it to work similar to ping, i.e., output data
  points as packets come in. Instead I almost immediately get a summary.
  Ah, it's running for a single second, and needs -v to output
  per-packet datapoints. For one-off command-line use it might be more
  useful to default to a more ping-like output (i.e., run until killed,
  output data points)?

- Hmm, -d 10 doesn't work. Ah, -d 10s does. Maybe default to seconds if
  no unit is given?

- Let's look at the json output. Oops, -o stdout outputs garbage to the
  terminal; ah, it's gzipped and needs -nogzip. Probably better to
  default stdout to not being gzipped? And instead of adding an
  extension, do the opposite and detect whether or not to gzip from the
  supplied file name instead? If I do '-o test.json' I get
  'test.json.json.gz' which is confusing. Also, supplying a filename of
  '-' creates '-.json.gz' instead of outputting to stdout. And the
  output file is written even if I cancel with Ctrl+C.

I consider all these minor issues, though, and overall it looks good!
I'll see if I can find some time to add support to Flent and try it out
in my testbed in various scenarios. Not sure if I'll have time this
week, though, have another deadline to attend to...

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

[-- Attachment #1.2: Type: text/html, Size: 5112 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2881 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 7720 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 708 bytes --]

Pete Heist <notifications@github.com> writes:

> I should have another block of time next week to finish the upstream
> vs downstream packet loss stats, then after that could be a good time
> for Flent integration. Need my help for it? It would probably take me
> longer to get into the Flent code and I'm not much of a Pythonista,
> but I could try if it's needed.

I can add support to Flent (I'm away next week, should have time after
that); but if you could document the JSON format that would be helpful :)


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

[-- Attachment #1.2: Type: text/html, Size: 2894 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 910 bytes --]

Pete Heist <notifications@github.com> writes:

>> I can add support to Flent (I'm away next week, should have time after
>> that); but if you could document the JSON format that would be helpful :)
>
> Cool, that should be good timing, the current output is already
> documented: https://github.com/peteheist/irtt/#json-format

Ah, that is excellent - thank you! :)

> I’ll still add more to it after the packet loss stats.

As long as you're not moving things around, that's fine.

> It would be nice if there were some standard way for documenting JSON,
> but I don’t know of anything. JSON Schema seems too verbose for
> this...

Yeah, don't go turning JSON back into XML now... ;)

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

[-- Attachment #1.2: Type: text/html, Size: 3346 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 949 bytes --]

Okay, basic Flent support for irtt implemented in 2503caba7d32f847b242eede225638bd64d88d53 - there's an rrul_be_irtt test that will substitute the netperf udp_rr test for irtt.

However, I don't really want to duplicate all tests for irtt, so I think a better way to integrate it is needed. I.e., a test should specify that it just wants a UDP RTT measurement, and Flent will pick the right tool depending on availability. Something similar might be useful for TCP (someone wanted to substitute iperf for netperf in #115).

Picking a tool depending on what is available locally is straight-forward, but checking for server-side support is trickier. Is it OK to punt on that, or should we fire off a one-shot test (something like `irtt client -d 1ms -wait 1ms <hostname>`) to check?

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

[-- Attachment #1.2: Type: text/html, Size: 3655 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2983 bytes --]

Pete Heist <notifications@github.com> writes:

> Cool, the rrul_be_irtt test is working for me. I see what you mean,
> ideally it would just be the same test but you substitute the tool you
> want to use for a particular measurement.
>
> Maybe this is what you're saying, but could it be that you specify
> what tool you want to use for each particular measurement? In other
> words, the tool for 'TCP throughput' is netperf as of now, and later
> could possibly be iperf. For 'UDP RTT' it can be netperf or irtt. For
> 'ICMP RTT' it can be ping or fping, etc.

Yeah, something like that. For ping we already do this (default to fping
and fall back to regular ping), but those are closer in functionality.
But the idea is the same; the test should not specify "use netperf" but
rather "this is a UDP RR test". Then we pick irtt if it's available and
use netperf as a fallback. Optionally with a command line switch to
force fallback (probably a good idea at least until we get wider
deployment of irtt).

> I'm waving my arms here because there can be more than one measurement
> from a single tool. So maybe it should really be 'UDP RT' because in
> the case of irtt it's doing a UDP round-trip and measuring several
> things from it at once: RTT, OWD, IPDV, etc. Since there isn't a
> one-to-one correspondence between the tool and measurement it returns,
> it's not clear to me yet how it should be specified, still thinking
> about it.
>
> I guess at some point there will be additional plots for OWD and IPDV.
> Is it a new situation for you that the plots available depend not only
> on the test but the tool used or even its settings?

Meh, irtt's functionality is basically a superset of netperf's UDP_RR.
So automatically picking irtt if available and a fallback is the right
thing to do, I think. I'd just add the plots everywhere, and if OWD data
is not available, those plots would just be empty. Same thing we do for
TCP window stats currently. Longer term, maybe hiding the plots entirely
when there is no data is better, but for now empty plots are fine.

> Personally I don't think it's necessary to check for server-side
> support. If someone is specifying they want to use a particular tool,
> I think they're declaring that it's available, as it is today with
> netperf / netserver.

Yes, but if we do automatic detection with a preference we could get
into the situation where irtt exists on the client but the test is being
run against a server that doesn't have it. This is especially likely to
happen before the *.netperf.bufferbloat.net servers have irtt deployed.

Could you be persuaded to add a 'check_server' action to irtt? Something
that just does the handshake and doesn't run any more tests other than
that. Then we could have Flent call that to verify that irtt is
usable...

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 7980 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]

Pete Heist <notifications@github.com> writes:

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

Yeah, one of the issues with the netperf UDP_RR test is that it uses
more bandwidth the lower the latency, because it really measures
"transactions per second" which Flent then converts to RTT. That is
probably also the reason for the 'locking' behaviour...

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 3106 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1042 bytes --]

Pete Heist <notifications@github.com> writes:

>> Could you be persuaded to add a 'check_server' action to irtt? Something
>> that just does the handshake and doesn't run any more tests other than
>> that. Then we could have Flent call that to verify that irtt is
>> usable...
>
> Sure, I’ll add that (or something similarly named). Should get to it
> today or tomorrow. Meanwhile you’re right that something like this
> works and check for return code 0 to mean success:

Cool!

> The handshake takes up to 15 seconds to complete (delays of 1, 2, 4
> and 8 seconds waiting for a reply), so not having irtt on the server
> will mean a 15 second wait. Do you think it’s ok to keep that fixed?

Hmm, waiting 15 seconds before starting a test is probably a bit much.
For the test, I'd say don't retransmit and make the wait configurable?

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 3666 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1015 bytes --]

Pete Heist <notifications@github.com> writes:

>> On Nov 16, 2017, at 1:48 PM, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> 
>> > The handshake takes up to 15 seconds to complete (delays of 1, 2, 4
>> > and 8 seconds waiting for a reply), so not having irtt on the server
>> > will mean a 15 second wait. Do you think it’s ok to keep that fixed?
>> 
>> Hmm, waiting 15 seconds before starting a test is probably a bit much.
>> For the test, I'd say don't retransmit and make the wait configurable?
>
> How about re-transmit but once per second with a flag for the number
> of times to try, plus I’d probably limit it to some maximum. If
> there’s no retransmit you might see fallbacks due to packet loss more
> than you’d want.

Sure, that works. Or make the interval a flag as well, maybe?

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 3680 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1427 bytes --]

Pete Heist <notifications@github.com> writes:

>> On Nov 16, 2017, at 2:07 PM, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> 
>> Pete Heist <notifications@github.com> writes:
>> 
>> >> On Nov 16, 2017, at 1:48 PM, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> >> 
>> >> > The handshake takes up to 15 seconds to complete (delays of 1, 2, 4
>> >> > and 8 seconds waiting for a reply), so not having irtt on the server
>> >> > will mean a 15 second wait. Do you think it’s ok to keep that fixed?
>> >> 
>> >> Hmm, waiting 15 seconds before starting a test is probably a bit much.
>> >> For the test, I'd say don't retransmit and make the wait configurable?
>> >
>> > How about re-transmit but once per second with a flag for the number
>> > of times to try, plus I’d probably limit it to some maximum. If
>> > there’s no retransmit you might see fallbacks due to packet loss more
>> > than you’d want.
>> 
>> Sure, that works. Or make the interval a flag as well, maybe?
>
> Yeah, I was thinking of making the handshake waits configurable
> anyway, so I’ll probably do that and I think it will be flexible
> enough for what’s needed. Will update when it’s ready…

Cool :)

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 4912 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 453 bytes --]

Right, so partially implemented the selection logic in 343f60da7be78d6fba13af02b60f37cdda9c4d24. Still a few more things needed before it can be activated, so I have not enabled it in any tests yet. One of those things is the server-side check for irtt, another is internal to Flent...

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

[-- Attachment #1.2: Type: text/html, Size: 2355 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1795 bytes --]



On 16 November 2017 17:15:36 CET, Pete Heist <notifications@github.com> wrote:
>
>> On Nov 16, 2017, at 3:47 PM, Toke Høiland-Jørgensen
><notifications@github.com> wrote:
>> Right, so partially implemented the selection logic in 343f60d
><https://github.com/tohojo/flent/commit/343f60da7be78d6fba13af02b60f37cdda9c4d24>.
>Still a few more things needed before it can be activated, so I have
>not enabled it in any tests yet. One of those things is the server-side
>check for irtt, another is internal to Flent...
>> 
>
>After my afternoon walk, I’m re-thinking how to handle the server
>check. What I propose instead of adding a separate command is:
>
>* add a -n parameter to the client command, which will skip the running
>of the test. A single packet will be sent with both the open and close
>flags set, the server will evaluate the test parameters, as usual, and
>return a response with any parameter restrictions, as usual.
>
>* add a -hwait parameter, or similar, which allows specifying the list
>of durations to wait for the handshake response, that can be specified
>with or without -n
>
>Advantages:
>
>* you can use -strictparams if you want, to make sure the parameters
>you use for the test won't be restricted by the server
>
>* the specification of other parameters relevant to connecting
>(handshake wait times, hmac key, -4, -6, etc) is all done in an
>equivalent way
>
>* when it comes to protecting the server (which still needs work), I
>don’t have to deal with a new type of packet to rate limit
>
>Is this ok?

Yup, sounds like an excellent plan! :)


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

[-- Attachment #1.2: Type: text/html, Size: 5448 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1334 bytes --]



On 16 November 2017 18:20:16 CET, "Dave Täht" <notifications@github.com> wrote:
>Toke Høiland-Jørgensen <notifications@github.com> writes:
>
>> Pete Heist <notifications@github.com> writes:
>>
>>> 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.
>>
>> Yeah, one of the issues with the netperf UDP_RR test is that it uses
>> more bandwidth the lower the latency, because it really measures
>> "transactions per second" which Flent then converts to RTT. That is
>> probably also the reason for the 'locking' behaviour...
>
>The rrul spec was for isochronous behavior. Would not mind a rrulv2
>test
>that did that using irtt.

I don't really see any reason to keep the netperf UDP_RR behaviour for anything other than a fallback. So once I'm done with the integration, RRUL would just switch to isochronous behaviour everywhere whenever irtt is available...

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 4502 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2359 bytes --]

Pete Heist <notifications@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 127.0.0.2
> [Connecting] connecting to 127.0.0.2
> 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 127.0.0.1
> [Connecting] connecting to 127.0.0.1
> [Connected] connected to 127.0.0.1:2112
> [NoTest] skipping test at user request
> tron:~/src/github.com/peteheist/irtt:% echo $?                                               
> 0
> ```

Awesome!

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

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 6700 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1496 bytes --]



On 18 November 2017 13:43:23 CET, Pete Heist <notifications@github.com> wrote:
>Maybe of interest, the per-packet upstream vs downstream loss now works
>properly, if you want to use it. Limitations documented:
>https://github.com/peteheist/irtt#64-bit-received-window
>
>But how to plot that. Maybe there could be an up arrow for `lost_up`,
>down arrow for `lost_down`, or X for the generic `lost` shown at y=0 on
>the latency plot, along with a gap in the plotted line?

Yeah, currently I'm skipping drops entirely, which is probably not the right thing to do. Same with the ping runner. Will think about how to fix that.

On a separate plot, drops could just be plotted as a "drops per interval" plot. That's what the qdisc stats plot does.

>IRTT for the voip tests would be awesome! (I hope) Just an idea,
>instead of having separate voip tests, any of the tests with UDP flows
>could become a voip test by accepting a "voip_codec" test-parameter
>that sets the interval and packet length. Common codec values:
>https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html#anc1
>
>I guess having generic parameters to explicitly set interval and packet
>length would still be useful...

Are VoIP packets always straight fixed interval? Or would you need to support various distributions?

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 4674 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 161 bytes --]

Of all the codecs out there, I like opus best. (It's deeply in webrtc).

g711, and gsm, used to be the most common, but I've been out of this field
a long time.

[-- Attachment #1.2: Type: text/html, Size: 286 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 621 bytes --]

Pete Heist <notifications@github.com> writes:

> G.711 can be simulated today with `-i 20ms -l 172 -fill rand
> -fillall`. I do this test pretty often, and I think it would be a good
> default voip test.

The problem with this is that it also changes the sampling rate. I don't
necessarily want to plot the latency every 20ms, so I'd have to
compensate for that in the Flent plotter somehow. Also, a better way to
deal with loss would be needed.

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 2714 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2367 bytes --]

Pete Heist <notifications@github.com> writes:

>> On Nov 20, 2017, at 1:11 PM, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> 
>> Pete Heist <notifications@github.com> writes:
>> 
>> > G.711 can be simulated today with `-i 20ms -l 172 -fill rand
>> > -fillall`. I do this test pretty often, and I think it would be a good
>> > default voip test.
>> 
>> The problem with this is that it also changes the sampling rate. I don't
>> necessarily want to plot the latency every 20ms, so I'd have to
>> compensate for that in the Flent plotter somehow. Also, a better way to
>> deal with loss would be needed.
>
>
> I wondered if/when this would come up… Why not plot the latency every
> 20ms, too dense?

For the current plot type (where data points are connected by lines),
certainly. It would probably be possible to plot denser data sets by a
point cloud type plot, but that would make denser data series harder to
read.

> I guess even if not, eventually at a low enough interval the round
> trip and plotting intervals would need to be decoupled, no matter what
> plot type is used.

Yeah, exactly.

> If we want to minimize flent changes, irtt could optionally produce a
> `round_trip_snapshots` (name TBD) array in the json with elements
> created at a specified interval (`-si duration` or similar) that would
> summarize the data from multiple round trips. For each snapshot, there
> would be no timestamps, but the start and end seqnos would be there
> (if needed), mean delays and ipdv, counts (or percentages?) of lost,
> lost_up or lost_down, etc. I’d need to spec this out, but would
> something like this help?

Hmm, seeing as we probably want to keep all the data points in the Flent
data file anyway, I think we might as well do the sub-sampling in Flent.
Just thinning the plots is a few lines of numpy code; just need to
figure out a good place to apply it.

Handling loss is another matter, but one that I need to deal with
anyway. Right now I'm just throwing away lost data points entirely,
which loses the lost_{up,down} information. Will fix that and also
figure out the right way to indicate losses.

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 6672 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 319 bytes --]


> Really looking forward to it!

Working on it. Turned out to need a bit of refactoring. This is me
currently: https://i.imgur.com/t0XHtgJ.gif

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 2022 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 552 bytes --]

Okay, testable code in the runner-refactor branch.

Ended up doing a fairly involved refactoring of how runners work with
data; which is good, as the new way to structure things makes a lot more
sense in general; but it did mean I had to change the data format, so
quite a few places this can break. So testing appreciated, both for
running new tests, and for plotting old data files.

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

[-- Attachment #1.2: Type: text/html, Size: 2496 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 3087 bytes --]

On Mon, Nov 20, 2017 at 5:21 AM, Toke Høiland-Jørgensen <
notifications@github.com> wrote:

> Pete Heist <notifications@github.com> writes:
>
> >> On Nov 20, 2017, at 1:11 PM, Toke Høiland-Jørgensen <
> notifications@github.com> wrote:
> >>
> >> Pete Heist <notifications@github.com> writes:
> >>
> >> > G.711 can be simulated today with `-i 20ms -l 172 -fill rand
> >> > -fillall`. I do this test pretty often, and I think it would be a good
> >> > default voip test.
> >>
> >> The problem with this is that it also changes the sampling rate. I don't
> >> necessarily want to plot the latency every 20ms, so I'd have to
> >> compensate for that in the Flent plotter somehow. Also, a better way to
> >> deal with loss would be needed.
> >
> >
> > I wondered if/when this would come up… Why not plot the latency every
> > 20ms, too dense?
>
> For the current plot type (where data points are connected by lines),
> certainly. It would probably be possible to plot denser data sets by a
> point cloud type plot, but that would make denser data series harder to
> read.


Winstein plot of latency variance? It doesn't get denser, it gets darker.

Packet loss vs throughput?


> > I guess even if not, eventually at a low enough interval the round
> > trip and plotting intervals would need to be decoupled, no matter what
> > plot type is used.
>
> Yeah, exactly.
>
> > If we want to minimize flent changes, irtt could optionally produce a
> > `round_trip_snapshots` (name TBD) array in the json with elements
> > created at a specified interval (`-si duration` or similar) that would
> > summarize the data from multiple round trips. For each snapshot, there
> > would be no timestamps, but the start and end seqnos would be there
> > (if needed), mean delays and ipdv, counts (or percentages?) of lost,
> > lost_up or lost_down, etc. I’d need to spec this out, but would
> > something like this help?
>
> Hmm, seeing as we probably want to keep all the data points in the Flent
> data file anyway, I think we might as well do the sub-sampling in Flent.
> Just thinning the plots is a few lines of numpy code; just need to
> figure out a good place to apply it.
>
> Handling loss is another matter, but one that I need to deal with
> anyway. Right now I'm just throwing away lost data points entirely,
> which loses the lost_{up,down} information. Will fix that and also
> figure out the right way to indicate losses.
>

Groovy.


> -Toke
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/tohojo/flent/issues/106#issuecomment-345693455>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AerUv9ZyQpd6Oq7HudRiOYPKKIg8Ey8Aks5s4XzMgaJpZM4MpJAm>
> .
>
> _______________________________________________
> Flent-users mailing list
> Flent-users@flent.org
> http://flent.org/mailman/listinfo/flent-users_flent.org
>
>


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

[-- Attachment #1.2: Type: text/html, Size: 4850 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 3564 bytes --]

A goal for me has been to be able to run Opus at 24 bit, 96Khz, with 2.7ms
sampling latency.
Actually getting 8 channels of that through a loaded box would be mahvelous.



On Mon, Nov 20, 2017 at 1:14 PM, Dave Taht <dave.taht@gmail.com> wrote:

>
>
> On Mon, Nov 20, 2017 at 5:21 AM, Toke Høiland-Jørgensen <
> notifications@github.com> wrote:
>
>> Pete Heist <notifications@github.com> writes:
>>
>> >> On Nov 20, 2017, at 1:11 PM, Toke Høiland-Jørgensen <
>> notifications@github.com> wrote:
>> >>
>> >> Pete Heist <notifications@github.com> writes:
>> >>
>> >> > G.711 can be simulated today with `-i 20ms -l 172 -fill rand
>> >> > -fillall`. I do this test pretty often, and I think it would be a
>> good
>> >> > default voip test.
>> >>
>> >> The problem with this is that it also changes the sampling rate. I
>> don't
>> >> necessarily want to plot the latency every 20ms, so I'd have to
>> >> compensate for that in the Flent plotter somehow. Also, a better way to
>> >> deal with loss would be needed.
>> >
>> >
>> > I wondered if/when this would come up… Why not plot the latency every
>> > 20ms, too dense?
>>
>> For the current plot type (where data points are connected by lines),
>> certainly. It would probably be possible to plot denser data sets by a
>> point cloud type plot, but that would make denser data series harder to
>> read.
>
>
> Winstein plot of latency variance? It doesn't get denser, it gets darker.
>
> Packet loss vs throughput?
>
>
>> > I guess even if not, eventually at a low enough interval the round
>> > trip and plotting intervals would need to be decoupled, no matter what
>> > plot type is used.
>>
>> Yeah, exactly.
>>
>> > If we want to minimize flent changes, irtt could optionally produce a
>> > `round_trip_snapshots` (name TBD) array in the json with elements
>> > created at a specified interval (`-si duration` or similar) that would
>> > summarize the data from multiple round trips. For each snapshot, there
>> > would be no timestamps, but the start and end seqnos would be there
>> > (if needed), mean delays and ipdv, counts (or percentages?) of lost,
>> > lost_up or lost_down, etc. I’d need to spec this out, but would
>> > something like this help?
>>
>> Hmm, seeing as we probably want to keep all the data points in the Flent
>> data file anyway, I think we might as well do the sub-sampling in Flent.
>> Just thinning the plots is a few lines of numpy code; just need to
>> figure out a good place to apply it.
>>
>> Handling loss is another matter, but one that I need to deal with
>> anyway. Right now I'm just throwing away lost data points entirely,
>> which loses the lost_{up,down} information. Will fix that and also
>> figure out the right way to indicate losses.
>>
>
> Groovy.
>
>
>> -Toke
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/tohojo/flent/issues/106#issuecomment-345693455>, or mute
>> the thread
>> <https://github.com/notifications/unsubscribe-auth/AerUv9ZyQpd6Oq7HudRiOYPKKIg8Ey8Aks5s4XzMgaJpZM4MpJAm>
>> .
>>
>> _______________________________________________
>> Flent-users mailing list
>> Flent-users@flent.org
>> http://flent.org/mailman/listinfo/flent-users_flent.org
>>
>>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619 <(669)%20226-2619>
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

[-- Attachment #1.2: Type: text/html, Size: 6134 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]

Pete Heist <notifications@github.com> writes:

>> On Nov 20, 2017, at 9:58 PM, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> Okay, testable code in the runner-refactor branch.
>> 
>> Ended up doing a fairly involved refactoring of how runners work with
>> data; which is good, as the new way to structure things makes a lot more
>> sense in general; but it did mean I had to change the data format, so
>> quite a few places this can break. So testing appreciated, both for
>> running new tests, and for plotting old data files.
>> 
> Awesome, I’m sure it could take some shaking out. I tried an rrul_be
> test on the runner-refactor branch...

Ha! Epic fail! :D

Well, I only just managed to finish writing the code and unbreaking the
CI tests; didn't actually get around to running any tests. I've fixed
those two errors, and am running a full test run on my testbed now...

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 3814 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1340 bytes --]

Pete Heist <notifications@github.com> writes:

>> On Nov 21, 2017, at 11:36 AM, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> 
>> Ha! Epic fail! :D
>> 
>> Well, I only just managed to finish writing the code and unbreaking the
>> CI tests; didn't actually get around to running any tests. I've fixed
>> those two errors, and am running a full test run on my testbed now…
>
> Much better now though! Both rrul_be test ran fine for me (with and
> without —socket-stats).

Cool. Getting closer. Still a few bugs to fix with the more esoteric
runners, but I'm working on that.

> Next thing I noticed as for current tests, for rrul_be_nflows, the
> test completed but only one irtt instance ran (also just saw one
> connection to the server).
>
> % flent rrul_be_nflows --test-parameter upload_streams=8
> --test-parameter download_streams=8 --socket-stats -l 60 -H $SERVER -p
> all_scaled --figure-width=10 --figure-height=7.5 -t irtt -o
> irtt_8flows.png

Well that's actually to be expected. That test only varies the number of
TCP parameters; there's always a single ICMP and a single UDP latency
measurement.

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 4394 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 798 bytes --]

Pete Heist <notifications@github.com> writes:

> Trying to confirm how latency was being calculated before with the
> UDP_RR test. Looking at its raw output, I see that transactions per
> second is probably used to calculate RTT, with interim results like:
>
> ```
> NETPERF_INTERIM_RESULT[0]=3033.41
> NETPERF_UNITS[0]=Trans/s
> NETPERF_INTERVAL[0]=0.200
> NETPERF_ENDING[0]=1511296777.475
> ```
>
> So RTT = (1 / 3033.41) ~= 330us
>
> And this likely takes the mean value of all transactions and
> summarizes it at the end of the interval, then the calculated latency
> was what was plotted in flent?

Yup, that's exactly it :)


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

[-- Attachment #1.2: Type: text/html, Size: 3216 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1138 bytes --]

Pete Heist <notifications@github.com> writes:

>> > And this likely takes the mean value of all transactions and
>> > summarizes it at the end of the interval, then the calculated latency
>> > was what was plotted in flent?
>> 
>> Yup, that's exactly it :)
>
> Ok, it’ll be interesting for me to look at the differences between the
> two going forward. Naturally doing it the udp_rr way would probably
> result in a smoother line. The other impacts on the test might be fun
> to explore.

Well the obvious one is that the netperf measurement uses more bandwidth
as the latency decreases. Have been meaning to add that to the Flent
bandwidth graphs, but now I'm not sure I'll even bother :P

Also, the netperf measurement will stop at the first packet loss (later
versions added in a timeout parameter that will restart it, but even
with that we often see UDP latency graphs completely stopping after a
few seconds of the RRUL test).

-Toke


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

[-- Attachment #1.2: Type: text/html, Size: 3882 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 219 bytes --]

Closed #106 via 117b39c89c0780d6c3082be79571b3807a3198e7.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/106#event-1353926710

[-- Attachment #1.2: Type: text/html, Size: 2113 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 523 bytes --]

Right, so convinced myself that I'd fixed most of the breakages in the refactor (which turned out to be a multiple-thousands lines patch, but with a net negative of 400 lines of code; not too bad), so merged it and closed this issue.

Please open new issue(s) for any breakage that I missed. I'll open a new one specifically for using irtt for VoIP tests.

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

[-- Attachment #1.2: Type: text/html, Size: 2414 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 254 bytes --]

Oh, and many thanks for your work on irtt, @peteheist! We really needed such a tool :)

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

[-- Attachment #1.2: Type: text/html, Size: 1920 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 464 bytes --]

Pete Heist <notifications@github.com> writes:

> So I'm glad! Looking forward to playing with this more soon. Thanks
> for all that refactoring too, looks like it was some real walking
> through walls...

Meh, it needed doing anyway. You just gave me a chance to repay a bit of
technical debt ;)


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

[-- Attachment #1.2: Type: text/html, Size: 2372 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 251 bytes --]

The owd data is already being collected, so it's fairly trivial to add the plots...

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

[-- Attachment #1.2: Type: text/html, Size: 1850 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Matthias Tafelmeier]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1075 bytes --]

On 09/26/2017 01:35 AM, Dave Täht wrote:
> > sysadmin@luke:~ $ ./irtt -i 10ms -d 30s -l 160 a.b.c.d
> > IRTT to a.b.c.d (a.b.c.d:2112)
> >
> > Min Mean Median Max Stddev
> > --- ---- ------ --- ------
> > RTT 11.59ms 15.73ms 14.39ms 49.34ms 3.64ms
> > send delay 5.9ms 9.23ms 6.8ms 43.16ms 3.48ms
> > receive delay 5.42ms 6.5ms 7.59ms 17.88ms 937µs
> >
> > IPDV (jitter) 1.25µs 2.52ms 4.15ms 29.16ms 2.75ms
> > send IPDV 36ns 2.41ms 595µs 28.84ms 2.69ms
> > receive IPDV 60ns 734µs 3.55ms 9.57ms 914µs
> >
> > send call time 56.3µs 70.6µs 236µs 22.7µs
> > timer error 4ns 11.3µs 9.59ms 187µs
> > server proc. time 6.93µs 7.62µs 68.1µs 2.23µs
> >
> > duration: 30.2s (wait 148ms)
> > packets received/sent: 2996/2996 (0.00% loss)
> > bytes received/sent: 479360/479360
> > receive/send rate: 127.9 Kbps / 127.9 Kbps
> > timer stats: 4/3000 (0.13%) missed, 0.11% error
> >
> > g711.json.gz
> >

Hm, these efforts could have been synergized w\ mtr, no?

https://linux.die.net/man/8/mtr

-- 
Besten Gruß

Matthias Tafelmeier


[-- Attachment #1.1.1.2: 0x8ADF343B.asc --]
[-- Type: application/pgp-keys, Size: 4806 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org