Skip to Content.
Sympa Menu

ndt-users - Re: the indeterminate link type

Subject: ndt-users list created

List archive

Re: the indeterminate link type


Chronological Thread 
  • From: Richard Carlson <>
  • To: Peter Van Epp <>
  • Cc:
  • Subject: Re: the indeterminate link type
  • Date: Wed, 17 Sep 2008 12:53:24 -0500
Hi Peter;

OK, thanks. I'll put this on my to-do list for future upgrades. Unless someone else wants to supply the community with a patch .-)

Rich

On Sep 17, 2008, at 10:44 AM, Peter Van Epp wrote:

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

Richard Carlson

1000 Oakbrook Dr
Ann Arbor, MI 48194

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


Archive powered by MHonArc 2.6.16.

Top of Page