Merge commit 'v3.3.0' into upstream

[debian/gnuradio] / usrp / doc / inband-signaling-gigethernet

diff --git a/usrp/doc/inband-signaling-gigethernet b/usrp/doc/inband-signaling-gigethernet
new file mode 100644 (file)
index 0000000..4ca7542
--- /dev/null
+++ b/usrp/doc/inband-signaling-gigethernet
@@ -0,0 +1,34 @@
+Gigabit Ethernet Interconnect for the USRP2
+
+At this point, this is a place to summarize design requirements,
+possible solutions, point-counterpoint, etc.
+
+
+Requirements:
+
+(R1) High throughput and low latency between USRP h/w and user-space.
+One of the primary reasons for switching from USB to gigabit ethernet
+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 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.
+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, 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.