Pete Heist 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