Home page logo
/

wireshark logo Wireshark mailing list archives

Re: wireshark and RTT
From: Martin Visser <martinvisser99 () gmail com>
Date: Thu, 29 Aug 2013 22:32:42 +1000

Simone,

Way back about 4 years ago, when I was doing an application response time
assessment, I also found some inconsistencies in the way that Wireshark
sometimes calculated RTT. The main issue was that it didn't always
correctly associate the appropriate ACK with right SEQ. I'd probably want
to look at the specifics of what you are seeing to see if it was the same
problem I was observing. For what it is worth, my post from 2009 is here :-
http://www.wireshark.org/lists/wireshark-users/200906/msg00068.html

Martin

Regards, Martin

MartinVisser99 () gmail com


On 27 August 2013 17:52, Simone Ferlin-Oliveira <ferlin () simula no> wrote:

Hi,
I am capturing traces at client and server and only transferring in
downlink, download (s->c) direction.
I am plotting different things about these flows - window size, rtt, etc.
Depending on the plot, either one trace file or the other is appropriate,
but even like this, wireshark shows sometimes very uncommon RTT values. I
compare them with tcptrace to validate. I know approximately in which range
they should be and
sometimes wireshark shows different values compared to tcptrace -Z ... . I
am relying on tcptrace for now. captcp was another
option, but since I capture only 150B for each packet. The tool has a
small bug because it accepts only full packets. I modified
the code, but the calculations are wrong since it considers full packet
sizes only...



On 26 August 2013 15:37, NITIN GOYAL <nitinkumgoyal () gmail com> wrote:


On Mon, Aug 26, 2013 at 6:53 PM, Simone Ferlin-Oliveira <ferlin () simula no
wrote:

Hi, I am doing a download from server to client and I want to see the
RTT estimates.
Why is that so complicated? :)
Thanks for the link, but there is no conclusion there, right? What was
the conclusion of your discussion with the wireshark forum people?


I did not got conclusion as I was capturing at the client end and it
didnot have the access to the server to take the reverse values to validate.

It is not complicated but it is like how exactly you are taking the
captures. IF you say the RTT value is not convincing, how you say they are
not? Actually there are other ways/tools to validate the values.

Like you can capture the trace and put the trace with the help of
tcptrace tool which also calculate the RTT.

Also, you can take reverse RTT calculation frm the server and validate if
that will work for you.

For me, i did like that with the help of tcptrace i was getting a bt
different values then showed by wireshark which looked convincing to me.

Regards
Nitin


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org
?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org
?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]