> On Sep 26, 2017, at 11:41 AM, Toke Høiland-Jørgensen
> <[email protected]> wrote:
>
> Pete Heist <[email protected]> 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
I think that’s all in there (except packet size, will add it), but I’ll
reorganize it into groupings that may make more sense.
> A few comments about the data format:
>
> - I'm guessing all values are nanoseconds? Are the absolute times in
> UTC?
Yes, time.Time.UnixNano()- the number of nanoseconds elapsed since January 1,
1970 UTC.
> - 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.
> - Why are the IPDV values in a separate array?
For less memory usage / processing during the test, the IPDV array isn’t
created until after the test. But you’re right, it would make more sense for
consumption to have the individual round trip data in a single array. I'll make
it work for the JSON without changing the internal representation somehow.
> - 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.
> - 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.
> - 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.
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).
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.
> - 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?
Not really, it was just there for completeness. I just removed everything
except for four that I need for the bitrate calculations. I don’t even need to
have those in the JSON if it’s not something externally useful anyway.
> > - 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.
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. :)
--
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-332209237
_______________________________________________
Flent-users mailing list
[email protected]
http://flent.org/mailman/listinfo/flent-users_flent.org
