[PATCH] TcpRtt support in ragraph

[Carter Bullard]

Hi,
TcpRtt is actually calculated as the complete round trip time
measured as the syn->synack times "+" the synack->ack time.
Even if argus is in the middle, you will get a full roundtrip time
calculated, but you have to see all three packets in order
to calculate the metric.  Its possible that you have asymmetric
paths for the TCP data?

Because the TcpRtt is the sum of two other metrics, you can
print the two components and the totals to see where its messing up.

    ra -r file -s +synack +ackdat +tcprtt - tcp

If you want to have high assurances that the data you are printing
has a real tcprtt in it, use can filter the input.  This should work:

     ra -r file -s +tcprttt - tcp and syn and synack and ack

Carter


On Aug 25, 2008, at 6:58 PM, Tomoyuki Sakurai wrote:

> On Mon, Aug 25, 2008 at 09:40:07AM -0400, Carter Bullard wrote:
>>
>> Did you get interesting graphs for your TcpRtt metrics?  Do they
>> appear to be
>> reasonable for your experiments/observations?
>
> The reason I wrote the patch was that TcpRtt looked weired while I had
> been watching TcpRtt and sCo.
>
> Case 1:
>
> external clients -> argus -> my servers
>
> Almost all TcpRtt values are a few msec, even when the client is  
> outside of
> Japan like web crawlers. Argus is running on my router. My servers are
> just 1 hop away from the router.
>
> Case 2:
>
> internal clients -> argus -> external servers
>
> TcpRtt looks reasonable, 10 - 30 msec for domestic hosts, 100 - 300  
> msec
> for hosts in the U.S. or EU.
>
> My guess is that argus reports RTT between argus host and dst host,  
> not
> src host and dst host.
>
> The router has two NICs, one (NIC 1) for the upstream and the other  
> (NIC
> 2) for DMZ and internal networks. The argus monitors NIC 2.
>
> -- 
> Tomoyuki Sakurai
>