On Tue, Oct 19, 2010 at 9:39 PM, Josh Blum <[email protected]> wrote:
> > > On 10/19/2010 06:14 PM, [email protected] wrote: > >> >> We're exploring the possibility of monitoring the overrun/underrun >> status via the USRP2 UART. >> >> > FYI, the USRP2 under UHD reports underflows as async messages to the host > that can be accessed through the API. There are no true overflows since the > implementation drops packets on the ground when the host buffers fill. But > you can observe packet loss by inspecting the timestamps on a packet. This > is done in the benchmark rx example application. > > I'm a little confused by the 'no true overflows' comment. Isn't dropping packets on the ground still an overflow? Perhaps you mean that the host doesn't report to main when there are certain types of overflows? Has this changed some for the UHD_003.001.000 code? >From what I can tell, the host code appears to handle overruns in two specific places (printed in io_impl.cpp). One appears to be checking sequence numbers (indicates that the kernel is dropping packets) and one appears to be getting a message which translates into an error code. In metadata.cpp it refers to the error as overrun of 'internal' receive buffer (translating that as the FPGA internal buffer). AFAIK, if the USRP2 hardware detects an overrun, streaming stops (I've been using STREAM_MODE_CONTINUOUS), and in the host code, the stream command is automatically resent in UHD to start streaming again. I actually attempted to recreate a scenario where I could distinguish between the two, so I changed one of the printouts to an 'X' (hardware error message) instead of an 'O' and what I found was that the if I loaded down the CPU with lots of non-uhd related tasks and then ran benchmark_rx_rate.cpp, then I could see only O's (sequence error message from the kernel). In the second case, I just upped the sampling rate until my PC couldn't take any more and I received X's and O's equally. David > -Josh > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
