forked from mininet/mininet
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Manpage of NUTTCP.html
544 lines (423 loc) · 19.4 KB
/
Manpage of NUTTCP.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
<!-- saved from url=(0042)http://lcp.nrl.navy.mil/nuttcp/nuttcp.html -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>Content-type: text/html
<title>Manpage of NUTTCP</title>
<h1>NUTTCP</h1>
Section: Under Construction (8)<br>Updated: 3 February 2007<br><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#index">Index</a>
<a href="http://localhost/cgi-bin/man/man2html">Return to Main Contents</a><hr>
<a name="lbAB"> </a>
<h2>NAME</h2>
nuttcp - network performance measurement tool
<a name="lbAC"> </a>
<h2>SYNOPSIS</h2>
<b>nuttcp -h</b>
<br>
<b>nuttcp -V</b>
<br>
<b>nuttcp -t</b>
[ <b>-bdDsuv</b> ]
[ <b>-c </b><i>dscp_value</i> ]
[ <b>-l </b><i>buffer_len</i> ]
[ <b>-n </b><i>num_bufs</i> ]
<br>
<br>
[ <b>-w </b><i>window_size</i> ]
[ <b>-ws </b><i>server_window</i> ]
[ <b>-wb</b> ]
<br>
<br>
[ <b>-p </b><i>data_port</i> ]
[ <b>-P </b><i>control_port</i> ]
<br>
<br>
[ <b>-N </b><i>num_streams</i> ]
[ <b>-R </b><i>xmit_rate_limit</i> [m|g] ]
<br>
<br>
[ <b>-T </b><i>xmit_timeout</i> [m] ]
<i>host</i>
[
<b><</b>
<i>input</i>
]
<br>
<b>nuttcp -r</b>
[ <b>-bBdsuv</b> ]
[ <b>-c </b><i>dscp_value</i> ]
[ <b>-l </b><i>buffer_len</i> ]
[ <b>-n </b><i>num_bufs</i> ]
<br>
<br>
[ <b>-w </b><i>window_size</i> ]
[ <b>-ws </b><i>server_window</i> ]
[ <b>-wb</b> ]
<br>
<br>
[ <b>-p </b><i>data_port</i> ]
[ <b>-P </b><i>control_port</i> ]
<br>
<br>
[ <b>-N </b><i>num_streams</i> ]
[ <b>-R </b><i>xmit_rate_limit</i> [m|g] ]
<br>
<br>
[ <b>-T </b><i>xmit_timeout</i> [m] ]
[
<i>host</i>
]
[
<b>></b>
<i>output</i>
]
<br>
<b>nuttcp -S</b>
[ <b>-P </b><i>control_port</i> ]
<br>
<b>nuttcp -1</b>
[ <b>-P </b><i>control_port</i> ]
<a name="lbAD"> </a>
<h2>DESCRIPTION</h2>
nuttcp is a network performance measurement tool intended for use by
network and system managers. Its most basic usage is to determine the
raw TCP (or UDP) network layer throughput by transferring memory buffers
from a source system across an interconnecting network to a destination
system, either transferring data for a specified time interval, or
alternatively transferring a specified number of bytes. In addition
to reporting the achieved network throughput in Mbps, nuttcp also
provides additional useful information related to the data transfer
such as user, system, and wall-clock time, transmitter and receiver
CPU utilization, and loss percentage (for UDP transfers).
<p>
nuttcp is based on nttcp, which in turn was an enhancement by someone
at Silicon Graphics (SGI) on the original ttcp, which was written by
Mike Muuss at BRL sometime before December 1984, to compare the performance
of TCP stacks by U.C. Berkeley and BBN to help DARPA decide which version
to place in the first BSD Unix release. nuttcp has several useful features
beyond those of the basic ttcp/nttcp, such as a server mode, rate limiting,
multiple parallel streams, and timer based usage. More recent changes
include IPv6 support, IPv4 multicast, and the ability to set the maximum
segment size or TOS/DSCP bits. nuttcp is continuing to evolve to meet
new requirements that arise and to add desired new features. nuttcp has
been successfully built and run on a variety of Solaris, SGI, and
PPC/X86 Linux systems, and should probably work fine on most flavors
of Unix. It has also been used successfully on various versions of
the Windows operating system.
</p><p>
There are two basic modes of operation for nuttcp. The original or
classic mode is the transmitter/receiver mode, which is also the way
the original ttcp and nttcp worked. In this mode, a receiver is first
initiated on the destination host using "nuttcp -r", and then a
transmitter must be started on the source host using "nuttcp -t".
This mode is somewhat deprecated and is no longer recommended for
general use. The preferred and recommended mode of operation for
nuttcp is the new client/server mode. With this mode, a server is
first started on one system using "nuttcp -S" (or "nuttcp -1"),
and then a client may either transmit data to (using "nuttcp -t")
or receive data from (using "nuttcp -r") the server system. All
the information provided by nuttcp is reported by the client, including
the information from the server, thus providing a full snapshot of both
the transmitter and receiver ends of the data transfer.
</p><p>
The server may be started by a normal, non-privileged user by issuing
either a "nuttcp -S" or a "nuttcp -1" command. However, the optimal
and recommended method of running a server is to run "nuttcp -S" via
the inetd/xinetd daemon. This method has several significant advantages,
including being more robust, allowing multiple simultaneous connections,
and providing for access control over who is allowed to use the nuttcp
server via the hosts.allow (and hosts.deny) file. By default, the
nuttcp server listens for commands on port 5000, and the actual nuttcp
data transfers take place on port 5001.
</p><p>
The
<i>host</i>
parameter must be specified for the transmitter, and provides the
host name or IP address of the receiver. In classic transmitter/receiver
mode, the
<i>host</i>
parameter may not be specified for the receiver. In client/server mode,
when the client is the receiver, the
<i>host</i>
parameter specifies the host name or IP address of the transmitter
(server).
</p><p>
Normally, a nuttcp data transfer is memory-to-memory. However, by
using the "-s" option, it is possible to also perform memory-to-disk,
disk-to-memory, and disk-to-disk data transfers. Using the "-s" option
with the transmitter will cause nuttcp to read its data from the
standard input instead of using a prefabricated memory buffer,
while using the "-s" option on the receiver causes nuttcp to write
its data to standard output. All these types of data transfers are
possible with the classic transmitter/receiver mode. For security
reasons, the "-s" option is disabled on the server, so it is not
possible to access the disk on the server side of a data transfer.
</p><p>
The allowed options to nuttcp are:
<a name="lbAE"> </a>
</p><h2>OPTIONS</h2>
<dl compact="">
<dt><b>-h</b>
</dt><dd>
Print out a usage statement. Running nuttcp with no arguments will
also produce a usage statement.
</dd><dt><b>-V</b>
</dt><dd>
Prints the nuttcp version number. The nuttcp version is also printed
as part of the normal nuttcp output when the "-v" verbose output is
used (but not when using the default brief output). In client/server
mode, the version number of both the client and server is identified.
</dd><dt><b>-t</b>
</dt><dd>
Indicates that this nuttcp is the transmitter. In client/server mode,
this means the server specified by the
<i>host</i>
parameter is the receiver.
</dd><dt><b>-r</b>
</dt><dd>
Indicates that this nuttcp is the receiver. In client/server mode,
this means the server specified by the
<i>host</i>
parameter is the transmitter.
</dd><dt><b>-S</b>
</dt><dd>
Indicates that this nuttcp is the server. The only option that may
be specified to the server is the "-P" option, which allows one to
change the control port used by the server, but only when the server
is started by a normal, non-privileged user. When the server is
initiated by inetd/xinetd, the server control port should be specified
in the
<i>services</i>
file.
</dd><dt><b>-1</b>
</dt><dd>
Basically the same as the "-S" option, but indicates a one-shot server,
i.e. the server exits after the first data transfer initiated by a
client. The "-1" option should only be used when the server is started
by a normal, non-privileged user. This option will probably rarely
need to be used, but can be useful for a quick test and eliminates
the possibilty of leaving a non-access controlled nuttcp server running
on the system (which can happen when using the "-S" option and forgetting
to kill the nuttcp server after finishing a series of tests).
</dd><dt><b>-b</b>
</dt><dd>
Produce brief one-line output, which includes the amount of data
transferred in MB (1024**2 bytes), the time interval in seconds,
the TCP (or UDP) network throughput in Mbps (millions of bits per
second), the transmitter and/or receiver CPU utilization, and for
UDP data transfers also outputs the loss percentage. In client/server
mode, most of the printed statistics are from the viewpoint of the
receiver. This is the default output format.
</dd><dt><b>-B</b>
</dt><dd>
This option is only valid for the receiver, and forces the receiver
to read a full buffer (as specified by the "-l" buffer length option)
from the network. It is mainly intended to be used with the "-s"
option to only output full buffers to standard output (e.g. for use
with tar). It is also implicitly set whenever the number of streams
as specified by the "-N" option is greater than 1. This option is
not passed to the server.
</dd><dt><b>-d</b>
</dt><dd>
For TCP data transfers, sets the SO_DEBUG option on the data socket.
This option is not passed to the server. It is a rarely used option
which may possibly be removed or renamed in a future version of nuttcp.
</dd><dt><b>-D</b>
</dt><dd>
This option is only valid for the transmitter, and only for TCP data
transfers, in which case it sets the TCP_NODELAY option on the data
socket, which turns off the Nagle algorithm causing data packets to
be sent as soon as possible without introducing any unnecessary delays.
This option is not passed to the server. It is a rarely used option
which may possibly be removed or renamed in a future version of nuttcp.
</dd><dt><b>-s</b>
</dt><dd>
Setting the "-s" option causes nuttcp to either read its data from
standard input rather than using prefabricated memory buffers (for
"nuttcp -t"), or to write its data out to standard output (for
"nuttcp -r"). The "-s" option is disabled for security reasons
on the server.
</dd><dt><b>-u</b>
</dt><dd>
Use UDP for the data transfer instead of the default of TCP.
</dd><dt><b>-v</b>
</dt><dd>
Verbose output that provides some additional information related to
the data transfer. In client/server mode, the server is always verbose
(implicit "-v" option), but the client controls the extent and type of
output via the "-v" and "-b" options.
</dd><dt><b>-c</b><i>dscp_value</i>
</dt><dd>
Sets the socket option to support COS. Either takes a dscp value or
with the t|T modifier it takes the full TOS field.
</dd><dt><b>-l</b><i>buffer_len</i>
</dt><dd>
Length of the network write/read buffer in bytes for the
transmitter/receiver. It defaults to 64 KB (65536) for TCP data
transfers and to 8 KB (8192) for UDP. For client/server mode, it
sets both the client and server buffer lengths.
</dd><dt><b>-n</b><i>num_bufs</i>
</dt><dd>
Specifies the number of source buffers written to the network
(default is unlimited), and is ignored by the receiver. For client/server
mode, if the client issues a "nuttcp -r" command making it the
receiver, this parameter is passed to the server since the server
is the transmitter in this case. This parameter is also ignored
if the "-s" parameter is specified to the transmitter.
</dd><dt><b>-w</b><i>window_size</i>
</dt><dd>
Indicates the window size in KB of the transmitter (for "nuttcp -t")
or receiver (for "nuttcp -r"). Actually, to be technically correct,
it sets the sender or receiver TCP socket buffer size, which then
effectively sets the window size. For client/server mode, both the
transmitter and receiver window sizes are set. The default window
size is architecture and system dependent. Note recent Linux systems,
out of a misguided desire to be helpful, double whatever window size
is actually specified by the user (this is not a bug with nuttcp but
a bug/feature of the Linux kernel). Also, with these Linux systems,
the actual window size that's used on the intervening network, as
observed with tcpdump, is greater than the requested window size,
but less than the doubled value set by Linux.
</dd><dt><b>-ws</b><i>server_window</i>
</dt><dd>
For client/server mode, the "-ws" option provides a mechanism for
setting a different window size on the server than the client window
size as specified with the "-w" option.
</dd><dt><b>-wb</b>
</dt><dd>
Normally, to conserve memory, the transmitter only sets the TCP send
socket buffer size and the receiver only sets the TCP receive socket
buffer size. However, if the "-wb" option is used, the transmitter
will also set the TCP receive socket buffer size and the receiver will
also set the TCP send socket buffer size. Under normal circumstances,
this should never be necessary. This option was implemented because
certain early braindead Solaris 2.8 systems would not properly set
the TCP window size unless both the TCP send and receive socket buffer
sizes were set (later Solaris 2.8 systems have corrected this deficiency).
Thus the 'b' in this option can stand either for "braindead" or "both".
</dd><dt><b>-p</b><i>data_port</i>
</dt><dd>
Port number used for the data connection, which defaults to port 5001.
If multiple streams are specified with the "-N" option, the "-p" option
specifies the starting port number for the data connection. For example,
if four streams are specified using the default data connection port
number, nuttcp will use ports 5001, 5002, 5003, and 5004 for the four
TCP (or UDP) connections used to perform the data transfer.
</dd><dt><b>-P</b><i>control_port</i>
</dt><dd>
For client/server mode, specifies the port number used for the control
connection between the client and server, and defaults to port 5000.
On the server side, the "-P" option should only be used when the server
is started manually by the user. If the server is started by inetd/xinetd
(the preferred method), the control connection must be specified by adding
a nuttcp entry to the
<i>services</i>
file.
</dd><dt><b>-N</b><i>num_streams</i>
</dt><dd>
Species the number of parallel TCP (or UDP) data streams to be used for
the data transfer, with the default being a single data stream. The
maximum number of parallel data streams that can be used is 128. If the
number of streams is greater than one, the "-B" option is implicitly set.
The current implementation does not fork off separate processes for each
data stream, so specifying multiple streams on an SMP machine will not
take advantage of its multiple processors. Of course it is always possible
to run multiple nuttcp commands in parallel on an SMP system to determine
if there is any advantage to running on multiple processors. This is
especially simple to do when running in client/server mode when the server
is started from the inetd/xinetd daemon. When running multiple nuttcp
commands in parallel, the "-T" transmitter timeout option may be used
to insure that all the nuttcp commands finish at approximately the same
time.
</dd><dt><b>-R</b><i>xmit_rate_limit</i><b>[m|g]</b>
</dt><dd>
The transmitter rate limit throttles the speed at which the transmitter
sends data to the network, and by default is in Kbps, although the 'm'
or 'g' suffix may be used to specify Mbps or Gbps. This option may be
used with either TCP or UDP data streams. Because of the way this option
is currently implemented, it will consume all the available CPU on the
transmitter side of the connection so the "%TX" stats are not meaningful
when using the rate limit option. By default the rate limit is applied
to the average rate of the data transfer in real time, and not in CPU
time, so if nuttcp is switched out of the processor for any reason, when
it is switched back in, it is possible that the instantaneous rate may
momentarily exceed the specified value. There is an 'i' qualifier to
the rate limit option (specified as "-Ri") that will restrict the
instantaneous rate at any given point in time to the specified value,
although in this case the final rate reported by nuttcp may be less
than the specified value since nuttcp won't attempt to catch up if other
processes gain control of the CPU. The default is no rate limit. Note
another way to throttle the throughput of TCP data streams is to reduce
the window size.
</dd><dt><b>-T</b><i>xmit_time_limit</i><b>[m]</b>
</dt><dd>
Limits the amount of time that the transmitter will send data to the
specified number of seconds, or number of minutes if the 'm' suffix
is used. Normally a data transfer will either specify a fixed amount
of data to send using the "-n" option, or a fixed period of time to
send using the "-T" option. However, if both the "-n" and "-T" options
are used, the data transfer will be stopped by whichever option takes
affect first. The default is a 10 second time limit for the data
transfer.
</dd></dl>
<p>
<a name="lbAF"> </a>
</p><h2>USAGE</h2>
Under Construction
<p>
For now, consult the README file for basic usage guidelines.
<a name="lbAG"> </a>
</p><h2>EXAMPLES</h2>
Under Construction
<p>
For now, see the examples.txt file for some examples of using nuttcp.
<a name="lbAH"> </a>
</p><h2>SEE ALSO</h2>
<b><a href="http://localhost/cgi-bin/man/man2html?8+ping">ping</a></b>(8),
<b><a href="http://localhost/cgi-bin/man/man2html?8+traceroute">traceroute</a></b>(8),
<b><a href="http://localhost/cgi-bin/man/man2html?8+tracepath">tracepath</a></b>(8),
<b><a href="http://localhost/cgi-bin/man/man2html?8+pathchar">pathchar</a></b>(8),
<b><a href="http://localhost/cgi-bin/man/man2html?1+netstat">netstat</a></b>(1),
<b><a href="http://localhost/cgi-bin/man/man2html?8+mtrace">mtrace</a></b>(8)
<a name="lbAI"> </a>
<h2>AUTHORS</h2>
Developed by Bill Fink based on nttcp which in turn was an enhancement
of the original ttcp developed by Mike Muuss at BRL. IPv6 capability
and some other fixes and enhancements contributed by Rob Scott. Many
useful suggestions and testing performed by Phil Dykstra and others.
<p>
The current version is available via anonymous ftp from:
</p><p>
</p><dl compact=""><dt></dt><dd>
<i><a href="ftp://ftp.lcp.nrl.navy.mil/pub/nuttcp/">ftp://ftp.lcp.nrl.navy.mil/pub/nuttcp/</a></i>
</dd></dl>
<p>
The authors can be reached at <a href="mailto:nuttcp@lcp.nrl.navy.mil">nuttcp@lcp.nrl.navy.mil</a>.
<a name="lbAJ"> </a>
</p><h2>BUGS</h2>
Please send bug reports to <a href="mailto:nuttcp-bugs@lcp.nrl.navy.mil">nuttcp-bugs@lcp.nrl.navy.mil</a>.
<p>
</p><hr>
<a name="index"> </a><h2>Index</h2>
<dl>
<dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAB">NAME</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAC">SYNOPSIS</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAD">DESCRIPTION</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAE">OPTIONS</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAF">USAGE</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAG">EXAMPLES</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAH">SEE ALSO</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAI">AUTHORS</a></dt><dd>
</dd><dt><a href="http://lcp.nrl.navy.mil/nuttcp/nuttcp.html#lbAJ">BUGS</a></dt><dd>
</dd></dl>
<hr>
This document was created by
<a href="http://localhost/cgi-bin/man/man2html">man2html</a>,
using the manual pages.<br>
Time: 09:16:29 GMT, February 03, 2007
</body></html>