Ronnie Sahlberg wrote:
> > Actually, it could become very useful if the information shown wasn't just
> based
> > off of traffic loading, but could be based off of any (numerical)
> filterable
> > field or tap output. Like what about maximum tcp round trip time or tcp
> > retransmission rate or other things like that? From the network analysis
> > perspective, those are highly useful pieces of information.
> >
>
> Interesting idea.
> Yes, other criterias than just number of bytes or number of frames would
> indeed be very useful.
>
> I will see if it can be made so that the generic case, as I belive to be
> either number of frames or bytes,
> will not be inefficient. Otherwise it can just be coded as two similar
> tools, one being optimized for performance and memory for frames and bytes
> only and another more generic one that can do everything.
>
> Let me build a few generations of prototypes so I can see how it would work
> and what it will be able to do.
>
> The tcp-retransmission rate would just be to specify the filter
> "tcp.analysis.retransmission" and just count number of frames so that one
> would not need anything special.
> The maximum-round-trip-time would need a special and more generic case, that
> one would also be very useful. I will keep that one in mind when prototyping
> it.
a filter of "tcp.analysis.retransmission" wouldn't do exactly what I was
thinking... I'm going to bias my discussion towards iostat style output since
it already exists. Maybe more a filter along the lines of "tcp ||
tcp.analysis.retransmission" and then plot the "average value per tick" of
tcp.analysis.retransmission (where nonexistence defaults to zero and existence
has a value of 1)
If the tcp graph stuff got moved over to a tap, round trip time would be more
easily available. Again something like "max per tick" would work for a
maximum... of course the most generic would be some kind of expression
evaluation similar to how filtering is done now.
I'll be very interested in what you come up with.