["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

From: "Ronnie Sahlberg"
Subject: Re: [Ethereal-users] Ethereal Top Talkers - Other reporting info?


> From Spamcontrol2:

...
> ACKs of segments we have not seen,   FirstSegmentAfter a retransmission
etc
This should have been FirstSegment After a lost segment. I.e. it will tell
you,   "Previous Segment was lost"


> > 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?

No, but it could be added easily.
I might add an option to put these values from the Reply packets in the INFO
part of the
packet list.


> >
> > 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?

Ah,   when reading your mail again I now understand that you did
mean response-to-call   and it was not just a typo.

Hm.  interesting idea.
However, with NFS and CIFS you often have multiple overlapping requests at
the same time
even for the same session, which would make it "difficult" to come up with
a good semantic on how to describe this idle time in a way that makes sense.

Of course, one could filter out a 10 second interval of the capture and
measure the RTT statistics
over that, then multiply the Average RTT for a call with the number of such
calls and add it all up.

But with asynchronous requests, what would the value mean?
Aggregated application RTT during these 10 seconds might be 30seconds, just
meaning that on average
there were 3 commands in flight between client and server.
Would that be good or bad numbers?   How to interpret it?
Would 30seconds mean thet truput was very good or would it mean that only 3
commands in flight at any one time
is capping performance and the client should use 5 asynchronous calls
instead?
It would be difficult to parse thisd data in a meaningful way.

The numbers would also be dependant on where in the network the capture was
taken.
If the RTT mainly consists of network latency (not very likely for
interesting networks, but anyway) then
the values would be vastly different if the capture was taken close to the
server instead of close to the client.

Hmm.   this needs a lot of thought. But it would be useful.
If you can come up with semantics on how this would work and be calculated /
presented in a way that makes sense, then
i would be happy to try to implement it.


We need a discussion on what data to measure, how to calculate it and how to
present it in a meaningful way
(and not just as a pretty picture)


Maybe something like:
Divide the capture file intu intervals of length x ms.   x can be choosen
from 1 ms up to 100 s?
For each such interval,  calculate
   * number of commands that started in that interval.
        i.e. number of calls we saw.
   *   number of commands that completed in that interval
        i.e.  number of responses we saw.
   *   total number of commands that were either  started, ongoing or
completed in the interval.
        i.e. total number of commands that were either fully or partially in
flight   during either the entire or a part of the interval.
   *   aggregated time for the commands above.
        i.e.   a command that was started and completed inside the interval
would add   smb.time to the aggregated time.
        a command that was started before this interval but completes after
the interval would add the entire interval length
        to the aggregated time. etc.
    * NAT: normalized aggregate time,   ie the aggregated time from above
divided with the measurement interval.
       this may then tell us something similar to how many asynchronous
commands are in flight at a given time.

The NAT value could then be eyeballed from a table where each interval is
one line, or it could be fed into
say gnuplot or something.

Maybe the NAT value could be useful in analysis?   I guess a single threaded
client with only one single command in flight at a time
would show up as (if interval was choosen short enough)  as  1  1  1  0  0
0  0  0  0  ... 0 1 1 1 ..   alternating sequences of 1 and 0.
where wou could look at its "idle time" or duty cycle by just watching how
often the 0s and 1s changes.
I think however that for more realistic and multithreaded clients it may be
more difficult to interpret the NAT data.

Maybe it could give useful information, like how the average "load"/"command
queue length"/"maxmpxct useage"
or what you want to call it changes over time. ?


Can you come up with a description on what and how to measure  idle-time /
work-time  so we can start experimenting
on an implementation?


best regards
   ronnie sahlberg