Re: use of -z io,stat

[ronnie sahlberg <ronniesahlberg () gmail com>]

Or if you want to fix this,  change it to float and normalize to 1.0
== 1 i/o   then please go ahead.

Otherwise I can do it in a few days.
(I created this brain-fart  so it is suitable punishment if I have to
fix it too)


regards
ronnie sahlberg

On Wed, May 29, 2013 at 3:08 PM, ronnie sahlberg
<ronniesahlberg () gmail com> wrote:
> Ah,  the LOAD unit mis-design.
>
> This was done ages and ages ago.
> I did it in units of 1/1000  since I could then use simple integer arithmetics.
>
>
> This should probably be re-done to use floating point and then it
> should be normalized so the value 1.0  means 1 I/O.
>
>
> To fix this is long long overdue. Let me look at fixing this over the
> next few days.
>
>
> regards
> ronnie sahlberg
>
> On Wed, May 29, 2013 at 3:02 PM, Sake Blok <sake () euronet nl> wrote:
> > Hi Ronny,
> >
> > Regarding the LOAD graph, I have looked at it before and yesterday I used it to graph the load on http (since 1.10 
> > has a http response time measure). Do you know why the load is multiplied by 1000? It is in your presentation, but I 
> > always assumed that this was because of the tick interval of 1 ms that you used there. But whatever tick interval I 
> > choose, the load is always 1000 times the actual load.
> >
> > If there is no known reason for the 1000x upscale, I'm tempted to correct this so it does show actual load values. 
> > Any ideas?
> >
> > Cheers,
> > Sake
> >
> > On 29 mei 2013, at 23:44, ronnie sahlberg wrote:
> >
> > > Hi,
> > >
> > > "I want to calculate how much time the Client spent thinking:"
> > >
> > > This is actually a very difficult question to answer. Especially since
> > > with most clients/most protocols doing multithreaded concurrent i/o
> > > "client-slowness" is usually never as simple as delta between a reply
> > > and to the next request goes out but
> > > much more complex things to model like "slow client does slightly less
> > > concurrent i/o"
> > >
> > > While measuring server performance is pretty straightforward,
> > > measuring client performance is often surprisingly hard problem.
> > >
> > >
> > >
> > > One method I have found that works surprisingly well (for me) is the
> > > LOAD calculation in wireshark.
> > > This is a measure of the average queue depth between a client and a
> > > server. As the client issues new I/O, the queue grows, as the server
> > > completes a request the queue shrinks.
> > > This provides a metric to compare the relative speeds between a client
> > > and a server and how they are matched/where the bottleneck is.
> > >
> > >
> > > See this for a presentation I did a long time ago that contains a
> > > description of LOAD :
> > >
> > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC0QFjAA&url=http%3A%2F%2Fwww.snia.org%2Fsites%2Fdefault%2Ffiles2%2Fsdc_archives%2F2008_presentations%2Fmonday%2FRonnieSahlberg_UsingWireshark.pdf&ei=4XWmUc-gAqmqiQKM9oHQCQ&usg=AFQjCNFdiD93MJaGOBkol17t2KcncXEHvw&sig2=xIyIYZTOFoQs2gxKV8p0pA
> > >
> > >
> > > regards
> > > ronnie sahlberg
> > >
> > >
> > > On Sun, May 26, 2013 at 8:42 AM, Stuart Kendrick <skendric () fhcrc org> wrote:
> > > > I'm trying to teach myself how to use the '-z io,stat' options in tshark
> > > >
> > > > I was imagining that the following would tell me how many seconds the trace covers
> > > >
> > > > tshark -r sample-http.pcapng -o tcp.calculate_timestamps:TRUE -qz "io,stat,0,SUM(tcp.time_delta)tcp.time_delta"
> > > >
> > > > =============================================
> > > > | IO Statistics                             |
> > > > |                                           |
> > > > | Interval size: 11.1 secs (dur)            |
> > > > | Col 1: Frames and bytes                   |
> > > > |     2: SUM(tcp.time_delta)tcp.time_delta  |
> > > > |-------------------------------------------|
> > > > |              |1               |2          |
> > > > | Interval     | Frames | Bytes |    SUM    |
> > > > |-------------------------------------------|
> > > > |  0.0 <> 11.1 |    216 | 45453 | 23.817352 |
> > > > =============================================
> > > >
> > > > capinfos sample-http.pcapng
> > > > File name:           sample-http.pcapng
> > > > [...]
> > > > File size:           53 kB
> > > > Data size:           45 kB
> > > > Capture duration:    11 seconds
> > > > [...]
> > > >
> > > > But apparently not:  '23.817352' does not equal '11 seconds'
> > > >
> > > > https://vishnu.fhcrc.org/wireshark/sample-http.pcapng
> > > > I'm using wireshark 1.10.0rc2
> > > >
> > > > What am I not understanding about this '-z io,stat' feature?
> > > >
> > > > --sk
> > > >
> > > > Stuart Kendrick
> > > > FHCRC
> > > >
> > > > P.S.
> > > >
> > > > My actual use case will be more complex than this.  This trace was taken next to the Client.
> > > > I want to calculate how much time the Client spent thinking:
> > > > tshark -r sample-http.pcapng -o tcp.calculate_timestamps:TRUE -qz "io,stat,0,SUM(tcp.time_delta)tcp.time_delta and 
> > > > tcp.dstport==80"
> > > >
> > > > and how much time the Network + Server spent thinking:
> > > > tshark -r sample-http.pcapng -o tcp.calculate_timestamps:TRUE -qz "io,stat,0,SUM(tcp.time_delta)tcp.time_delta and 
> > > > tcp.srcport==80"
> > > >
> > > > To give myself insights into how much of the total transaction time the Client is contributing versus that of the 
> > > > Network + Server.
> > > >
> > > > But I figure that if I cannot even persuade tshark to sum every value in the DeltaT column, then I'm not ready to 
> > > > progress to the real-world use case.
> > > >
> > > >
> > > > P.P.S.
> > > > The Average function gives me a plausible answer:
> > > >
> > > > tshark -r sample-http.pcapng -o tcp.calculate_timestamps:TRUE -qz "io,stat,0,AVG(tcp.time_delta)tcp.time_delta"
> > > >
> > > > =============================================
> > > > | IO Statistics                             |
> > > > |                                           |
> > > > | Interval size: 11.1 secs (dur)            |
> > > > | Col 1: Frames and bytes                   |
> > > > |     2: AVG(tcp.time_delta)tcp.time_delta  |
> > > > |-------------------------------------------|
> > > > |              |1                |2         |
> > > > | Interval     | Frames |  Bytes |    AVG   |
> > > > |-------------------------------------------|
> > > > |  0.0 <> 11.1 |    473 | 349155 | 0.050354 |
> > > > =============================================
> > > >
> > > >
> > > > But when I sanity-check this calculation using Excel, I see a different result:
> > > > 0.023518s
> > > >
> > > > ___________________________________________________________________________
> > > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > >             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
> > > ___________________________________________________________________________
> > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > >             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >              mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe