ndt-users list created

[Peter Van Epp <>]

        You are correct we do seem to have thought that:

WEB100SRV_OPTIONS="-l/var/log/web100srv.log -a -4 -i eth4 -i eth5"

but it doesn't seem to be working anymore (we upgraded the OS and web100
versions a while back which may be why):

...
Server unable to determine bottleneck link type.
...

Statistics
...
     ------ Web100 Deailed Analysis ------
Interprocess communications failed, unknown link type.
...

Mode Details

...
Client Data reports link is "system fault", Client acks report link is 
"System fault" (and same for server).

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

On Wed, Sep 17, 2008 at 10:29:21AM -0500, Richard Carlson wrote:
> Hi Peter;
> 
> I thought you told me that you could specify multiple interfaces using  
> the '-iethx' option multiple times (-ieth0 -ieth1 ...).  I don't  
> recall if I tested this, but it may work.
> 
> Rich
> 
> On Sep 17, 2008, at 10:09 AM, Peter Van Epp wrote:
> 
> >     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
> 
> Richard Carlson
> 
> 1000 Oakbrook Dr
> Ann Arbor, MI  48194
> 
> P: 734-352-7043
> C: 630-251-4572