On Tue, Oct 19, 2010 at 9:39 PM, Josh B. [email protected] wrote:
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
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
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
(translating that as the FPGA internal buffer).
AFAIK, if the USRP2 hardware detects an overrun, streaming stops (I’ve
using STREAM_MODE_CONTINUOUS), and in the host code, the stream command
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
message) instead of an ‘O’ and what I found was that the if I loaded
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
my PC couldn’t take any more and I received X’s and O’s equally.