["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

>From Spamcontrol2:

Subject: Re: [Ethereal-users] Ethereal Top Talkers - Other reporting info?


> In fact, there were two main ideas behind my request - 1) I often need a
way to
> spot "interesting events" or quickly reference response times as I scan
through
> a trace, and 2) I wanted a way to export this information, in its
entirety, to a
> file that I could easily manipulate (with Excel or other programs we've
written)

> Also, the field filtering suggestions (smb.time>t) and color marking
suggestions
> will be VERY handy.


You may also want to enable TCP Sequence number analysis (and relative
sequence numbers)
and create a ColorFilter    "tcp.analysis.flags"    and make the background
for these packets RED.

All Retransmissions, DuplicateAcks, ZeroWindows, ZeroWindowProbes,
ACKs of segments we have not seen,   FirstSegmentAfter a retransmission etc
etc
will be flagged as RED.

It then gets TRIVIAL to spot fast retransmissions or normal (and truputwise
fatal)
retransmission timeouts.
Do check what TCPSequenceNumberAnalysis will flag for you.
It is MUCH more complete/correct than the "joke" that exists in other
products to do this.
(some products can not even figure out if something is a TCP retransmission
unless it has actually seen the exact same packet earlier in the capture,
load a capture file with lot of
packet loss in into both ethereal and other tools and compare for yourself.)


It would be nice to enhance it to detect the difference between
FastRetransmission and normal Retransmissions
but it is not too urgent for me to look at right now.
It could be enhanced sometime to calculate RTT according to RFC2988 and flag
those ACKs
that take too long and thus violates the standard.


>
> I still would like to be able to place the response time fields within the
> summary/packet list for quicker reference as I scan a trace (it will slow
me
> down otherwise, and I'm usually not looking for a particular response
time).
> There's no way to do this using the Preferences->Columns dialog?
>
> And, from what I can tell there's no easy way to measure response-to-call
times
> (what I've been calling "client idle times", though I know that's a bit
> misleading), at least with NFS/RPC and CIFS, correct?

NFS, or rather ALL ONC-RPC based protocols that ethereal supports, we
already do
support application call-to-response times.
Both as an individual field down in the RPC layer (not in the NFS layer) for
each individual
call  as well as aggregated statistics both with tethereal and ethereal.

-z rpc,rtt,...    see manpage,    for ethereal, use the menu under Tools:

After a specific ONC-RPC based protocol has been selected and which version
you were interested in
it will calculate Min/Max/Average  response times for each procedure for
that protocol and display it as a table.

It is quite powerful when used from tethereal,
I have which i use a small shellscript that
    calls tethereal once to extract the IP address for everyone that speaks
NFS v3 in the capture,
    then for each IP address, calculate the NFSv3  response time statistics
Everything is then put together to a simple text report where I get Client
by client NFSv3  response times.
Very useful.

Another script I have does:
    call tethereal and extract all filehandles.
    for each filehandle, call tethereal again and produce NFSv3 response
time statistics
All this is put together into a text file where I get NFSv3 response time
statistics on a per file basis.
Very Cool, and VERY useful (to find HOT files)
Just look for the file which has lots of IO to it and has high latency.



I just checked in tethereal and ethereal support to produce Min/Max/Average
call-response time statistics for SMB
as well.  Will be available in next release.



All these statistics are also already available in all dce-rpc protocols
such as SAMR, LSA, NETLOGON etc.
and would be trivial to add to any other call-response protocol supported in
ethereal.


Oh,    something similar to top-talkers can now be calculated by tethereal
it currently only supports  ethernet, ip and tokenring
but is still useful.