man: edits to ifpps man page

Some edits to the ifpps man page.

Signed-off-by: Jon Schipp <jonschipp@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>

1 files changed, 22 insertions, 22 deletions

diff --git a/ifpps.8 b/ifpps.8
index 46088dd..8f802e9 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 would falsify statistics on high load.
+which could falsify statistics on high load.
 
 For instance, consider the following scenario: two directly connected
-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
+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
 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 are
-in our focus; statistics, which are also fairly reliable under high packet
+is not implemented in ifpps, because overall networking statistics is
+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 1000 ms.
+Statistics refresh interval in milliseconds, default is 1000ms(1 sec).
 
 .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
-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
+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
 with gnuplot(1).
 
 .SS -v, --version
-Show versioning information.
+Show version 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 each > 1sec. Thus, it might be advised to alter the timing
-option to a higher accumulation interval for such cards.
+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.
 
 .SH BUGS
-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
+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
 challenge would be to display the presented information in a sane way,
 probably by selectively hiding uninteresting statistics.