1ovs-benchmark(1) Open vSwitch Manual ovs-benchmark(1)
2
6 ovs-benchmark - flow setup benchmark utility for Open vSwitch
7
9 ovs-benchmark latency --remote ip[:ports] [--sockets nsocks]
10 [--batches nbatches] [--local [ip][:ports]]
11 ovs-benchmark rate --remote ip[:ports] [--max-rate rate]
13 [--timeout maxsecs] [--sockets nsocks]
14 [--batches nbatches] [--local [ip][:ports]]
15 ovs-benchmark listen [--local [ip]:ports]
17 ovs-benchmark help
19
21 ovs-benchmark tests the performance of Open vSwitch flow setup by set‐
22 ting up a number of TCP connections and measuring the time required.
23 It can also be used with the Linux bridge or without any bridging soft‐
24 ware, which allows one to measure the bandwidth and latency cost of
25 bridging.
26 Each ovs-benchmark command is described separately below.
28
30 This command initiates nsocks TCP connections (by default, 100) as
31 quickly as possible, waits for each one to complete with success or
32 failure, and prints a bar chart of completion times on standard output,
33 followed by a summary line. Each line in the bar chart lists a time to
34 connection completion in milliseconds followed by a number of . or !
35 symbols, one for each TCP connection that completed in that many mil‐
36 liseconds. A successful connection prints a ., and an unsuccessful
37 connection (e.g. to a port on which no process is listening) prints a
38 !.
39 If nbatches is given, the entire procedure is repeated the specified
41 number of times. Only a single summary line is printed at the end.
42 Results vary widely based on the number of sockets and whether the
44 remote host is listening for connections on the specified ports. With
45 a small number of sockets, all connection times typically remain within
46 a handful of milliseconds. As the number of sockets increases, the
47 distribution of connection times clusters around the sending TCP
48 stack's SYN retransmission interval. (This pattern occurs with or
49 without Open vSwitch on the network path.)
50
52 This command initiates nsocks TCP connections (by default, 100) as
53 quickly as possible (limited by maxrate, if --max-rate is specified).
54 Each time a connection completes with success or failure, it closes
55 that connection and initiates a new one. It continues to do so either
56 forever or, if --timeout is specified, until maxsecs seconds have
57 elapsed. During the test, it prints statistics about time elapsed,
58 successful and unsuccessful connections, and the average number of com‐
59 pleted (succeeded or failed) connections per second over the run.
60 Without --max-rate, the rate command measures the maximum sustained
62 flow setup rate for an Open vSwitch instance. This naturally tends to
63 drive ovs-vswitchd CPU usage to 100% on the host receiving the traffic.
64 When --max-rate is specified with a value below the maximum rate that
66 an Open vSwitch instance can handle, then rate can also be used to mea‐
67 sure the kernel and userspace CPU cost of flow setups at specific flow
68 rates.
69 Results tend to fluctuate greatly for the first few seconds of a run,
71 then settle down. The displayed average is calculated over the entire
72 run and so tends to converge asymptotically on the ``correct'' value.
73 To converge more quickly, try running for 5 to 10 seconds, then killing
74 and restarting the run.
75
77 This command listens on one or more TCP ports for incoming connections.
78 It accepts connections and immediately closes them. It can be paired
79 with the rate or latency commands for observing effects of successful
80 vs. unsuccessful TCP connections.
81 It is easier to reproduce and interpret ovs-benchmark results when
83 there is no listener (see NOTES below).
84
86 Prints a usage message and exits successfully.
87
89 -r ip[:ports]
90 --remote ip[:ports]
91 This option, required on latency and rate commands, minimally
92 specifies the remote host to connect to (as an IP address or DNS
93 name) as ip.
94 A TCP port or range of ports (separated by -) may also be speci‐
96 fied. If a range is specified then each port in the range is
97 used in round-robin order. The default port is 6630 if none is
98 specified.
99 -l [ip][:ports]
101 --local [ip][:ports]
102 On the latency and rate, without this option, outgoing connec‐
103 tions will not bind a specific TCP port. The local TCP stack
104 will pick a local TCP port to bind. When this option is speci‐
105 fied, the specified port or range of ports will be used in turn.
106 (If a port range is specified on both --local and --remote, then
107 each local port in its range will be used before the remote port
108 is incremented to the next port in its range.)
109 On the listen command, this option specifies the local port or
111 ports and IP addresses on which to listen. If it is omitted,
112 port 6630 on any IP address is used.
113 -s nsocks
115 --sockets nsocks
116 For latency, sets the number of connections to initiate per
117 batch. For rate, sets the number of outstanding connections
118 attempts to maintain at any given time. The default is 100.
119 -b nbatches
121 --batches nbatches
122 For latency, sets the number of times to initiate and wait for
123 all of the connections to complete. The default is 1.
124 -c maxrate
126 --max-rate maxrate
127 For rate, caps the maximum rate at which connections will be
128 attempted to maxrate connections per second. By default there
129 is no limit.
130 -T maxsecs
132 --timeout maxsecs
133 For rate, stops the benchmark after maxsecs seconds have
134 elapsed. By default, the benchmark continues until interrupted
135 by a signal.
136
138 ovs-benchmark uses standard POSIX socket calls for network access, so
139 it shares the strengths and limitations of TCP/IP and its implementa‐
140 tions in the local and remote TCP/IP stacks. Particularly, TCP and its
141 implementations limit the number of successfully completed and then
142 closed TCP connections. This means that ovs-benchmark tests tend to
143 slow down if run for long intervals or with large numbers of sockets or
144 batches, if the remote system is listening on the port or ports being
145 contacted. The problem does not occur when the remote system is not
146 listening. ovs-benchmark results are therefore much more reliable and
147 repeatable when the remote system is not listening on the port or ports
148 being contacted. Even a single listening socket (e.g. range of ports
149 8000 to 9000 with one listener on port 8080) can cause anomalies in
150 results.
151 Be sure that the remote TCP/IP stack's firewall allows the benchmark's
153 traffic to be processed. For Open vSwitch benchmarking purposes, you
154 might want to disable the firewall with, e.g., iptables -F.
155 ovs-benchmark is single-threaded. A multithreaded process might be
157 able to initiate connections more quickly.
158 A TCP connection consists of two flows (one in each direction), so mul‐
160 tiply the TCP connection statistics that ovs-benchmark reports by 2 to
161 get flow statistics.
162Open vSwitch 2.0.0 ovs-benchmark(1)