mirror of https://gerrit.osmocom.org/libusrp
35 lines
1.6 KiB
Plaintext
35 lines
1.6 KiB
Plaintext
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.
|