Toke Høiland-Jørgensen <[email protected]> writes:
> 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
>
> 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.
with a seqno it might also be possible to see ooo packets.
>
> - 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?
To really complexify your (our) life at one point, I've been dying for a
decent videoconferencing emulation. Typical behaviors are a burst on a
keyframe, a long sparser string of updates to that keyframe, and
bandwidth probing behavior.
And yes, there is a working group (rmcat), and RFCs and papers on it
(the google congestion control one is pretty good, scream is also worth
reading) BUT: Don't listen to me on this, just keep coding.....
>
> - 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 commented.
> Reply to this email directly, view it on GitHub, or mute the thread.
--
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-332270525
_______________________________________________
Flent-users mailing list
[email protected]
http://flent.org/mailman/listinfo/flent-users_flent.org
