sdr
/
libusrp
mirror of https://gerrit.osmocom.org/libusrp
7
0
Fork 0
Code Releases Activity

added R3, flow control 

git-svn-id: http://gnuradio.org/svn/gnuradio/trunk@4691 221aa14e-8319-0410-a670-987f0aec2ac5
This commit is contained in:
eb 2007-03-02 19:29:01 +00:00
parent 89bd3d7650
commit 268db6cdcb
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/inband-signaling-gigethernet
View File

@ -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.