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, view it on GitHub, or mute the thread.