ndt-users list created

[Richard Carlson <>]

Hi Clarke;

The web100 kernel patches contain a set of variables to track where  
the sending TCP (the web100 server in this case) is spending it's  
time.  From the RFC-4898 paper

   tcpEStatsPerfSndLimTimeRwin  OBJECT-TYPE
       SYNTAX          ZeroBasedCounter32
       UNITS           "milliseconds"
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
          "The cumulative time spent in the 'Receiver Limited' state.
           See tcpEStatsPerfSndLimTransRwin."
       ::= { tcpEStatsPerfEntry 34 }

   tcpEStatsPerfSndLimTimeCwnd  OBJECT-TYPE
       SYNTAX          ZeroBasedCounter32
       UNITS           "milliseconds"
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
          "The cumulative time spent in the 'Congestion Limited'
           state.  See tcpEStatsPerfSndLimTransCwnd.  When there is a
           retransmission timeout, it SHOULD be counted in
           tcpEStatsPerfSndLimTimeCwnd (and not the cumulative time
           for some other state.)"
       ::= { tcpEStatsPerfEntry 35 }

   tcpEStatsPerfSndLimTimeSnd  OBJECT-TYPE
       SYNTAX          ZeroBasedCounter32
       UNITS           "milliseconds"
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
          "The cumulative time spent in the 'Sender Limited' state.
           See tcpEStatsPerfSndLimTransSnd."
       ::= { tcpEStatsPerfEntry 36 }

The NDT server extracts these variables and calculates the % of time  
in each state (you can see the time, bytes transfered, and transition  
count in the data below).

The test results below indicate that your server may have memory or  
CPU constraints that will impact the test results.  The web100 data  
shows that this server has data to send (in the sender ready state)  
but it can't push this data down to the NIC.  Most likely the CPU is  
busy handling other processes/interrupts.  You can enable the -- 
cputime flag and it will track/report the CPU utilization numbers so  
you don't need to sit at a console running top or something like that  
to check the CPU util numbers.

While it is true that they haven't impacted this test, it may become  
an issue if you (1) want to run at gigabit rates; or (2) run 100 Mbps  
tests to remote clients.

Regards;
Rich

On Oct 22, 2009, at 3:58 PM, Clarke Morledge wrote:

> I need some help decoding the "This connection is sender limited x%  
> of the time", particularly when the value of x is greater than 80%.
>
> What does the statement actually mean, and what are some potential  
> troubleshooting remedies?
>
> In this case, I am using NDT v.5.5.4a.
>
> I am including the statistics output of a test below, where this  
> example is sender limited 88.14% of the time....
>
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
>
> -------------------------------------------------------
>
> checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
> running 10s outbound test (client-to-server [C2S]) . . . . . 93.43Mb/s
> running 10s inbound test (server-to-client [S2C]) . . . . . .  
> 93.04Mb/s
> Client: localhost/127.0.0.1
> CurMSS: 1448
> X_Rcvbuf: 33554432
> X_Sndbuf: 33554432
> AckPktsIn: 45541
> AckPktsOut: 0
> BytesRetrans: 0
> CongAvoid: 0
> CongestionOverCount: 0
> CongestionSignals: 0
> CountRTT: 45542
> CurCwnd: 99912
> CurRTO: 205
> CurRwinRcvd: 63712
> CurRwinSent: 6144
> CurSsthresh: 2147483647
> DSACKDups: 0
> DataBytesIn: 0
> DataBytesOut: 120854968
> DataPktsIn: 0
> DataPktsOut: 83303
> DupAcksIn: 0
> ECNEnabled: 0
> FastRetran: 0
> MaxCwnd: 99912
> MaxMSS: 1448
> MaxRTO: 207
> MaxRTT: 9
> MaxRwinRcvd: 66608
> MaxRwinSent: 6144
> MaxSsthresh: 0
> MinMSS: 1428
> MinRTO: 201
> MinRTT: 1
> MinRwinRcvd: 55024
> MinRwinSent: 5792
> NagleEnabled: 1
> OtherReductions: 0
> PktsIn: 45541
> PktsOut: 83303
> PktsRetrans: 0
> RcvWinScale: 10
> SACKEnabled: 3
> SACKsRcvd: 0
> SendStall: 0
> SlowStart: 66
> SampleRTT: 4
> SmoothedRTT: 5
> SndWinScale: 1
> SndLimTimeRwin: 1223997
> SndLimTimeCwnd: 5595
> SndLimTimeSender: 9140777
> SndLimTransRwin: 3624
> SndLimTransCwnd: 10
> SndLimTransSender: 3634
> SndLimBytesRwin: 86086656
> SndLimBytesCwnd: 123528
> SndLimBytesSender: 34644784
> SubsequentTimeouts: 0
> SumRTT: 214553
> Timeouts: 0
> TimestampsEnabled: 1
> WinScaleRcvd: 1
> WinScaleSent: 10
> DupAcksOut: 0
> StartTimeUsec: 411289
> Duration: 10370730
> c2sData: 5
> c2sAck: 5
> s2cData: 5
> s2cAck: 5
> half_duplex: 0
> link: 100
> congestion: 0
> bad_cable: 0
> mismatch: 0
> spd: 93.23
> bw: 2344.96
> loss: 0.000001000
> avgrtt: 4.71
> waitsec: 0.00
> timesec: 10.00
> order: 0.0000
> rwintime: 0.1180
> sendtime: 0.8814
> cwndtime: 0.0005
> rwin: 0.5082
> swin: 256.0000
> cwin: 0.7623
> rttsec: 0.004711
> Sndbuf: 33554432
> aspd: 0.00000
> CWND-Limited: 22054.01
> minCWNDpeak: -1
> maxCWNDpeak: -1
> CWNDpeaks: -1
> The slowest link in the end-to-end path is a 100 Mbps Full duplex  
> Fast Ethernet subnet
>
> Web100 reports the Round trip time = 4.71 msec; the Packet size =  
> 1448 Bytes; and
> No packet loss was observed.
> This connection is receiver limited 11.79% of the time.
> This connection is sender limited 88.14% of the time.
> Server '128.239.22.8' is not behind a firewall. [Connection to the  
> ephemeral port was successful]
> Client is probably behind a firewall. [Connection to the ephemeral  
> port failed]
> The theoretical network limit is 2344.96 Mbps
> The NDT server has a 16384.0 KByte buffer which limits the  
> throughput to 54340.90 Mbps
> Your PC/Workstation has a 65.0 KByte buffer which limits the  
> throughput to 107.87 Mbps
> The network based flow control limits the throughput to 161.81 Mbps

Richard Carlson

1000 Oakbrook Dr
Ann Arbor, MI  48104

P: 734-352-7043
C: 630-251-4572