Chinaunix首页 | 论坛 | 博客
  • 博客访问: 157755
  • 博文数量: 64
  • 博客积分: 2545
  • 博客等级: 少校
  • 技术积分: 692
  • 用 户 组: 普通用户
  • 注册时间: 2006-11-22 20:00
文章分类

全部博文(64)

文章存档

2011年(3)

2009年(51)

2008年(10)

我的朋友

分类:

2009-09-10 22:34:03

tcptrace RTT caltulation

From:
Date: 11/14/02

  • Next message:
    • Previous message:
    • In reply to:
    • Messages sorted by:

    Date: Thu, 14 Nov 2002 07:38:56 +0100
    Subject: Re: tcptrace RTT caltulation
    Message-ID: <20021114063856.GA26780@pusa.informat.uv.es>
    From: 
    
    

    On Wed, Nov 13, 2002 at 06:36:37PM -0500, Liangping Ma wrote:
    > Hi, Ulisses,
    >
    > The second scenario is not reasonable. When you use tcptrace, you should
    > take special care of that. In my previous experiments, I got zero RTTs
    > because I put the monitor in a mistaken place (in your case the receiving
    > end), as in the second scenario.

    The second scenario is reasonable because a TCP connection is full duplex
    and a receibe host is also a sender :-)

    I think this should be documented somehere, I will post a
    README.rtt_measurement to the mantainer when this thread ends

            Ulisses

    >
    > Liangping Ma
    >
    > On Wed, 13 Nov 2002 wrote:
    >
    > > On Wed, Nov 13, 2002 at 12:39:57PM -0500, Liangping Ma wrote:
    > > > Hi, Ulisses,
    > > >
    > > > I did TCP RTT measurement before. Based on my memory, the tcptrace
    > > > processes tcpdump raw data, which can be collected in a local ethernet.
    > > > You are right, that the measurement may not be on one of the end points
    > > > of a TCP conneciton. But the delay within a LAN is trivial in the case of
    > > > a long-haul TCP connection. Thus the measurement can be reasonably
    > > > accurate.
    > >
    > >
    > > Ok, imagine the following two scenarios
    > >
    > >
    > >
    > > |
    > > |
    > > [Host A] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [Host B]
    > > ((((((((((((((((((((((((((<<<<<<<<<<<<<<<<<<<<<<<<<<<
    > >
    > >
    > >
    > >
    > > |
    > > |
    > > [Host A] ))))))))))))))))))))))))))))))))))))))))))))))))))))> [Host B]
    > > ((((((((((((((((((((((((((((((((((((((((((((((((((((<
    > >
    > >
    > >
    > > If I'm right RTT meassured values differ their meaning _a lot_ depeding
    > > where the monitorization host is
    > >
    > >
    > > Am I right?
    > >
    > >
    > > Thanks in advance
    > >
    > >
    > > Ulisses
    > >
    > >
    > > >
    > > >
    > > > Liangping
    > > >
    > > > On Wed, 13 Nov 2002 wrote:
    > > >
    > > > >
    > > > > I have read rexmit.c:rtt_ackin() and I belive that RTT meassurement is the
    > > > > following:
    > > > >
    > > > >
    > > > >
    > > > > |
    > > > > |
    > > > > [Host A] ))))))))))))))))))))))))))>>>>>>>>>>>>>>>>>>>>>>>>>>> [Host B]
    > > > > ((((((((((((((((((((((((((<<<<<<<<<<<<<<<<<<<<<<<<<<<
    > > > >
    > > > >
    > > > > ")" or ">" is the data segment
    > > > >
    > > > > "(" or "<" is the ACK segment for the corresponding data segment
    > > > >
    > > > >
    > > > > Where the time meassured for RTT is the time that is the sum of ">" and "<"
    > > > >
    > > > > I suposse here the monitorization is being done in the "middle" of the connection
    > > > >
    > > > >
    > > > > That is, tcptrace's RTT is not like the RTT meassured in the "ping" utility,
    > > > > in other words is not a "two full way transmision" meassurement
    > > > >
    > > > >
    > > > >
    > > > >
    > > > > Thanks in advance
    > > > >
    > > > >
    > > > > Ulisses
    > > > >
    > > > >
    > > > > Debian GNU/Linux: a dream come true
    > > > > -----------------------------------------------------------------------------
    > > > > "Computers are useless. They can only give answers." Pablo Picasso
    > > > >
    > > > > ---> Visita para saber acerca de la <---
    > > > > ---> Asociaci髇 Valenciana de Usuarios de Linux <---
    > > > >
    > > > > ----------------------------------------------------------------------------
    > > > > To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
    > > > > majordomo@tcptrace.org.
    > > > >
    > > >
    > >
    > > --
    > > Debian GNU/Linux: a dream come true
    > > -----------------------------------------------------------------------------
    > > "Computers are useless. They can only give answers." Pablo Picasso
    > >
    > > ---> Visita para saber acerca de la <---
    > > ---> Asociaci髇 Valenciana de Usuarios de Linux <---
    > >
    > > ----------------------------------------------------------------------------
    > > To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
    > > majordomo@tcptrace.org.
    > >
    >

    -- 
                    Debian GNU/Linux: a dream come true
    -----------------------------------------------------------------------------
    "Computers are useless. They can only give answers."            Pablo Picasso
    

    ---> Visita para saber acerca de la <--- ---> Asociaci髇 Valenciana de Usuarios de Linux <--- ---------------------------------------------------------------------------- To unsubscribe, send a message with body containing "unsubscribe tcptrace" to majordomo@tcptrace.org.

  • 阅读(523) | 评论(0) | 转发(0) |
    给主人留下些什么吧!~~