tcptrace-bugs Time-line graph - times seem to be slightly mismatched?

From: Thomas Uhl (t_tuhl@qualcomm.com)
Date: 09/05/02

  • Next message: Yohanes N. W: "tcptrace-bugs how to create graphs?" 

    Message-Id: <5.1.0.14.2.20020904163637.0286e1f0@jittlov.qualcomm.com>
Date: Thu, 05 Sep 2002 17:35:30 -0700
From: Thomas Uhl <t_tuhl@qualcomm.com>
Subject: tcptrace-bugs Time-line graph - times seem to be slightly mismatched?

    I'm using tcptrace to view a single, simple connection for a 1M TCP
    transfer, being transferred from the remote end 1.3.0.2 to the local host
    1.3.0.1. There are no other hosts on my network. The transfer is
    successful. However, when I xplot the a_b_tline.xpl, it looks like the Ack
    for each packet is being sent out before the corresponding data packet has
    even arrived. I looked at the .xpl file and it is showing that the
    remote-end send timestamp of the 1st 536-byte packet is equal to the
    local-end arrival timestamp that tcpdump ascii-output is showing me, and as
    far as I can tell it is just fabricating a local-end arrival timestamp by
    adding ~3ms. Furthermore, the remote-end arrival timestamp of the Ack for
    that packet, is equal to the local-end send timestamp that tcpdump is
    showing me, and it appears to be fabricating a local-end send timestamp
    which is ~96ms earlier. How could tcptrace know when a packet was sent or
    received by the remote end, since all it knows it when a packet was sent or
    received by the local end, right? It appears to assume that the timestamps
    from tcpdump are remote-end timestamps and then guesses or makes up a
    local-end timestamp based on that. This same behavior holds throughout the
    entire transmission. Well, it makes a lot more sense if you look at the
    a_b_tline, it shows the Acks being sent before the data has arrived.

    The time sequence graphs look fine though, the green Ack line only
    increases after a white arrow indicating an incoming packet.

    a_b_tline.xpl, a2b_tsg.xpl, tcpdump -w tcp.6, and tcpdump -i eth0 > tcpa.6
    are attached.

    Thanks for your help,
    Tom

    This archive was generated by hypermail 2b30 : 09/06/02 EDT