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
- Follow-Ups:
- Re: [Wireshark-users] use of -z io,stat
- From: Sake Blok
- Re: [Wireshark-users] use of -z io,stat
- References:
- [Wireshark-users] use of -z io,stat
- From: Stuart Kendrick
- Re: [Wireshark-users] use of -z io,stat
- From: ronnie sahlberg
- Re: [Wireshark-users] use of -z io,stat
- From: Sake Blok
- Re: [Wireshark-users] use of -z io,stat
- From: ronnie sahlberg
- [Wireshark-users] use of -z io,stat
- Prev by Date: Re: [Wireshark-users] use of -z io,stat
- Next by Date: Re: [Wireshark-users] use of -z io,stat
- Previous by thread: Re: [Wireshark-users] use of -z io,stat
- Next by thread: Re: [Wireshark-users] use of -z io,stat
- Index(es):