[bugzilla-daemon@xxxxxxxxxxxxx]

Jim Young changed bug 11920

What	Removed	Added
Status	INCOMPLETE	RESOLVED
CC		jyoung@gsu.edu
Resolution	---	NOTABUG

Comment # 10 on bug 11920 from Jim Young

Hello Carsten,

The reason that the "NFS" and "RPC" bytes/sec graphs are so much lower than the
"Stream 0" graph is because your trace contains many fewer NFS and RPC frames
than it does TCP frames!

In your sample trace (thanks) 100% of the packets match the display filter of
"tcp.stream==0" but only 6.9% of the frames match a display filter of "rpc" or
of "nfs".

>From your screen shots you've configured the IO Graph to plot three different
graphs.

#1 - a count of the bytes (per second) for "tcp.stream==0" frames
#2 - a count of the bytes (per second) for "nfs" frames
#3 - a count of the bytes (per second) for "rpc" frames

These IO graphs simply plot the sum of the frame lengths of the packets that
match each of the filters for the configured time interval (in this case one
second).

Obviously what you want really want to plot is the lengths of RPC and NFS
packets.

As you are aware NFS is encapsulated in RPC and in this case RPC is
encapsulated in TCP.  But each RPC packet is sent in multiple TCP segments. 
The complete set of TCP segments must be reassembled to create the original
RPC/NFS packet.  Wireshark only displays the reassembled RPC/NFS packet in the
last packet of each reassembled TCP segment train.  So only the last TCP packet
of each TCP segment train ends up matching the display filters of "nfs" or
"rpc".

I believe you can achieve your objective by plotting the
"tcp.reassembled.length",
"rpc.fraglen" and/or perhaps the "nfs.count3" field values. 

To generate a graph of the RPC bytes per second configure the "Display Filter"
field with the value "rpc", the "Y Axis" field with the formula "Sum(Y Field)"
and the "Y Field" with the field value "tcp.reassembled.length".  This will
plot the length of the complete RPC packet including the RPC header.

To generate a graph of the NFS bytes per second configure the "Display Filter"
field with the value "nfs", the "Y Axis" field with the formula "Sum(Y Field)"
and the "Y Field" with the field value "rpc.fraglen".  I'm no RPC/NFS expert
but this appears to plot the length of the complete NFS packet including the
NFS header.

It becomes a little harder to generate a graph of just the NFS payload bytes
per second.   If you configure a "Display Filter" field value of "nfs" and
the"Y Axis" field with the formula "Sum(Y Field)" and the "Y Field" with the
field value "nfs.count3" you will see a plot twice as high as expected.  This
is because the field "nfs.count3" exists both in the NFS WRITE Call packets and
the and NFS Write Reply packets.  To generate a graph more in line with the
actual bytes transmitted you could simply augment the "Display Filter" field
with something like "nfs && ip.src="" where <IPADDRESS> is the host
that is transmitting the file.

To help illustrate the differences in these three field's values you might want
to add Custom Columns to Wireshark's Packet List for "tcp.reassembled.length",
"rpc.fraglen" and "nfs.count3".  This will allow you to compare the three
values side by side and determine which value(s) might be best for your needs. 
Displaying them in the Custom Column in this manner will also help with
understanding why simply plotting the "nfs.count3" could result in a plot twice
as high as expected. 

With the modified IO Graph Y Axis and Y Field value in place I believe you will
see the IO Graph congruency you expect.

If you believe this analysis is incorrect please feel free to reopen this bug.

---

      You are receiving this mail because:

• You are watching all bug changes.