ndt-users list created

[Peter Van Epp <>]

        Ah something more to add to my "when I have time" list :-). We 
intentionally run ndt without a specified interface because the machine is
multihomed and ndt will (mostly :-)) correctly respond to the interface the
request comes in on meaning one ndt server (and more importantly one machine) 
server multiple networks. I have noticed it doesn't seem to be able to tell 
link type most times but that will be because the public interface isn't the
first link (there are something like 6 interfaces on the box). Getting it to
figure out which interface it is using (which probably currently depends on
routing) and opening that interface would be a good thing (although perhaps
not easy or even not possible). 

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

On Wed, Sep 17, 2008 at 08:01:00AM -0500, Richard Carlson wrote:
> Hi Maurice;
> 
> The NDT server puts the interface into promiscuous mode and measures  
> the arrival time of packet-pairs.  The "unknown link type" message  
> indicates that this task is failing.  The typical reason for this is  
> because there are multiple NIC's installed and you are not using the  
> 1st interface in the list.
> 
> Run the '/sbin/ifconfig' command and determine the name of the  
> interface you are using (eth0 is the 1st interface).
> Then start the web100srv process with the '-iethx' option (where x is  
> the interface number).  If you are using the ndt start script from the  
> conf directory, then edit this file and add this option to the  
> WEB100SRV_OPTIONS line.
> 
> The other possible issue is that the web100srv is not running as root,  
> so it does not have permission to put the interface into promiscuous  
> mode.  Use the 'ps' command to verify the owner of the web100srv  
> process.
> 
> I just started the NPToolkit ISO image as a VMWare Fusion client on my  
> Mac and it properly reported the bottleneck line using the eth0  
> interface.
> 
> Rich
> On Sep 16, 2008, at 5:47 PM, Maurice Volaski wrote:
> 
> >I am using this program again, and I seem to always be getting some  
> >sort of "unknown link type" error, such as "unable to determine the  
> >bottleneck link type". OTOH, it does seem to be determining the  
> >duplex state properly.
> >
> >I'm now running our Gentoo NDT box with web100-patched kernel 2.6.26  
> >running on VMware 2 on my Mac running 10.5.5, all under gigabit. The  
> >user tools are 1.7 and NDT reports 5.5.4a in the applet.
> >
> >Here's some sample output
> >WEB100 Enabled Statistics:
> >Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> >checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
> >running 10s outbound test (client-to-server [C2S]) . . . . .  
> >655.54Mb/s
> >running 10s inbound test (server-to-client [S2C]) . . . . . .  
> >484.16Mb/s
> >
> >     ------  Client System Details  ------
> >OS data: Name = Mac OS X, Architecture = i386, Version = 10.4.11
> >Java data: Vendor = Apple Computer, Inc., Version = 1.5.0_13
> >
> >     ------  Web100 Detailed Analysis  ------
> >Interprocess communications failed, unknown link type.
> >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 = 0.95 msec; the Packet size =  
> >1448 Bytes; and
> >No packet loss - but packets arrived out-of-order 5.51% of the time
> >S2C throughput test: Packet queuing detected: 1.59%
> >This connection is receiver limited 6.11% of the time.
> >This connection is sender limited 92.80% of the time.
> >This connection is network limited 1.09% of the time.
> >
> >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: ON
> >RFC 1323 Window Scaling: OFF
> >
> >Server 'theradargun.aecom.yu.edu' 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
> >------------------------------------------------------------------------------
> >
> >WEB100 Kernel Variables:
> >Client: localhost/127.0.0.1
> >CurMSS: 1448
> >X_Rcvbuf: 33554432
> >X_Sndbuf: 33554432
> >AckPktsIn: 87561
> >AckPktsOut: 0
> >BytesRetrans: 0
> >CongAvoid: 0
> >CongestionOverCount: 0
> >CongestionSignals: 0
> >CountRTT: 79576
> >CurCwnd: 98464
> >CurRTO: 204
> >CurRwinRcvd: 65080
> >CurRwinSent: 6144
> >CurSsthresh: 2147483647
> >DSACKDups: 0
> >DataBytesIn: 0
> >DataBytesOut: 606684560
> >DataPktsIn: 0
> >DataPktsOut: 418134
> >DupAcksIn: 4828
> >ECNEnabled: 0
> >FastRetran: 0
> >MaxCwnd: 98464
> >MaxMSS: 1448
> >MaxRTO: 216
> >MaxRTT: 72
> >MaxRwinRcvd: 65535
> >MaxRwinSent: 6144
> >MaxSsthresh: 0
> >MinMSS: 1448
> >MinRTO: 204
> >MinRTT: 0
> >MinRwinRcvd: 8648
> >MinRwinSent: 5792
> >NagleEnabled: 1
> >OtherReductions: 0
> >PktsIn: 87561
> >PktsOut: 418134
> >PktsRetrans: 0
> >RcvWinScale: 9
> >SACKEnabled: 3
> >SACKsRcvd: 0
> >SendStall: 0
> >SlowStart: 66
> >SampleRTT: 0
> >SmoothedRTT: 4
> >SndWinScale: 0
> >SndLimTimeRwin: 612037
> >SndLimTimeCwnd: 109523
> >SndLimTimeSender: 9297644
> >SndLimTransRwin: 19242
> >SndLimTransCwnd: 9
> >SndLimTransSender: 19252
> >SndLimBytesRwin: 471048792
> >SndLimBytesCwnd: 271608
> >SndLimBytesSender: 135364160
> >SubsequentTimeouts: 0
> >SumRTT: 75384
> >Timeouts: 0
> >TimestampsEnabled: 1
> >WinScaleRcvd: 0
> >WinScaleSent: 9
> >DupAcksOut: 0
> >StartTimeUsec: 553581
> >Duration: 10019463
> >c2sData: -1
> >c2sAck: -1
> >s2cData: -1
> >s2cAck: -1
> >half_duplex: 0
> >link: 100
> >congestion: 0
> >bad_cable: 0
> >mismatch: 0
> >spd: 484.42
> >bw: 11661.69
> >loss: 0.000001000
> >avgrtt: 0.95
> >waitsec: 0.00
> >timesec: 10.00
> >order: 0.0551
> >rwintime: 0.0611
> >sendtime: 0.9280
> >cwndtime: 0.0109
> >rwin: 0.5000
> >swin: 256.0000
> >cwin: 0.7512
> >rttsec: 0.000947
> >Sndbuf: 33554432
> >aspd: 0.00000
> >CWND-Limited: 170.82
> >minCWNDpeak: -1
> >maxCWNDpeak: -1
> >CWNDpeaks: -1
> >
> >The theoretical network limit is 11661.69 Mbps
> >The NDT server has a 16384.0 KByte buffer which limits the  
> >throughput to 270327.34 Mbps
> >Your PC/Workstation has a 63.0 KByte buffer which limits the  
> >throughput to 527.98 Mbps
> >The network based flow control limits the throughput to 793.24 Mbps
> >
> >Client Data reports link is 'System Fault', Client Acks report link  
> >is 'System Fault'
> >Server Data reports link is 'System Fault', Server Acks report link  
> >is 'System Fault'
> >-- 
> >
> >Maurice Volaski, 
> >
> >Computing Support, Rose F. Kennedy Center
> >Albert Einstein College of Medicine of Yeshiva University
> 
> Richard Carlson
> 
> 1000 Oakbrook Dr
> Ann Arbor, MI  48194
> 
> P: 734-352-7043
> C: 630-251-4572