You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+11-28Lines changed: 11 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,34 +77,17 @@ welcome.
77
77
78
78
## usage
79
79
80
-
Everything is outlined in the output of `--help` and most users familiar with
81
-
similar tools should feel comfortable immediately.
82
-
83
-
_rperf_ works much like _iperf3_, sharing a lot of concepts and even
84
-
command-line flags. One key area where it differs is that the client drives
85
-
all of the configuration process while the server just complies to the best
86
-
of its ability and provides a stream of results. This means that the server
87
-
will not present test-results directly via its interface and also that TCP
88
-
and UDP tests can be run against the same instance, potentially by many clients
89
-
simultaneously.
90
-
91
-
In its normal mode of operation, the client will upload data to the server;
92
-
when the `reverse` flag is set, the client will receive data.
93
-
94
-
Unlike _iperf3_, _rperf_ does not make use of a reserved port-range. This is
95
-
so it can support an arbitrary number of clients in parallel without
96
-
resource contention on what can only practically be a small number of
97
-
contiguous ports. In its intended capacity, this shouldn't be a problem, but
98
-
it does make `reverse` incompatible with most non-permissive firewalls and
99
-
NAT setups.
100
-
101
-
There also isn't a concept of testing throughput relative to a fixed quantity
102
-
of data. Rather, the sole focus is on measuring throughput over a roughly
103
-
known period of time.
104
-
105
-
Also of relevance is that, if the server is running in IPv6 mode and its
106
-
host supports IPv4-mapping in a dual-stack configuration, both IPv4 and IPv6
107
-
clients can connect to the same instance.
80
+
Everything is outlined in the output of `--help` and most users familiar with similar tools should feel comfortable immediately.
81
+
82
+
_rperf_ works much like _iperf3_, sharing a lot of concepts and even command-line flags. One key area where it differs is that the client drives all of the configuration process while the server just complies to the best of its ability and provides a stream of results. This means that the server will not present test-results directly via its interface and also that TCP and UDP tests can be run against the same instance, potentially by many clients simultaneously.
83
+
84
+
In its normal mode of operation, the client will upload data to the server; when the `reverse` flag is set, the client will receive data.
85
+
86
+
Unlike _iperf3_, _rperf_ does not make use of a reserved port-range by default. This is so it can support an arbitrary number of clients in parallel without resource contention on what can only practically be a small number of contiguous ports. In its intended capacity, this shouldn't be a problem, but where non-permissive firewalls and NAT setups are concerned, the `--tcp[6]-port-pool` and `--udp[6]-port-pool` options may be used to allocate non-continguous ports to the set that will be used to receive traffic.
87
+
88
+
There also isn't a concept of testing throughput relative to a fixed quantity of data. Rather, the sole focus is on measuring throughput over a roughly known period of time.
89
+
90
+
Also of relevance is that, if the server is running in IPv6 mode and its host supports IPv4-mapping in a dual-stack configuration, both IPv4 and IPv6 clients can connect to the same instance.
0 commit comments