[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Commit-gnuradio] r4691 - gnuradio/trunk/usrp/doc,
eb <=