> On Sep 26, 2017, at 1:35 AM, Dave Täht <[email protected]> wrote:
>
> While I'm obsessive, so many seem to think networks behave with gaussian
> (where the concept of stdev comes from) distributions.
>
> Pareto distributions are closer but still inadaquate... Poisson is poison:
>
> http://www.pollere.net/Pdfdocs/QrantJul06.pdf
>
> but by all means, throw stdev in there. It's sometimes useful.
>
> I am usually most interested in the outliers above the 98th percentile,
> and fine some use in seven number summaries also.
That’s really helpful feedback. I just added stddev “because ping has it”. Not
a great reason! Would have liked to hear V Jacobsen give that talk by the way.
Instead of trying to find some useful underlying distribution (sounds like I
won’t), would a textual histogram (that fits within my 80 column limit) be
useful? Summarizing outliers is also possible.
Ultimately though I think it will be more interesting to look at results in
Flent. BTW, I’m thinking about adding a simple web interface for the client
(after first release), but that will double the executable’s size, so it should
be separate from the command line app. Before that though, I’ll at least add
CSV export for spreadsheets.
I’m at at around 2.2 - 2.8 megs without symbol table, depending on platform.
That fits comfortably on my EdgeRouter X’s but needs to live on a RAM disk on
my OM2P’s with limited flash space. upx gets it down to around 850K on raspi,
for example, but I’ve found upx to be flakey sometimes.
> > * Read the OWAMP RFC, mostly. Good lord. At least it gave me an idea that
> > the
> > server can (later) return received packet count and/or a bitmap of recently
> > received packets for a flow so we can distinguish between upstream and
> > downstream packet loss, which is not possible right now.
>
> Don't let that RFC freeze you up! (talk about overenginering!)
Yes, I don’t want to be overly critical of the good thought and work put into
it, but I was concerned in the introduction when I read about encryption and
separation of the control and test servers before seeing anything about how
accurate measurements should be made. I didn’t see any mention of wall vs
monotonic clocks but I think it’s important.
I liked Russ Cox’s recent blog entry on the process for developing Go.
Particularly the section about "Explaining Problems", and the importance of
making sure to define the real problem that’s being solved and its
significance- having fallen into the trap of not doing so too many times myself
(continues to this day so something to keep watching for).
https://blog.golang.org//toward-go2 <https://blog.golang.org//toward-go2>
--
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-332095180
_______________________________________________
Flent-users mailing list
[email protected]
http://flent.org/mailman/listinfo/flent-users_flent.org
