--- cvsroot/AnyEvent-SNMP/README	2012/04/15 11:02:07	1.6
+++ cvsroot/AnyEvent-SNMP/README	2019/10/09 18:22:59	1.7
@@ -31,14 +31,14 @@
     CPU and memory usage. Most AnyEvent backends (including the pure-perl
     backend) fare much better than the Net::SNMP dispatcher.
 
-    Another major added fetaure of this module over Net::SNMP is automatic
+    Another major added feature of this module over Net::SNMP is automatic
     rate-adjustments: Net::SNMP is so slow that firing a few thousand
     requests can cause many timeouts simply because Net::SNMP cannot process
     the replies in time. This module automatically adapts the send rate to
     avoid false timeouts caused by slow reply processing.
 
     A potential disadvantage of this module is that replacing the dispatcher
-    is not at all a documented thing to do, so future changes in Net::SNP
+    is not at all a documented thing to do, so future changes in Net::SNMP
     might break this module (or the many similar ones).
 
     This module does not export anything and does not require you to do
@@ -63,7 +63,7 @@
 
         To avoid this, you can (and should) limit the number of outstanding
         requests to a number low enough so that parsing time doesn't
-        introduce noticable delays.
+        introduce noticeable delays.
 
         Unfortunately, this number depends not only on processing speed and
         load of the machine running Net::SNMP, but also on the network
@@ -74,7 +74,7 @@
 
         Increasing $MAX_OUTSTANDING will not automatically use the extra
         request slots. To increase $MAX_OUTSTANDING and make
-        "AnyEvent::SNMP" make use of the extra paralellity, call
+        "AnyEvent::SNMP" make use of the extra parallelity, call
         "AnyEvent::SNMP::set_max_outstanding" with the new value, e.g.:
 
            AnyEvent::SNMP::set_max_outstanding 500;
@@ -95,11 +95,11 @@
         $MIN_RECVQUEUE, it increases $MAX_OUTSTANDING.
 
         This has the result of adjusting the number of outstanding requests
-        so that the recv queue is between the minimum and maximu, usually.
+        so that the recv queue is between the minimum and maximum, usually.
 
         This algorithm works reasonably well as long as the responses,
-        response latencies and processing times are the same size per packet
-        on average.
+        response latencies and processing times are the same per packet on
+        average.
 
 COMPATIBILITY
     This module may be used as a drop in replacement for the