thebracket
commented
1 year ago On the dots vs. lines for bandwidth, Plotly leaves us with a tricky choice:
a) You can have lines, but you are stuck with a Download and Upload line per IP in the circuit (the number is bounded only by the tracked subnet and what traffic happens to be there) b) You can have dots (which actually render a bit slower) and combine each IP with one color/legend entry (it only shows the legend when there's more than one) per IP.
I honestly find the visualizations in that "mice & elephants" paper so hard to read that I'm still not sure what they're trying to tell me. I'm pretty sure if I stare at them long enough I'll spot a Rorschach blot.
Packet capture rendering is a tricky one. From the point of view of figuring out why someone's net connection isn't working, spotting the small packets is proving to be pretty useful. A variance in size is often where the interesting stuff is. So I like using the y axis for that. I can also see some value in isolating flows, or finding a way to render them separately. I'd be interested to see how useful people would find that; I strongly suspect that a lot of our target audience won't go much beyond "hey look, there's traffic".
I'll investigate the other delay metrics.
dtaht
I have to admit I was comfortable with "lines" for bandwidth, rather than dots. Dots for drops is definately better than lines. I am pretty interested however in what dots look like vs a vs real traffic.
In terms of the two things lining up better, I do not understand why the 0 start is so offset from the other, and these two charts could be co-joined to eliminate the first time since now phrase and the numbers if they did line up.
2) It is also possible I was confusing regarding the piano roll idea? which I was trying to apply to one of the plots that was part of the flows->analyze section, where we would show one flow per line, much like that mice and elephants 2002 paper did. Each packet represents a note on a musical scale. Presently it groups all flows by size, which is less useful.
3) Lastly, it was the cake sp_delay (not sp_flows) that keeps track of how much latency the sparser flows are actually experiencing in usec. I am sorry I misspoke about sp_flows. av_delay and pk_delay tend to closely reflect the depth of the overall queue, it is my hope that sp_delay shows the benefits of fq better.