On Apr 28, 2015, at 7:32 AM, mmann78@xxxxxxxxxxxx wrote:
> I started
working on ensuring that SRT (service response time) stats that are available in
Wireshark are also available in TShark (taking bug 9363 a step farther). I
initially collected my data by doing a grep on ",srt" and comparing the
filenames it showed up on in \ui\cli and \ui\gtk. The initial list showed a big
disparity between what was supported in Wireshark and what was supported in
TShark. After digging a little deeper, I came to realize that the disparity
isn't that great, it's just some of the TShark stats use ",rtd" (response time
delay) as their stat tap name.
>
> So my first question would be - what's
the difference? It appears the computation is different,
Is that "different"
as in "they have no columns in common" or "different" as in "they have some
columns in common but one or both of them have columns that the others
don't"?
The latter. All seem to have Min/Max/Avg SRT, but the difference between "SRT" and "RTD" seems to be that "SRT" has "Sum SRT" column and "RTD"
has "Min in Frame" and "Max in Frame" (and I don't understand the meanings of the fields to know why each are separate/important).
A few of the dissectors have additional fields, but I would consider all of these "common".
> but then why did the Wireshark stat tap names that use ",rtd" in
TShark use ",srt" in the first place?
I.e., some Wireshark taps that have
"{protocol},srt" as the name actually do RTD-style rather than SRT-style
statistics?
Yes. MEGACO, MGCP, and Radius all use "{protocol},srt" as a name (in GTK), but do RTD-style statistics (and use "{protocol},rtd" in tshark).I'm of the impression that the GTK tap name is "less visible" to most users than the tshark name, so I think the protocols computing "RTD"
should really have their taps renamed.
