From: "Toke Høiland-Jørgensen" <notifications@github.com> To: tohojo/flent <flent@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [Flent-users] [tohojo/flent] packet loss stats (#106) Date: Tue, 26 Sep 2017 11:35:38 -0700 [thread overview] Message-ID: <tohojo/flent/issues/106/332293836@github.com> (raw) In-Reply-To: <tohojo/flent/issues/106@github.com> [-- 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
next prev parent reply other threads:[~2017-09-26 18:36 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <tohojo/flent/issues/106@github.com> 2017-09-26 9:41 ` Toke Høiland-Jørgensen 2017-09-26 18:35 ` Toke Høiland-Jørgensen [this message] 2017-10-10 9:08 ` Toke Høiland-Jørgensen 2017-10-15 17:18 ` Toke Høiland-Jørgensen 2017-10-16 15:54 ` Toke Høiland-Jørgensen 2017-10-31 11:12 ` Toke Høiland-Jørgensen 2017-10-31 12:02 ` Toke Høiland-Jørgensen 2017-11-16 9:57 ` Toke Høiland-Jørgensen 2017-11-16 12:15 ` Toke Høiland-Jørgensen 2017-11-16 12:17 ` Toke Høiland-Jørgensen 2017-11-16 12:48 ` Toke Høiland-Jørgensen 2017-11-16 13:07 ` Toke Høiland-Jørgensen 2017-11-16 13:18 ` Toke Høiland-Jørgensen 2017-11-16 14:47 ` Toke Høiland-Jørgensen 2017-11-16 18:09 ` Toke Høiland-Jørgensen 2017-11-16 18:11 ` Toke Høiland-Jørgensen 2017-11-17 14:58 ` Toke Høiland-Jørgensen 2017-11-18 13:04 ` Toke Høiland-Jørgensen [not found] ` <tohojo/flent/issues/106/345442147@github.com> 2017-11-18 19:07 ` Dave Taht 2017-11-20 12:11 ` Toke Høiland-Jørgensen 2017-11-20 13:21 ` Toke Høiland-Jørgensen 2017-11-20 21:14 ` Dave Taht 2017-11-20 21:44 ` Dave Taht 2017-11-20 16:01 ` Toke Høiland-Jørgensen 2017-11-20 20:58 ` Toke Høiland-Jørgensen 2017-11-21 10:36 ` Toke Høiland-Jørgensen 2017-11-21 14:53 ` Toke Høiland-Jørgensen 2017-11-21 21:56 ` Toke Høiland-Jørgensen 2017-11-22 7:49 ` Toke Høiland-Jørgensen 2017-11-22 12:03 ` Toke Høiland-Jørgensen 2017-11-22 12:05 ` Toke Høiland-Jørgensen 2017-11-22 12:06 ` Toke Høiland-Jørgensen 2017-11-22 13:34 ` Toke Høiland-Jørgensen 2017-11-22 21:57 ` Toke Høiland-Jørgensen [not found] ` <tohojo/flent/issues/106/332043470@github.com> 2017-11-26 16:49 ` Matthias Tafelmeier
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.flent.org/postorius/lists/flent-users.flent.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=tohojo/flent/issues/106/332293836@github.com \ --to=notifications@github.com \ --cc=flent@noreply.github.com \ --cc=reply+01ead4bfd1ef9165cd44e731104a0f57159a0a025eceec0c92cf0000000115e25ffa92a169ce0ceefa50@reply.github.com \ --cc=subscribed@noreply.github.com \ --subject='Re: [Flent-users] [tohojo/flent] packet loss stats (#106)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox