On Fri, May 27, 2011 at 3:21 AM, Marcus D. Leech <[email protected]> wrote:
> > > > USRP1: > > - When we have a very simple flowgraph with a USRP1 sink connected to a > > signal source and a USRP1 source connected to a WX scope- trying to shut > > down the app using the close box causes the USB on the host system to > > freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids > > this problem. This problem exists on many flowgraphs, both GRC generated > > and not- as far as I know it is limited to flowgraphs with both USRP1 > > source and sink. This is a serious problem that has hit us on multiple > > platforms and machines and causes unnecessary reboots. It is honestly an > > unacceptable bug. > > > > > My intuition here is that the "close" box doesn't cause the flow-graph > to do the > usual "finish the flow-graph" thing. Which means that the USRP1 is > still streaming, and > nobody is listening. For the 'power off' case, the USRP1 resets > itself, and stops streaming > data, and for ctrl-C, there's built-in logic that causes the > flow-graph to shutdown > "politely", and send a "please stop streaming" command to the USRP1. > My suspicion about > USB freeze-up is that the problem is due to the USB drivers in the > kernel not doing the > right thing with a deluge of data still arriving when nobody is > actually listening. Which makes it a > not-strictly-GnuRadio thing, and more of a USB drivers thing. Also, > USB is inherently half-duplex, > which may (somehow) play into scenarios like this--some kind of weird > deadlock problem in the > kernel USB drivers? >From the sounds of things, I'd say Marcus is correct. At least, it's what I'm thinking is the problem, as well. > > > USRP2 / UHD: > > - With a similar flowgraph to the one above, changing the secs/div > > causes the various traces to change phase relative to one another but > > this doesn't happen when a USRP1 source is substituted. However, I > > believe this is indicative of a deeper problem. We also see with the > > same flowgraph and a slider that controls both the TX and RX frequencies > > simultaneously, the flowgraph gets into a place where it seems to be > > getting data but it no longer represents the state of what's coming in > > and we also see the phase slippage. Long story short, create a flowgraph > > with a UHD (USRP2) sink and source with a siggen at a fixed > > frequency/amplitude, a wx scope, and a slider that sets the TX+RX > > frequencies to the slider value. Direct connect the TX to the RX with an > > SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX > > this seems to give various results. Do the same thing with a USRP1 for > > comparison. To me it seems like UHD is losing data or the various paths > > in the flowgraph get out of whack with eachother. There were no O's or > > U's printed. > > > > We were trying to do a simple VNA in UHD and it just doesn't work as > > expected, but switching it all over to a USRP1 its fine and dandy. > > > > > > > There's a tremendous amount of buffering inside a Gnu Radio flow-graph, > which can > easily cause *seconds* of latency. The buffer-sizing algorithm is > complicated, and the > buffering at any point in the graph is calculated by whatever is > downstream, including > decimators. > The GNU Radio scheduler optimizes for throughput, not latency, so yes, large latencies can build up in the buffers because of the difference in the optimization process. > I've long opined that the buffer-sizing (with its inherent latency) > isn't actually correct all the time, > but I admit to not having offered any meaningful solutions. I don't > know whether UHD exacerbates > this problem or not. Yes, it would be nice to have this ability. Unfortunately, it's not on my list of things to get to immediately. Obviously, it's going to require some delicate surgery inside the scheduler code. And when I say delicate, I'm no saying that it's necessarily difficult, but that it must be thought about carefully to make sure we're not harming ourselves in any other way. Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
