[Martin Visser <martinvisser99@xxxxxxxxx>]

Juha,

I just remembered that FTP uses two sockets, port 21 for control (which is initiated by the client) and port 20 for data (initiated by the server). Have a look at the port 20 data and if this makes more sense. 

If you are sure that 50ms average RTT is too small (because of speed-of-light distance to the server), then is it possible you are going through a proxy or some other WAN accelerator? Remember that the TCP session will be terminated on this intermediate device, hence the discrepancy you might be seeing.

Also if you check under Preference:Protocols:TCP that "Analyze TCP sequence numbers" is checked it will add SEQ/ACK analysis in the packet details field which can also help identify the RTT on a per-packet level.

Regards, Martin

MartinVisser99@xxxxxxxxx

On Tue, Jan 20, 2009 at 10:25 PM, Juha Yli-Penttilä <juha.yli-penttila@xxxxxx> wrote:

Hi Martin,

thanks for your comments. In this case the downlink FTP transfer is
ongoing, meaning that the file is downloaded from the server to the
client. There is no other traffic than acks from the client to the
server. If I try to select an ack and then plot the RTT graph, the
graph is totally empty. Is there any way to monitor RTT estimates that
the client sees by using this kind of downlink transfer?

Quoting "Martin Visser" <martinvisser99@xxxxxxxxx>:

> Juha,
>
> What you are seeing is the RTT for the traffic from the view of the server
> being responded to by the client. I assume from your notes that you are
> capturing traffic at the client end. Every time the server sends a
> non-zero-length TCP payload incrementing the SEQ, it also expects an ACK
> back from the client. Of course the same goes from the client traffic toward
> the server. Even though you are capturing on the client end, it still needs
> to do some processing before it sends the ACK.
>
> The fact that RTT is quantised (at discrete levels) I think is indicative of
> the resolution of the system clock on your machine, and hence the time
> stamp. (There is some incomplete discussion on that here -
> http://wiki.wireshark.org/Timestamps)
>
> In order to see the RTT graph that corresponds to the response time for
> client requests towards the server, you must select a frame in the TCP
> session that is in that direction. You have selected a frame from server to
> client, just select one going the other direction and then display the RTT
> graph again. You should then get what you expect.
>
> Regards, Martin
>
> MartinVisser99@xxxxxxxxx
>
>
> On Tue, Jan 20, 2009 at 2:39 AM, Juha Yli-Penttilä <juha.yli-penttila@xxxxxx
>> wrote:
>
>> Hi all,
>>
>> I captured a log of FTP transfer using EGPRS dial-up connection. The RTT
>> values seem to be too small, because most of the values are < 70ms. In
>> practise these should be something like 200-500ms. The log capturing and FTP
>> client were run on the same computer (another endpoint). Am I doing
>> something wrong or why the RTT estimates are this small? From the figure can
>> also be seen that most of the RTT values are on some certain levels, which I
>> guess should not be the case. Attached TCP RTT graph. Thanks in advance.
>>
>> --
>> Juha Yli-Penttilä
>> ___________________________________________________________________________
>> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>             mailto:wireshark-users-request@xxxxxxxxxxxxx
>> ?subject=unsubscribe
>>
>

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