Wireshark-users: Re: [Wireshark-users] use of -z io,stat
From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Wed, 29 May 2013 15:10:46 -0700
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@xxxxxxxxx> 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@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