]> git.proxmox.com Git - ovs.git/blame - utilities/ovs-benchmark.1.in
ofp-util: Implement translation to and from OpenFlow 1.1 ofp_match.
[ovs.git] / utilities / ovs-benchmark.1.in
CommitLineData
5e00790e 1.\" -*- nroff -*-
23edef9e 2.so lib/ovs.tmac
5e00790e
BP
3.TH ovs\-benchmark 1 "July 2011" "Open vSwitch" "Open vSwitch Manual"
4.
5.SH NAME
6ovs\-benchmark \- flow setup benchmark utility for Open vSwitch
7.
8.SH SYNOPSIS
9.
10.SY ovs\-benchmark\ latency
11\fB\-\-remote \fIip\fR[\fB:\fIports\fR]
12.OP \-\-sockets nsocks
13.OP \-\-batches nbatches
14.OP \-\-local \fR[\fIip\fR][\fB:\fIports\fR]
15.YS
16.
17.SY ovs\-benchmark\ rate
18\fB\-\-remote \fIip\fR[\fB:\fIports\fR]
19.OP \-\-max\-rate rate
20.OP \-\-timeout maxsecs
21.OP \-\-sockets nsocks
22.OP \-\-batches nbatches
23.OP \-\-local \fR[\fIip\fR][\fB:\fIports\fR]
24.YS
25.
26.SY ovs\-benchmark\ listen
27.OP \-\-local \fR[\fIip\fR]\fB:\fIports
28.YS
29.
30.SY ovs\-benchmark\ help
31.YS
32.
33.SH DESCRIPTION
34\fBovs\-benchmark\fR tests the performance of Open vSwitch flow setup
35by setting up a number of TCP connections and measuring the time
36required. It can also be used with the Linux bridge or without any
37bridging software, which allows one to measure the bandwidth and
38latency cost of bridging.
39.PP
40Each \fBovs\-benchmark\fR command is described separately below.
41.
42.SH "The ``latency'' command"
43.
44.PP
45This command initiates \fInsocks\fR TCP connections (by default, 100)
46as quickly as possible, waits for each one to complete with success or
47failure, and prints a bar chart of completion times on standard
48output, followed by a summary line. Each line in the bar chart lists
49a time to connection completion in milliseconds followed by a number
50of \fB.\fR or \fB!\fR symbols, one for each TCP connection that
51completed in that many milliseconds. A successful connection prints a
52\fB.\fR, and an unsuccessful connection (e.g. to a port on which no
53process is listening) prints a \fB!\fR.
54.
55.PP
56If \fInbatches\fR is given, the entire procedure is repeated the
57specified number of times. Only a single summary line is printed at
58the end.
59.
60.PP
61Results vary widely based on the number of sockets and whether the
62remote host is listening for connections on the specified ports. With
63a small number of sockets, all connection times typically remain
64within a handful of milliseconds. As the number of sockets increases,
65the distribution of connection times clusters around the sending TCP
66stack's SYN retransmission interval. (This pattern occurs with or
67without Open vSwitch on the network path.)
68.
69.SH "The ``rate'' command"
70.
71.PP
72This command initiates \fInsocks\fR TCP connections (by default, 100)
73as quickly as possible (limited by \fImaxrate\fR, if
74\fB\-\-max\-rate\fR is specified). Each time a connection completes
75with success or failure, it closes that connection and initiates a new
76one. It continues to do so either forever or, if \fB\-\-timeout\fR is
77specified, until \fImaxsecs\fR seconds have elapsed. During the test,
78it prints statistics about time elapsed, successful and unsuccessful
79connections, and the average number of completed (succeeded or failed)
80connections per second over the run.
81.
82.PP
83Without \fB\-\-max\-rate\fR, the \fBrate\fR command measures the
84maximum sustained flow setup rate for an Open vSwitch instance. This
85naturally tends to drive \fBovs\-vswitchd\fR CPU usage to 100% on the
86host receiving the traffic.
87.
88.PP
89When \fB\-\-max\-rate\fR is specified with a value below the maximum
90rate that an Open vSwitch instance can handle, then \fBrate\fR can
91also be used to measure the kernel and userspace CPU cost of flow
92setups at specific flow rates.
93.
94.PP
95Results tend to fluctuate greatly for the first few seconds of a run,
96then settle down. The displayed average is calculated over the entire
97run and so tends to converge asymptotically on the ``correct'' value.
98To converge more quickly, try running for 5 to 10 seconds, then
99killing and restarting the run.
100.
101.SH "The ``listen'' command"
102.
103.PP
104This command listens on one or more TCP ports for incoming
105connections. It accepts connections and immediately closes them. It
106can be paired with the \fBrate\fR or \fBlatency\fR commands for
107observing effects of successful vs. unsuccessful TCP connections.
108.
109.PP
110It is easier to reproduce and interpret \fBovs\-benchmark\fR results
111when there is no listener (see \fBNOTES\fR below).
112.
113.SH "The ``help'' command"
114.
115.PP
116Prints a usage message and exits successfully.
117.
118.SH OPTIONS
119.
120.IP "\fB\-r \fIip\fR[\fB:\fIports\fR]"
121.IQ "\fB\-\-remote \fIip\fR[\fB:\fIports\fR]"
122This option, required on \fBlatency\fR and \fBrate\fR commands,
123minimally specifies the remote host to connect to (as an IP address or
124DNS name) as \fIip\fR.
125.
126.IP
127A TCP port or range of ports (separated by \fB\-\fR) may also be
128specified. If a range is specified then each port in the range is
129used in round-robin order. The default port is 6630 if none is
130specified.
131.
132.IP "\fB\-l \fR[\fIip\fR][\fB:\fIports\fR]"
133.IQ "\fB\-\-local \fR[\fIip\fR][\fB:\fIports\fR]"
134On the \fBlatency\fR and \fBrate\fR, without this option, outgoing
135connections will not bind a specific TCP port. The local TCP stack
136will pick a local TCP port to bind. When this option is specified,
137the specified port or range of ports will be used in turn. (If a port
138range is specified on both \fB\-\-local\fR and \fB\-\-remote\fR, then
139each local port in its range will be used before the remote port is
140incremented to the next port in its range.)
141.
142.IP
143On the \fBlisten\fR command, this option specifies the local port or
144ports and IP addresses on which to listen. If it is omitted, port
1456630 on any IP address is used.
146.
147.IP "\fB\-s \fInsocks\fR"
148.IQ "\fB\-\-sockets \fInsocks\fR"
149For \fBlatency\fR, sets the number of connections to initiate per
150batch. For \fBrate\fR, sets the number of outstanding connections
151attempts to maintain at any given time. The default is 100.
152.
153.IP "\fB\-b \fInbatches\fR"
154.IQ "\fB\-\-batches \fInbatches\fR"
155For \fBlatency\fR, sets the number of times to initiate and wait for
156all of the connections to complete. The default is 1.
157.
158.IP "\fB\-c \fImaxrate\fR"
159.IQ "\fB\-\-max\-rate \fImaxrate\fR"
160For \fBrate\fR, caps the maximum rate at which connections will be
161attempted to \fImaxrate\fR connections per second. By default there
162is no limit.
163.
164.IP "\fB\-T \fImaxsecs\fR"
165.IQ "\fB\-\-timeout \fImaxsecs\fR"
166For \fBrate\fR, stops the benchmark after \fImaxsecs\fR seconds have
167elapsed. By default, the benchmark continues until interrupted by a
168signal.
169.
170.SH NOTES
171.PP
172\fBovs\-benchmark\fR uses standard POSIX socket calls for network
173access, so it shares the strengths and limitations of TCP/IP and its
174implementations in the local and remote TCP/IP stacks. Particularly,
175TCP and its implementations limit the number of successfully completed
176and then closed TCP connections. This means that \fBovs\-benchmark\fR
177tests tend to slow down if run for long intervals or with large
178numbers of sockets or batches, if the remote system is listening on
179the port or ports being contacted. The problem does not occur when
180the remote system is not listening. \fBovs\-benchmark\fR results are
181therefore much more reliable and repeatable when the remote system is
182not listening on the port or ports being contacted. Even a single
183listening socket (e.g. range of ports 8000 to 9000 with one listener
184on port 8080) can cause anomalies in results.
185.
186.PP
187Be sure that the remote TCP/IP stack's firewall allows the benchmark's
188traffic to be processed. For Open vSwitch benchmarking purposes, you
189might want to disable the firewall with, e.g., \fBiptables \-F\fR.
190.
191.PP
192\fBovs\-benchmark\fR is single-threaded. A multithreaded process
193might be able to initiate connections more quickly.
194.
195.PP
196A TCP connection consists of two flows (one in each direction), so
197multiply the TCP connection statistics that \fBovs\-benchmark\fR
198reports by 2 to get flow statistics.