man: trafgen: Minor fixes

Replace "on default" by "by default", make it a bit more clear what the
seed in the -E/--seed option is for and mention exit after display of
information on --version and --help.

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>

1 files changed, 22 insertions, 22 deletions

diff --git a/ifpps.8 b/ifpps.8
index 8f802e9..46088dd 100644
--- a/ifpps.8
+++ b/ifpps.8
@@ -15,24 +15,24 @@ ifpps \- top-like networking and system statistics
 ifpps is a small utility which periodically provides top-like networking
 and system statistics from the kernel. ifpps gathers its data directly
 from procfs files and does not apply any user space monitoring libraries
-which could falsify statistics on high load.
+which would falsify statistics on high load.
 
 For instance, consider the following scenario: two directly connected
-Linux machines, each with an Intel Core 2 Quad Q6600 2.40GHz CPUs, 4 GB
-RAM, and an Intel 82566DC-2 Gigabit Ethernet NIC, are used for performance
-evaluation. One machine generates 64 byte network packets by using the
-kernel space packet generator, pktgen, with a maximum possible packet rate.
-The other machine displays statistics about incoming network packets by
-using i) iptraf(8) and ii) ifpps.
-
-iptraf which incorporates pcap(3) shows an average packet rate of
-246,000 pps, while on the other hand, ifpps shows an average packet rate
-of 1,378,000 pps. Hence, due to packet copies and deferring statistical
-calculations to user space, a measurement error of approx. 460 per cent
+Linux machines with Intel Core 2 Quad Q6600 2.40GHz CPUs, 4 GB RAM, and
+an Intel 82566DC-2 Gigabit Ethernet NIC are used for performance evaluation.
+One machine generates 64 byte network packets by using the kernel space
+packet generator pktgen with a maximum possible packet rate. The other
+machine displays statistics about incoming network packets by using i)
+iptraf(8) and ii) ifpps.
+
+iptraf that incorporates pcap(3) shows an average packet rate of
+246,000 pps while on the other hand ifpps shows an average packet rate of
+1,378,000 pps. Hence, due to copying packets and deferring statistics
+creation into user space, measurement error of approx. 460 per cent
 occurs. Tools like iptraf might display much more information such as
 TCP per flow statistics (therefore the use of the pcap library), which
-is not implemented in ifpps, because overall networking statistics is
-our focus; statistics, which are also fairly reliable under high packet
+is not implemented in ifpps, because overall networking statistics are
+in our focus; statistics, which are also fairly reliable under high packet
 load.
 
 .SH OPTIONS
@@ -41,7 +41,7 @@ load.
 Networking device to fetch statistics from, e.g. eth0, wlan0.
 
 .SS -t <time>, --interval <time>
-Statistics refresh interval in milliseconds, default is 1000ms(1 sec).
+Statistics refresh interval in milliseconds, default is 1000 ms.
 
 .SS -p, --promisc
 Turn on promiscuous mode for the given networking device.
@@ -51,12 +51,12 @@ Output (once) the ncurses data to the terminal as gnuplot(1)-ready data.
 
 .SS -l, --loop
 Continuously output the terminal data after a refresh interval. This option
-is available only if option ``-c'' is given. For ``-l'' it is usually
-recommended to redirect the output into a file that will be processed
+only is available, if option ``-c'' is given. For ``-l'' it is usually
+recommended to redirect the output into a file that is later being processed
 with gnuplot(1).
 
 .SS -v, --version
-Show version information.
+Show versioning information.
 
 .SS -h, --help
 Show user help.
@@ -74,12 +74,12 @@ Continuous terminal output for the wlan0 device in promiscuous mode.
 
 .SH NOTE
 On 10Gbit/s cards or higher, receive and transmit statistics are usually
-accumulated at a higher duration interval than 1 second. Thus, it might
-be advised to alter the timing option to a longer interval for such cards.
+accumulated each > 1sec. Thus, it might be advised to alter the timing
+option to a higher accumulation interval for such cards.
 
 .SH BUGS
-Systems with a fairly high number of cores (> 32) are currently not
-supported. This should, however, not be a big deal to fix. The only
+Systems with a failry high number of cores (> 32) are currently not
+supported. This should however not be a big deal to fix that. The only
 challenge would be to display the presented information in a sane way,
 probably by selectively hiding uninteresting statistics.