[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 6 on bug 8178 from Cal Turney

(In reply to comment #5)
> Note also that an _expression_ of COUNT(smb2.cmd) and a filter of "smb2.cmd ==
> X && smb2.file_info.infolevel", where X is a command that has a file_info
> structure containing an infolevel subfield, would, I think, end up counting
> *all* the SMB2 commands in a packet in which *at least one* command had a
> file_info structure containing an infolevel subfield.  This may not be what
> is intended.

Yes. In the vast majority of cases this is not what the user intended. As many
responses get queued up on a NAS server, they will typically gegin to transmit
multiple responses in a framen.  The same happens with clients such as
webservers when they become overwhelemed with requests. Over the course of the
capture period the clients or server may transmit varying numbers of
requests/responses. The mere fact that some frames have multiple requests
should in no way alter the statistical results. If Wireshark's SRT dialog
reports that ther are 100 Writes with an average SRT of 2.3ms, io,stat and IO
Graph should report the same number. In the NFSv3 example I mentioned, a single
frame had 1 LOOKUP, 1 READ, and 4 GETATTR responses but when I filtered for the
number of LOOKUPs the tools reported that there were 6 LOOKUPs but it gets
worse. Consider this output:

tshark -n -q -r multiple-resp-frame-635.cap -z
io,stat,0,"COUNT(nfs.procedure_v3)nfs.procedure_v3==1 and
frame.number==635","SUM(rpc.time)rpc.time and nfs.procedure_v3==1 and
frame.number==635" -z io,stat,0,"COUNT(nfs.procedure_v3)nfs.procedure_v3==3 and
frame.number==635","SUM(rpc.time)rpc.time and nfs.procedure_v3==3 and
frame.number==635" -z io,stat,0,"COUNT(nfs.procedure_v3)nfs.procedure_v3==6 and
frame.number==635","SUM(rpc.time)rpc.time and nfs.procedure_v3==6 and
frame.number==635" -z "rpc,srt,100003,3,frame.number==635"

=======================================================
NFS Version 3 SRT Statistics:
Filter: frame.number==635
Procedure        Calls    Min SRT    Max SRT    Avg SRT
GETATTR              4   0.113281   0.113281   0.113281
LOOKUP               1   0.113281   0.113281   0.113281
READ                 1   0.113281   0.113281   0.113281
=======================================================

==============================================================================
| IO Statistics                                                              |
|                                                                            |
| Interval size: 0.227 secs (dur)                                            |
| Col 1: COUNT(nfs.procedure_v3)nfs.procedure_v3==6 and frame.number==635    |
|     2: SUM(rpc.time)rpc.time and nfs.procedure_v3==6 and frame.number==635 |
|----------------------------------------------------------------------------|
|                |1      |2         |                                        |
| Interval       | COUNT |    SUM   |                                        |
|-----------------------------------|                                        |
| 0.000 <> 0.227 |     6 | 0.679686 |                                        |
==============================================================================

==============================================================================
| IO Statistics                                                              |
|                                                                            |
| Interval size: 0.227 secs (dur)                                            |
| Col 1: COUNT(nfs.procedure_v3)nfs.procedure_v3==3 and frame.number==635    |
|     2: SUM(rpc.time)rpc.time and nfs.procedure_v3==3 and frame.number==635 |
|----------------------------------------------------------------------------|
|                |1      |2         |                                        |
| Interval       | COUNT |    SUM   |                                        |
|-----------------------------------|                                        |
| 0.000 <> 0.227 |     6 | 0.679686 |                                        |
==============================================================================

==============================================================================
| IO Statistics                                                              |
|                                                                            |
| Interval size: 0.227 secs (dur)                                            |
| Col 1: COUNT(nfs.procedure_v3)nfs.procedure_v3==1 and frame.number==635    |
|     2: SUM(rpc.time)rpc.time and nfs.procedure_v3==1 and frame.number==635 |
|----------------------------------------------------------------------------|
|                |1      |2         |                                        |
| Interval       | COUNT |    SUM   |                                        |
|-----------------------------------|                                        |
| 0.000 <> 0.227 |     6 | 0.679686 |                                        |
==============================================================================

As can be seen, io,stat reports that frame 635 has 6 GETATTRs, 6 LOOKUPs, and 6
READs and all three are responsible for 680ms of latency for a total of 2.039
*seconds* of latency.  It doesn't take too many of these multi-response frame
to completely ruin an analysis of latency in performance investigations.

Rather than requiring the user to have to remember to specify filters in the
form "same_subtree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)", symantics
should be added to for requesting these tools to filter in a way that treats a
frame as one request or response tree.  For example:

  aggregated_tree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)
or
  full_tree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)
or
  frame(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)

In this way if frame one is a bear and frame 2 is a chicken and frame 3 has a
bear and chicken, if one filters for a bear with wings, COUNT(bear && wings),
the result would be a count of one. 

I have attached capture 'multiple-resp-frame-635.cap' that was used in the
above example.

---

      You are receiving this mail because:

• You are watching all bug changes.