Wireshark · Wireshark-users: Re: [Wireshark-users] use of -z io,stat

[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

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@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>>> Archives:    http://www.wireshark.org/lists/wireshark-users
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>> ___________________________________________________________________________
>> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe