Skip to Content.
Sympa Menu

ndt-users - Re: My NDT just did not work

Subject: ndt-users list created

List archive

Re: My NDT just did not work


Chronological Thread 
  • From: "Ken Bellars" <>
  • To: "Richard Carlson" <>
  • Cc:
  • Subject: Re: My NDT just did not work
  • Date: Thu, 9 Nov 2006 13:47:24 +0100

Hey Rich,

I have upgraded the NDT server to 3.3.19.

Below is my result when try to do a test

================ TEST RESULT =================
click START to re-test
Connected to: "myserver"  --  Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client-to-server [C2S]) . . . . . 37.73Mb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 1.07Mb/s
The slowest link in the end-to-end path is a 100 Mbps Full duplex Fast Ethernet subnet
Information: Other network traffic is congesting the link
Information: [S2C]: Packet queuing detected


================ STATISTICS =================

WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client-to-server [C2S]) . . . . . 51.74Mb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 1.03Mb/s

    ------  Client System Details  ------
OS data: Name = Windows 2000, Architecture = x86, Version = 5.0
Java data: Vendor = Sun Microsystems Inc., Version = 1.6.0-beta2

    ------  Web100 Detailed Analysis  ------
100 Mbps FastEthernet link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 13.26 msec; the Packet size = 1460 Bytes; and
There were 123 packets retransmitted, 288 duplicate acks received, and 337 SACK blocks received
The connection stalled 22 times due to packet loss
The connection was idle 4.84 seconds (40.33%) of the time
C2S throughput test: Packet queuing detected: 0.08%
S2C throughput test: Packet queuing detected: 94.43%
This connection is sender limited 13.13% of the time.
This connection is network limited 86.86% of the time.
Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch

Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: ON

Server 'MYSERVER' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is not behind a firewall. [Connection to the ephemeral port was successful]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Client IP addresses are preserved End-to-End


================ MORE DETAILS =================
WEB100 Kernel Variables:
Client: localhost/127.0.0.1
CurMSS: 1460
X_Rcvbuf: 33554432
X_Sndbuf: 33554432
AckPktsIn: 773
AckPktsOut: 0
BytesRetrans: 179580
CongAvoid: 270
CongestionOverCount: 0
CongestionSignals: 82
CountRTT: 383
CurCwnd: 1460
CurRTO: 220
CurRwinRcvd: 100000
CurRwinSent: 6144
CurSsthresh: 2920
DSACKDups: 0
DataBytesIn: 0
DataBytesOut: 1802640
DataPktsIn: 0
DataPktsOut: 1218
DupAcksIn: 288
ECNEnabled: 0
FastRetran: 60
MaxCwnd: 13140
MaxMSS: 1460
MaxRTO: 364
MaxRTT: 216
MaxRwinRcvd: 100000
MaxRwinSent: 6144
MaxSsthresh: 5840
MinMSS: 1460
MinRTO: 204
MinRTT: 0
MinRwinRcvd: 90596
MinRwinSent: 5840
NagleEnabled: 1
OtherReductions: 0
PktsIn: 773
PktsOut: 1218
PktsRetrans: 123
RcvWinScale: 10
SACKEnabled: 3
SACKsRcvd: 337
SendStall: 0
SlowStart: 122
SampleRTT: 4
SmoothedRTT: 8
SndWinScale: 1
SndLimTimeRwin: 0
SndLimTimeCwnd: 11004506
SndLimTimeSender: 1664505
SndLimTransRwin: 0
SndLimTransCwnd: 1
SndLimTransSender: 1
SndLimBytesRwin: 0
SndLimBytesCwnd: 1802640
SndLimBytesSender: 0
SubsequentTimeouts: 0
SumRTT: 5080
Timeouts: 22
TimestampsEnabled: 0
WinScaleRcvd: 1
WinScaleSent: 10
DupAcksOut: 0
StartTimeUsec: 915639
Duration: 12669246
c2sData: 5
c2sAck: 5
s2cData: 6
s2cAck: 4
half_duplex: 0
link: 100
congestion: 1
bad_cable: 0
mismatch: 0
spd: 1.14
bw: 3.24
loss: 0.067323481
avgrtt: 13.26
waitsec: 4.84
timesec: 12.00
order: 0.3726
rwintime: 0.0000
sendtime: 0.1314
cwndtime: 0.8686
rwin: 0.7629
swin: 256.0000
cwin: 0.1003
rttsec: 0.013264
Sndbuf: 33554432
aspd: 0.00000
CWND-Limited: 9467.70

The theoretical network limit is 3.24 Mbps
The NDT server has a 16384.0 KByte buffer which limits the throughput to 19300.36 Mbps
Your PC/Workstation has a 97.0 KByte buffer which limits the throughput to 57.51 Mbps
The network based flow control limits the throughput to 7.56 Mbps

Client Data reports link is 'FastE', Client Acks report link is 'FastE'
Server Data reports link is 'OC-12', Server Acks report link is 'T3'


===========================================

Rich,

I will appreciate your response.

Regards
Kenny






On 10/20/06, Richard Carlson <> wrote:
Hi Kenny;

I've trimmed the email and have some comments below.

At 10:15 AM 10/17/2006, Ken Bellars wrote:
>Rich,
>
>Thanks so much for walking me through building my own NDT. The first
>suggestion actually fixed the problem.
>
>Now its running cool but I think there is still a problem (most likely the
>last.).
>
>My C2S speed is far greater than the S2C. See below.
>
>---------------------------------------------------------------------------------
>
>click START to re-test
>Connected to: <http://196.207.6.22>196.207.6.22  --  Using IPv4 address
>Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
>checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
>
>running 10s outbound test ( Client -to- Server [C2S] ) . . . . . 44.25Mb/s
>running 10s inbound test ( Server -to- Client [S2C] ) . . . . . . 1.48Mb/s

This is reporting that server is unable to fully utilize the
network.  Fortunately, the NDT "Statists" and "More Details" pages should
help explain why.  Look at these pages and send me a copy if you need help
interpreting the results.

>The slowest link in the end-to-end path is a 10 Gbps 10 Gigabit
>Ethernet/OC-192 subnet

The NDT server performs some raw packet timing calculations to determine
the bottleneck link capacity.  I suspect that you are using a new PC with a
1 GE NIC and that NIC is doing interrupt coalescing, handling multiple
receive packets on a single interrupt.  This means that the NDT is finding
out how fast the NIC can transfer packets across the memory bus, not across
the network.  Until I can fix this bug, turning interrupt coalescing off
should correct the problem (at the expense of more CPU utilization).

>Information: Other network traffic is congesting the link

This is probably a misleading message.  My plan is to update the congestion
detected signature in the next few months.

>[ S2C ]: Excessive packet queuing detected

This is saying that the server can send data to the NIC faster than the NIC
can push it out into the network.  This is typical for modern servers and
clients stuck behind slow links (DSL/Cable modem).  The word "Information"
in blue indicated that it is a hot-link that you can click on to get more
information.

Let us know what you find.

Rich
>click START to re-test
>
>---------------------------------------------------------------------------------
>
>[snip snip snip]

------------------------------------



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





Archive powered by MHonArc 2.6.16.

Top of Page