RE: [Discuss-gnuradio] Expected behavior during underruns

[Patrik Eliardsson]

> > It would be really nice if the send-function in the API have a TDMA 
> > mode where fragments of samples are dropped when an underrun occur so 
> > that the majority of the samples are aligned to the 
> > start_of_burst_time (see above example (1) and (3)). With this feature 
> > it is not necessary for the programmer to know if an underrun has 
> > occurred and how to handle this. Instead the programmer  knows that if 
> > an underrun occurred some samples are dropped but the rest of the 
> > sample are transmitted at the expected time without any offset.
> > Is this doable?
> > 
> 
> This should already be the case. If you timestamp every 
> packet, then the underflow recovery is handled by hardware. 
> That is, the FPGA will drop until the timestamp is <= current 
> time, and then wait until the timestamp == current time, so 
> realignment is automatic.
> 
> Are you timestamping every packet? This calculation should be 
> last_time_spec + time_spec_t(0, num_samps_in_last_packet, 
> host_sample_rate)

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.

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.

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;

To me it look likes the first fragment only has the timestamp for the packet....

Thanks for your answer by the way!

-Patrik