| 1 |
27 |
unneback |
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
| 2 |
|
|
<html>
|
| 3 |
|
|
<head>
|
| 4 |
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
| 5 |
|
|
<meta name="GENERATOR" content="Mozilla/4.7 [en] (X11; I; Linux 2.2.14 ppc) [Netscape]">
|
| 6 |
|
|
</head>
|
| 7 |
|
|
<body>
|
| 8 |
|
|
|
| 9 |
|
|
<center>
|
| 10 |
|
|
<h1>
|
| 11 |
|
|
eCos TCP/IP Networking Tests and Examples</h1></center>
|
| 12 |
|
|
A number of test/example programs are currently provided with the TCP/IP
|
| 13 |
|
|
networking package. These are not "tests" in the traditional eCos
|
| 14 |
|
|
test suite sense, but rather simple programs which exercise various parts
|
| 15 |
|
|
of the networking stack. Also included are a set of performance tests,
|
| 16 |
|
|
used to measure throughput and latency in an embedded eCos system.
|
| 17 |
|
|
<p>The following paragraphs list the various tests and how they might be
|
| 18 |
|
|
used. They are enumerated in the order in which they should
|
| 19 |
|
|
be run to verify a system configuration.
|
| 20 |
|
|
<p>Note: none of these tests are built by default. The user must
|
| 21 |
|
|
enable the <b><tt>CYGPKG_NET_BUILD_TESTS </tt></b>option and then "<tt>make
|
| 22 |
|
|
tests</tt>" to create them for the target environment. Also, these
|
| 23 |
|
|
tests require that the hardware interfaces be configured to use either
|
| 24 |
|
|
BOOTP or static initialization methods.
|
| 25 |
|
|
<h3>
|
| 26 |
|
|
mbuf_test.c</h3>
|
| 27 |
|
|
This should be the first test run on a new system. It simply tests
|
| 28 |
|
|
that the networking system can be initialized and that the internal memory
|
| 29 |
|
|
management (used by the stack) is functioning.
|
| 30 |
|
|
<h3>
|
| 31 |
|
|
socket_test.c</h3>
|
| 32 |
|
|
This test exercises some of the basic library interfaces.
|
| 33 |
|
|
<h3>
|
| 34 |
|
|
server_test.c</h3>
|
| 35 |
|
|
This test creates a server process on the target hardware which listens
|
| 36 |
|
|
on port TCP/7734. To verify that it is working, try to connect to
|
| 37 |
|
|
this port from some other [host] system. E.g. on Linux, use the command
|
| 38 |
|
|
"<tt>telnet <i>eCos</i> 7734</tt>", where "<i><tt>eCos</tt></i>" is the
|
| 39 |
|
|
name associated with the target hardware. Once connected, the eCos
|
| 40 |
|
|
application will respond with a "Hello" message and wait for a single line
|
| 41 |
|
|
of input text, which will be displayed on the diagnostic channel of the
|
| 42 |
|
|
target system.
|
| 43 |
|
|
<h3>
|
| 44 |
|
|
ping_test.c</h3>
|
| 45 |
|
|
This tests attempts to issue an ICMP "echo" request to the "server" host
|
| 46 |
|
|
(provided as part of the BOOTP or static configuration information).
|
| 47 |
|
|
The output will be similar to the analogous Linux program, "<tt>ping</tt>".
|
| 48 |
|
|
The test program also attempts to ping an additional host whose IP address
|
| 49 |
|
|
is the server IP+32. This second test is present to verify that the
|
| 50 |
|
|
ICMP (actually <tt>receive</tt>) time-out mechanism is working (assuming
|
| 51 |
|
|
that the second host is non-existent).
|
| 52 |
|
|
<h3>
|
| 53 |
|
|
ftp_test.c</h3>
|
| 54 |
|
|
This test attempts to make a connection to an FTP server, assuming the
|
| 55 |
|
|
default server host. This is an additional test which verifies that
|
| 56 |
|
|
the basic TCP functionality is working.
|
| 57 |
|
|
<h3>
|
| 58 |
|
|
nc_test_master.c</h3>
|
| 59 |
|
|
|
| 60 |
|
|
<h3>
|
| 61 |
|
|
nc_test_slave.c</h3>
|
| 62 |
|
|
This pair of programs can be used to measure throughput and latencies in
|
| 63 |
|
|
the target system. While both programs have been written in such
|
| 64 |
|
|
a way that they can be built and used on either Linux or eCos, the primary
|
| 65 |
|
|
use will be to run the "<tt>nc_test_master</tt>" program on a Linux host
|
| 66 |
|
|
and the "<tt>nc_test_slave</tt>" on the target hardware. If run in
|
| 67 |
|
|
this configuration, the master program will attempt to connect to the slave
|
| 68 |
|
|
and make various measurements using both UDP and TCP protocols. Additionally,
|
| 69 |
|
|
measurements will be made on an eCos slave of the actual CPU utilization
|
| 70 |
|
|
by the networking stack.
|
| 71 |
|
|
<p>To build the Linux versions, simply execute (in the eCos source tree,
|
| 72 |
|
|
not the install tree):
|
| 73 |
|
|
<blockquote><tt>make -f make.linux</tt></blockquote>
|
| 74 |
|
|
|
| 75 |
|
|
<h3>
|
| 76 |
|
|
tcp_echo.c</h3>
|
| 77 |
|
|
|
| 78 |
|
|
<h3>
|
| 79 |
|
|
tcp_sink.c</h3>
|
| 80 |
|
|
|
| 81 |
|
|
<h3>
|
| 82 |
|
|
tcp_source.c</h3>
|
| 83 |
|
|
This set of programs is similar to the <i><tt>nc_test_XXX</tt></i> programs
|
| 84 |
|
|
described above. However, they are designed to measure overall throughput
|
| 85 |
|
|
of the eCos system. The setup allows for one Linux host to run "<tt>tcp_source
|
| 86 |
|
|
<i>eCos</i></tt>" and another Linux host to run "<tt>tcp_sink <i>eCos</i></tt>".
|
| 87 |
|
|
The "<tt>tcp_echo</tt>" program is run on the target hardware. The
|
| 88 |
|
|
tests then measure the throughput and latency of sending TCP data from
|
| 89 |
|
|
one host, though the eCos target system and on to another host. Note:
|
| 90 |
|
|
the two Linux host systems may be the same computer in which case this
|
| 91 |
|
|
becomes a single wire echo test. This test suite is unique in that
|
| 92 |
|
|
it attempts to load the target system down with additional background processing
|
| 93 |
|
|
at various levels. This is done to simulate a real world environment
|
| 94 |
|
|
where the networking is ancillary to the main processing on the target
|
| 95 |
|
|
system.
|
| 96 |
|
|
<br>
|
| 97 |
|
|
</body>
|
| 98 |
|
|
</html>
|
