Hello, I was running Hydra MIMO testbench on USRP and got stream of this message:
usrp_source: overrun drop 16384 bytes Does anyone know what it means by overrun? Thanks, Thomas From: Josh Blum <j...@joshknows.com> To: Patrik Eliardsson <patrik.eliards...@foi.se> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Date: 12/16/2010 12:29 PM Subject: Re: [Discuss-gnuradio] Expected behavior during underruns Sent by: discuss-gnuradio-bounces+thomas.h.kim=aero....@gnu.org > Yes, I timestamp every packet sent by the send-function but my > observation shows that the underrun realignment is not automatic. I > also think that the underrun recovery works for packets, but it > doesn't work for fragments of packets. > Correct. Its at the packet level (thats UDP packet level 360~ish samples). > Consider the case when you have a packet P1 with timestamp 3.0 and > the number of samples are equal to 1 second in transmission duration. > P1 is then fragmented into several fragments by the UHD, call them > f1,f2,f3,f4,f5. The timestamp and start_of_burst is set at f1 in P1 > correct? And the remaining fragments doesn't get any timestamp and > are set to be transmitted immediate, correct? The f1 will block the > rest of the fragments until the usrp2 time is equal to the timestamp > of f1 and then all of the fragments will be transmitted in a sequence > if we do not get an underrun (1). > > If we instead get an underrun after that the first fragment is moved > to the usrp2 either nothing or a CW will be transmitted for a while > between f1 and f2 which will introduce an unknown and unwanted offset > (2). To eliminate this offset the host can drop f2 and timestamp all > of the fragments so that the fragments in the end of the transmission > happen at the expected time (3). > > f1,f2,f3,f4,f5 (1) expected sequence f1,U ,f2,f3,f4,f5 (2) with > underrun f1,U ,f3,f4,f5 (3) with underrun and dropping > > As we are talking about the fragments of a packet now, this must be > handled in vrt_packet_handler.hpp and/or io_impl.cpp. > I think you will find that hardware recovery is going to be faster then anything you you manipulate in software. I think the problem is that you are sending very large bursts with only the first packet having a time stamp. Can you try your own fragmentation into smaller sub-packets, each sub-packet with a timestamp? tx_timed_samples.cpp has an example of fragmenting a buffer into smaller packets. > http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/71e1763332141603e9edba097fd19b00e9a76ab8/entry/host/lib/transport/vrt_packet_handler.hpp > > Look at the state SEND_MODE_FULL_BUFF at line 414 //calculate new > flags for the fragments 427: if_packet_info.has_tsi = > metadata.has_time_spec and first_fragment; 428: > if_packet_info.has_tsf = if_packet_info.has_tsi; 429: > if_packet_info.sob = metadata.start_of_burst and first_fragment; > 430: if_packet_info.eob = metadata.end_of_burst and > final_fragment; > Correct, this could be modified to time-stamp every packet in the burst. But a pain to do as the code there knows nothing about the sample rate. -Josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
