ndt-users list created

["John Heffner" <>]

This is not too hard actually.  Do getsockname() on the socket to get
the local address.  Then you can use ioctl(SIOCGIFCONF) to get
addresses of interfaces and match the address.

  -John


On Wed, Sep 17, 2008 at 11: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
>