commit-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Commit-gnuradio] r4691 - gnuradio/trunk/usrp/doc


From: eb
Subject: [Commit-gnuradio] r4691 - gnuradio/trunk/usrp/doc
Date: Fri, 2 Mar 2007 12:29:01 -0700 (MST)

Author: eb
Date: 2007-03-02 12:29:01 -0700 (Fri, 02 Mar 2007)
New Revision: 4691

Modified:
   gnuradio/trunk/usrp/doc/inband-signaling-gigethernet
Log:
added R3, flow control

Modified: gnuradio/trunk/usrp/doc/inband-signaling-gigethernet
===================================================================
--- gnuradio/trunk/usrp/doc/inband-signaling-gigethernet        2007-03-02 
19:14:29 UTC (rev 4690)
+++ gnuradio/trunk/usrp/doc/inband-signaling-gigethernet        2007-03-02 
19:29:01 UTC (rev 4691)
@@ -12,14 +12,23 @@
 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]