Comment # 11
on bug 8647
from Evan Huus
(In reply to comment #5)
> The key stumbling block for my brain is that the syntax "(field)field [and
> filter]" conflates the term 'field' with the term 'filter'. A more verbose
> approach:
Yes, this is odd, I will see what I can do to clear that up, thanks for the
suggestions.
> So, there's an alternate syntax for the tshark man page ... that being said,
> the current syntax conveys the result in a more compact manner, despite its
> conflation of the term 'field' with 'filter'. [And, I note, there is plenty
> of room for error on /my part/ here ... recall that I'm new to the -z
> io,stat feature set, and I may be misunderstanding something here. In note
> that, in running this against file-copy.pcap, I get results of '0', i.e.
> smb.time is '0' regardless of how I slice & dice this. ]
I think you want smb2.time - there are no smb1 packets in the capture :)
(In reply to comment #6)
> OK, for file-copy.pcap, the syntax you demonstrate delivers the results I
> would expect, sanity-checked using Excel.
>
> I note several remaining issues though ... issues which may, of course,
> reflect my ignorance more than a bug in Wireshark.
>
> (a) The GUI approach (Wireshark) to the tshark "-z io,stat..." calculation
> does not work for me.
I'm not sure what you mean. In your original report you used the GUI's FBAR to
get the same results, so has it suddenly stopped working in 1.10?
Looking at the screenshots in your PDF I want to blame this on Windows having
confusing widgets - I don't think you have Graph 1 enabled (even though it's
blue from being the selected widget, the button doesn't appear depressed).
> (b) When I employ a second trace (this one illustrating an HTTP
> conversation), tshark and Excel deliver differing results (and the GUI
> approach continues to deliver nothing).
I want to blame this on packet reassembly, but I'm not sure which way the blame
should go - either tshark is being smarter than your manual excel process, or
it's trying to be smarter and is making a mistake. I'll take a closer look.
> Background:
> -Several years ago, I wrote an article for the UseNix Association's
> publication ";login" describing how to use various techniques to estimate
> the contributions of the Client, the Network, and the Server to the total
> performance 'pie', i.e. to the total transaction time.
> http://www.skendric.com/app/make-cns-pie/Making-Client-Network-Server-Pie.pdf
>
> On p.16 of that document, I demonstrated how to use tshark to perform this
> calculation ... using a Display Filter ('-R') rather than an io,stat filter
> ... perhaps I was simply propagating inaccurate information, perhaps tshark
> behaved differently back then (v1.7.1)
I wasn't a dev back then, so I honestly don't know. I do know that tshark's
filtering flags have been rewritten a few times and have been subtly different
each time, so it wouldn't surprise me if that use to work. The current
behaviour is intended though - it just needs better documentation.
You are receiving this mail because:
- You are watching all bug changes.