From: "Guy Harris"
Sent: Thursday, November 21, 2002 6:06 AM
Subject: Re: Display extension, ideas (was RE: [Ethereal-dev] io-stat pretty
picture for website)
> Biot Olivier said:
> > This discussion leads to the following proposal for enhancement: what if
> > we generate a flexible way of presenting graphical analysis of protocol
> > data, a thing like the filter logic already built into Ethereal? We
> > could easily save those analysis displays (as we save e.g., color
> > filters), and when presenting them give the window the appropriate name.
>
> I.e, have a tap that interprets arithmetic expressions constructed using
> field names, and lets you draw graphs (or show tables) based on that?
>
> That sounds like a reasonable idea.
It also sounds like a lot of work.
But, if such a parser and expression evaluation engine could be built by
someone, it would
provide a mechanism for incredibly powerful processing/presentaion.
After reading the discussion. I will try a few changes to the io-stat tap to
see if it can be made more generic.
The mechanisms discussed above does not really sound like a short-term
project so let me propose the
following extension for the short-term:
Change the type menubox from "frames/s" and "bytes/s" to also have a third
item "Advanced"
If and only if "Advanced" is selected, some new widgets become visible:
For each of the five graphs, two new widgets become visible:
One textbox where one can specify the name of one single hf field, and
One menubox where one can select something like
COUNT(*)
SUM(*)
MAX(*)
MIN(*)
AVG(*)
If COUNT(*) were selected, the value displayed in the graph would be the
number of occurences of the specified hf field that was encountered during
the measurement interval. Applicable to all types of fields.
SUM(*) Only applicatble to FT_UINTxx types. Self explanatory.
MAX/MIN/AVG Applicable to FT_UINTxx and FT_RELATIVE_TIME. Self explanatory.
This would allow io-stat to do something useful like :
Enable three graphs:
For each of the three graphs, specify the same display filter, like "nfs &&
rpc.response_time"
(or whatever the field for rpc rtt is called)
Then specifying
MAX(*) rpc.response_time
MIN(*) rpc.response_time
AVG(*) rpc.response_time
Which would produce a graph on how the MIN/MAX/AVG response times to NFS
calls changes over time.
This is something I would personally find very useful sometimes so you can
consider the probablility of this extension to io-stat happening to be
rather high.
The changes needed to io-stat.c should be fairly "trivial" but lets wait
until I finish with the traffic map first.
I can right now not see any realistic need for even more generic generic
semantics on how to describe
the io-stat stule of time/value graphs and think this would be more than
sufficient for almost every realistic type of time/value graph one can
imagine.
Well, I cant see any realistic need for ME to have anything more generic
or powerful than what i detailed above.
If you think I am wrong, please enlighten me.