On Tue, Oct 19, 2010 at 9:39 PM, Josh Blum
<address@hidden> wrote:
On 10/19/2010 06:14 PM,
address@hidden 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