added R3, flow control

git-svn-id: http://gnuradio.org/svn/gnuradio/trunk@4691 221aa14e-8319-0410-a670-987f0aec2ac5

diff --git a/usrp/doc/inband-signaling-gigethernet b/usrp/doc/inband-signaling-gigethernet
index 3bd3b43c07bc4dba8f022a1ee1a70699219b8f7a..4ca7542d200f2c63912f9d980c3cdb58bcd6a016 100644 (file)
--- a/usrp/doc/inband-signaling-gigethernet
+++ b/usrp/doc/inband-signaling-gigethernet
@@ -12,14 +12,23 @@ is to increase throughput.  Many users want to be be able to build
 WLAN type systems, and are thwarted by the relatively low throughput
 available over the USB.  Eric thinks we should shoot for at least
 100MB/s full-duplex into user space, using packets with payloads on
-the order of 256 bytes.  The small packet size is to reduce the
+the order of 256 to 512 bytes.  The small packet size is to reduce the
 latency.  This is important for many MACs that people want to build on
 the host side.
 
 (R2) Non-priviledged user programs should be able to access the USRP.
-Could be implemented by a priviledged daemon that actually handles the
+This could be implemented by a priviledged daemon that actually handles the
 low level communication with the USRP2.  This daemon may be desirable
 for other reasons, including central point of control for
 arbitrating/muxing/demuxing between multiple concurrent users (e.g.,
-Tx, Rx, various logical channels).
+Tx, Rx, requests, replies, various logical channels).
 
+(R3) Some way to flow control the host to USRP2 stream.  This is
+required in case the user connects an unthrottled signal generator to
+the USRP. (This is not uncommon.)  The USRP2 to host direction
+shouldn't be a problem, since the USRP2 throughput is controlled by
+its configuration.  It is an error to configure the USRP2 to transmit
+data at a higher rate than the transport or host can consume.
+
+One solution to this requirement could be having the USRP2 emit GigE
+"pause" frames.  We'll need to confirm that this works.