Update known issues for #55, #125, and #129.

docs/dev.rst

@@ -79,10 +79,14 @@ tracker.  These issues are either open (indicating no solution
 currently exists) or closed with the notation that no further attempts
 to solve the problem are currently being made:
 
-* UDP performance: iperf2/iperf3 are both only about 50% as fast
+* UDP performance: Some problems have been noticed with iperf3 on the
-  as nuttcp in UDP mode.  This is being investigated, but in the
+  ESnet 100G testbed at high UDP rates (above 10Gbps).  The symptom is
-  meantime, if UDP tests above 5Gbps are needed, using
+  that on any particular run of iperf3 the receiver reports a loss
-  `nuttcp <http://www.nuttcp.net/>`_ is recommended.  (Issue #55)
+  rate of about 20%, regardless of the ``-b`` option used on the client
+  side.  This problem appears not to be iperf3-specific, and may be
+  due to the placement of the iperf3 process on a CPU and its relation
+  to the inbound NIC.  In some cases this problem can be mitigated by
+  an appropriate use of the CPU affinity (``-A``) option.  (Issue #55)
 
 * Interval reports on high-loss networks: The way iperf3 is currently
   implemented, the sender write command will block until the entire
@@ -90,9 +94,11 @@ to solve the problem are currently being made:
   seconds to send a full block if the network has high loss, and the
   interval reports will have widely varying interval times.  A
   solution is being discussed, but in the meantime a work around is to
-  try using a small block size, for example ``-l 4K``.  (Issue #125)
+  try using a small block size, for example ``-l 4K``.  (Issue #125,
+  a fix will be released in iperf 3.1)
 
-* The ``-Z`` flag sometimes hangs on OSX.  (Issue #129)
+* The ``-Z`` flag sometimes causes the iperf3 client to hang on OSX.
+  (Issue #129)
 
 * On OpenBSD, the server seems to require a ``-4`` argument, implying
   that it can only be used with IPv4.  (Issue #108)