ndt-users list created

[Richard Carlson <>]

Hi Maurice;

OK, that's a different problem.  Most Gigabit NICs use interrupt  
coalescing to reduce the CPU overhead.  This means that packets arrive  
at the stack in bunches instead as they arrive.  This causes the pkt- 
pair timing routine to fail.  One option is to turn interrupt  
coalescing off using the "/sbin/ethtool -C ethx rx-frames 1" command  
(or whatever the name of your interface is).  In the VM world, you may  
need to do this on the real NIC instead of the VM-clients NIC.

I do have this listed as a know bug and I'm looking for ways to fix  
it, I also have an idea for a second link detection algorithm that may  
also help.  Hopefully something will be out by the end of the year.

RIch

On Sep 17, 2008, at 12:44 PM, Maurice Volaski wrote:

> > 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
>
> Thanks, that fixes the unknown problem, but it still doesn't quite  
> report ordinary gigabit, but "2.4 Gbps OC-48" instead. In the  
> statistics, the result is more complex, the client report OC-48, the  
> server and client "acks" report OC-12 and the server "acks" report  
> 10 Gig.
>
>
> WEB100 Enabled Statistics:
> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
> running 10s outbound test (client-to-server [C2S]) . . . . .  
> 373.36Mb/s
> running 10s inbound test (server-to-client [S2C]) . . . . . .  
> 419.60Mb/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  ------
> 2.4 Gbps OC-48 link found.
> 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.87 msec; the Packet size =  
> 1448 Bytes; and
> No packet loss - but packets arrived out-of-order 4.34% of the time
> S2C throughput test: Packet queuing detected: 0.10%
> This connection is receiver limited 4.32% of the time.
>  Increasing the the client's receive buffer (63.0 KB) will improve  
> performance
> This connection is sender limited 94.21% of the time.
> This connection is network limited 1.47% 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: 74954
> AckPktsOut: 0
> BytesRetrans: 0
> CongAvoid: 0
> CongestionOverCount: 0
> CongestionSignals: 0
> CountRTT: 68278
> CurCwnd: 99912
> CurRTO: 204
> CurRwinRcvd: 65535
> CurRwinSent: 6144
> CurSsthresh: 2147483647
> DSACKDups: 0
> DataBytesIn: 0
> DataBytesOut: 526888512
> DataPktsIn: 0
> DataPktsOut: 365616
> DupAcksIn: 3255
> ECNEnabled: 0
> FastRetran: 0
> MaxCwnd: 99912
> MaxMSS: 1448
> MaxRTO: 216
> MaxRTT: 92
> MaxRwinRcvd: 65535
> MaxRwinSent: 6144
> MaxSsthresh: 0
> MinMSS: 1448
> MinRTO: 204
> MinRTT: 0
> MinRwinRcvd: 8648
> MinRwinSent: 5792
> NagleEnabled: 1
> OtherReductions: 0
> PktsIn: 74954
> PktsOut: 365616
> PktsRetrans: 0
> RcvWinScale: 9
> SACKEnabled: 3
> SACKsRcvd: 0
> SendStall: 0
> SlowStart: 67
> SampleRTT: 0
> SmoothedRTT: 4
> SndWinScale: 0
> SndLimTimeRwin: 432412
> SndLimTimeCwnd: 147750
> SndLimTimeSender: 9440825
> SndLimTransRwin: 8813
> SndLimTransCwnd: 11
> SndLimTransSender: 8825
> SndLimBytesRwin: 215916064
> SndLimBytesCwnd: 272960
> SndLimBytesSender: 310699488
> SubsequentTimeouts: 0
> SumRTT: 59448
> Timeouts: 0
> TimestampsEnabled: 1
> WinScaleRcvd: 0
> WinScaleSent: 9
> DupAcksOut: 0
> StartTimeUsec: 114657
> Duration: 10028744
> c2sData: 8
> c2sAck: 6
> s2cData: 6
> s2cAck: 9
> half_duplex: 0
> link: 100
> congestion: 0
> bad_cable: 0
> mismatch: 0
> spd: 420.63
> bw: 1268826.32
> loss: 0.000000000
> avgrtt: 0.87
> waitsec: 0.00
> timesec: 10.00
> order: 0.0434
> rwintime: 0.0432
> sendtime: 0.9421
> cwndtime: 0.0147
> rwin: 0.5000
> swin: 256.0000
> cwin: 0.7623
> rttsec: 0.000871
> Sndbuf: 33554432
> aspd: 0.00000
> CWND-Limited: 171.84
> minCWNDpeak: -1
> maxCWNDpeak: -1
> CWNDpeaks: -1
>
> The theoretical network limit is 1268826.32 Mbps
> The NDT server has a 16384.0 KByte buffer which limits the  
> throughput to 293915.04 Mbps
> Your PC/Workstation has a 63.0 KByte buffer which limits the  
> throughput to 574.05 Mbps
> The network based flow control limits the throughput to 875.20 Mbps
>
> Client Data reports link is 'OC-48', Client Acks report link is  
> 'OC-12'
> Server Data reports link is 'OC-12', Server Acks report link is '10  
> Gig'
>
> --
>
> 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