ndt-users list created

[Peter Van Epp <>]

        Ah! Thanks, then we won't go looking for why its so long :-).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada


On Thu, Aug 24, 2006 at 06:36:40PM -0400, Richard Carlson wrote:
> Peter;
> 
> The NDT server usually reports much longer RTT's that tools like 
> ping.  This is due to the server pumping data into the NIC faster than the 
> NIC can send it out on the wire.  This results in a standing output queue 
> on the server.  TCP measures the RTT from the time it passes a packet down 
> to the IP layer until it receives an ACK for that packet (assuming that no 
> loss occurred in that time window).  So you are seeing 48 msec of buffer or 
> ~600 KB of data sitting in output buffers waiting to get onto the wire.
> 
> Rich
> 
> At 05:28 PM 8/24/2006, Peter Van Epp wrote:
> >        We are seeing a long rtt reported on 5.4.8. The rtt shouldn't be
> >anywhere near 49 Msec, it should be closer to 1.
> >
> >ping -c 100 -s 1452 sniffer1.ucs.sfu.ca
> >PING sniffer1.ucs.sfu.ca (142.58.200.253): 1452 data bytes
> >1460 bytes from 142.58.200.253: icmp_seq=0 ttl=62 time=1.057 ms
> >1460 bytes from 142.58.200.253: icmp_seq=1 ttl=62 time=0.999 ms
> >1460 bytes from 142.58.200.253: icmp_seq=2 ttl=62 time=1.008 ms
> >...
> >--- sniffer1.ucs.sfu.ca ping statistics ---
> >100 packets transmitted, 100 packets received, 0% packet loss
> >round-trip min/avg/max = 0.976/1.417/34.343 ms
> >
> >
> >WEB100 Enabled Statistics:
> >Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> >checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
> >running 10s outbound test (client-to-server [C2S]) . . . . . 90.25Mb/s
> >running 10s inbound test (server-to-client [S2C]) . . . . . . 87.67Mb/s
> >
> >        ------  Client System Details  ------
> >OS data: Name = Mac OS X, Architecture = ppc, Version = 10.3.9
> >Java data: Vendor = Apple Computer, Inc., Version = 1.4.2_09
> >
> >        ------  Web100 Detailed Analysis  ------
> >100 Mbps FastEthernet link found.
> >Link set to Full Duplex mode
> >No network congestion discovered.
> >Good network cable(s) found
> >Normal duplex operation found.
> >
> >Web100 reports the Round trip time = 49.48 msec; the Packet size = 1460 
> >Bytes; and
> >No packet loss - but packets arrived out-of-order 0.08% of the time
> >C2S throughput test: Packet queuing detected: 0.19%
> >S2C throughput test: Packet queuing detected: 8.21%
> >This connection is sender limited 100.0% of the time.
> >
> >Web100 reports TCP negotiated the optional Performance Settings to:
> >RFC 2018 Selective Acknowledgment: OFF
> >RFC 896 Nagle Algorithm: OFF
> >RFC 3168 Explicit Congestion Notification: OFF
> >RFC 1323 Time Stamping: OFF
> >RFC 1323 Window Scaling: OFF
> >
> >Server 'sniffer1.ucs.sfu.ca' is not behind a firewall. [Connection to the 
> >ephemeral port was successful]
> >Client is probably behind a firewall. [Connection to the ephemeral port 
> >failed]
> >Information: Network Middlebox is modifying MSS variable
> >Server IP addresses are preserved End-to-End
> >Client IP addresses are preserved End-to-End
> >
> >Peter Van Epp / Operations and Technical Support
> >Simon Fraser University, Burnaby, B.C. Canada
> 
> ------------------------------------
> 
> 
> 
> Richard A. Carlson                              e-mail: 
> 
> Network Engineer                                phone:  (734) 352-7043
> Internet2                                       fax:    (734) 913-4255
> 1000 Oakbrook Dr; Suite 300
> Ann Arbor,  MI  48104