Yes it would be useful to put it where the PDU end as well, but that
is a difficult problem when considering the single scan methodology of
tethereal.
The PDU time is mainly useful when detecting when a PDU took very long
to transfer due to retransmission timeouts, but when this happens the
last sent PDU might not necesserialy be the one that holds the last
bytes in the PDU.
Assume we send segments 1,2,3,4,5 of the PDU, but congestion occured
and segment 3 is the one retransmitted after one second, we would
then have in the capture :
1, 2, 3, 4, 5 <one second delay>, 3
the PDU time is the time from segment 1 to the second time segment 3
was transmitted.
Alternatively one could of course put the timestamp delta between the
current segments and the first segment in the TCP decode for all of
the semgents, not just the last one (since which oneIS the last one is
tricky to predict) but then we will have multiple such timestamps for
every PDU.
Another approach that might work and should provide reliable
measurements ( let me think about it for a while) would be to put the
PDU time, not in the initial segment of the PDU but instead in the
first ACK that ACKs exactly the end of the PDU.
(might have sideeffect on holes in the capture and unidirectional transfers?)
Then put in the initial PDU, frame #x, the lines:
"The last segment of this PDU is #y"
"This PDU was fully ACKed by #z"
These two would still not be filterable from Tethereal
but then in the ACK in frame #z one could have the line
"This PDU started in frame #x"
"The time to transfer and ACK this PDU was aaa.bbb seconds".
Or, maybe a muche better solution, if (which I do belive) people analyzing
performance wants to filter or measure it, would be to build a TAP
that will produce it as a report.
./tethereal -r foo.cap -R "not frame" -z tcp,pdutime
======
Number of PDUs monitored: 5
| Src | Dst | First Segment | Last Segment | Time To Transfer |
----------------------------------------------------------------------------------------------------------
1.2.3.4:5 1.2.3.5:6 55 977 1.445
I think maybe a TAP is best here.
On Fri, 12 Nov 2004 15:05:21 -0800 (PST), Guy Harris <gharris@xxxxxxxxx> wrote:
> Guy Harris said:
> > Perhaps it should be put into the segment where the PDU ends, as well,
>
> We might be able to get that "for free" if we put that into the reassembly
> code and have "show_fragment_tree()" display it. We have the frame number
> of the first fragment, and from that can get its time stamp.
>
> That would also give us that information for *other* protocols for free,
> as well.
>
>
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>