We've tried it with and without a switch - definitely better without the switch.
Thinking about our setup the behavior actually makes sense to me, although I'm waiting to discuss it with my signal processing guru. two usrp2s, connected with a mimo cable. the slave is just getting its clock from the master. the master is sampling, and sending data back to the host, which is also getting data from the slave, which is also sampling. usrp2 master is on eth0 (receive and transmit). usrp2 slave is on eth1. basically my flow graph in grc is pretty simple: two usrp2 sources feeding my custom block, which is doing some magic stuff and outputs a single channel to a single usrp2 sink (the master usrp2). I suspect that when RX is ON for eth0, the pause packets are causing the data going out on eth0 to back up, and the delay is worse (in terms of the algorithm running on the host) than the consequences of some data just being dropped on the floor, and never being transmitted. I guess I could study the firmware source (if it's in the C code where this happens) to figure out what happens if RX is OFF. My assumption is that somewhere in the USRP2 code there is some recognition that it can't keep up with transmit data, thus causing it to send pause signals back to the ethernet controller (is that correct?). Maybe it's not in the firmware but built into some ethernet port controller chip. Or maybe my understanding of what RX ON/OFF does is completely wrong. :-) So, I guess I'm asking: as I understand it, the USRP2 sends pause packets (or something) to the ethernet controller when it can't keep up with data being sent to it. RX ON means that the controller will acknowledge these pause commands and stop sending data. Or have I got that completely backwards? On Fri, Jan 15, 2010 at 1:12 PM, Eric Blossom <[email protected]> wrote: > On Thu, Jan 14, 2010 at 10:11:38PM -0500, Tom Gross wrote: >> Following up on my previous email, thinking about this some more: >> >> I'm guessing that we are sending the USRP2 more data than it can >> handle, it is sending pause packets back, which when RX is ON, the >> ethernet card recognizes and slows down its output (not knowing >> anything about gig-e control flow but this sounds like x-on x-off), >> which causes our system to become unstable, BUT when we turn of RX on >> the ethernet device, it ignores the pause packets coming back from the >> USPR2, and keeps bombarding the USRP2 with transmitter data. >> >> so what happens if we ignore the pause packets? does the USRP2 drop >> packets on the floor and just output stuff as fast as it can? > > Tom, are there any switches between the host and the USRP2? > If so, try removing them. PAUSE frames and switches don't interact > well. > > I'm not sure I'm following the physical interconnection of the pieces. > Is this the set up? > > Does the host have two gig E ports? > Is there a dedicated cable between eth<N> and USRP2 <1>? > Is there a dedicated cable between eth<N+1> and USRP2 <2>? > The two USRP2's are connected with a MIMO cable? > > Eric > _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
