NDT (Network Diagnostic Tool)
NDT can be used to check the TCP configuration of any host that can run Java applets. The client connects to a Web page containing a special applet. The Web server that serves the applet must run a kernel with the Web100
extensions for TCP measurement instrumentation. The applet performs TCP memory-to-memory tests between the client and the Web100-instrumented server, and then uses the measurements from the Web100 instrumentation to find out about the TCP configuration of the client. NDT also detects common configuration errors such as duplex mismatch
Besides the applet, there is also a command-line client called
that can be used without a browser. The client works on Linux without any need for Web100 extensions, and can be compiled on other Unix systems as well. It doesn't require a Web server on the server side, just the NDT server
- which requires a Web100
Since NDT performs memory-to-memory tests, it avoids end-system bottlenecks such as file system or disk limitations. Therefore it is useful for estimating "pure" TCP throughput limitations for a system, better than, for instance, measuring the throughput of a large file retrieval from a public FTP or WWW server. In addition, NDT servers are supposed to be well-connected and lightly loaded.
When trying to tune a host for maximum throughput, it is a good idea to start testing it against an NDT server that is known to be relatively close to the host in question. Once the throughput with this server is satisfactory, one can try to further tune the host's TCP against a more distant NDT server. Several European NRENs as well as many sites in the U.S. operate NDT servers.
This example shows the results (overview) of an NDT measurement between a client in Switzerland (Gigabit Ethernet connection) and an IPv6 NDT server in Ljubljana, Slovenia (Gigabit Ethernet connection).
The following is an example run of the
command-line client application. In this case, the client runs on a small Linux-based home router connected to a commercial broadband-over-cable Internet connection. The connection is marketed as "5000 kb/s downstream, 500 kb/s upstream", and it can be seen that this nominal bandwidth can in fact be achieved for an individual TCP connection.
$ ./web100clt -n ndt.switch.ch
Testing network path for configuration and performance problems -- Using IPv6 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 509.00 kb/s
running 10s inbound test (server to client) . . . . . . 5.07 Mb/s
Your host is connected to a Cable/DSL modem
Information [C2S]: Excessive packet queuing detected: 10.18% (local buffers)
Information [S2C]: Excessive packet queuing detected: 73.20% (local buffers)
Server 'ndt.switch.ch' 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 (changed to 1440)
Server IP addresses are preserved End-to-End
Client IP addresses are preserved End-to-End
Note the remark "-- Using IPv6 address". The example used the new version 3.3.12 of the NDT software, which includes support for both IPv4 and IPv6. Because both the client and the server support IPv6, the test is run over IPv6. To run an IPv4 test in this situation, one could have called the client with the
option, i.e. web100clt -4 -n ndt.switch.ch
There are many public NDT server installations available on the Web. You should choose between the servers according to distance (in terms of RTT
) and the throughput range you are interested in. The limits of your local connectivity can best be tested by connecting to a server with a fast(er) connection that is close by. If you want to tune your TCP parameters for "LFNs"
, use a server that is far away from you, but still reachable over a path without bottlenecks.
Development of NDT is now hosted on Google Code,
and as of July 2011 there is some activity. Notably, there is now documentation about the architecture
as well as the detailed protocol
or NDT. One of the stated goals is to allow outside parties to write compatible NDT clients without consulting the NDT source code
- NDT: Desktop Troubleshooting for All Users, Internet2 End-to-End Performance Initiative, 2005, http://e2epi.internet2.edu/ndt/overview.pdf
- Network Diagnostic Tool (NDT): An Internet2 Cookbook, Internet2 End-to-End Performance Initiative, 2005, http://e2epi.internet2.edu/network-perf-wk/ndt-cookbook.pdf
- http://e2epi.internet2.edu/ndt/ - NDT Web page at the Internet2 end-to-end performance initiative (e2epi)
- http://e2epi.internet2.edu/ndt/download.html - NDT download site
- https://mail.internet2.edu/wws/arc/ndt-announce/ -
ndt-announce mailing list archive
- https://mail.internet2.edu/wws/arc/ndt-users/ -
ndt-users mailing list archive
- Using the Network Diagnostic Tester, G. Shaffer, September 2006, Computerworld, http://www.techworld.com/networking/features/index.cfm?featureID=2787&pagtype=all
- http://code.google.com/p/ndt/ - NDT development site on Google Code hosting
- Network Diagnostic Tool Protocol (NDTP) - Wiki page/work in progress, started in July 2011
- 30 Jun 2005 - 22 Nov 2011