RE: [Discuss-gnuradio] Expected behavior during underruns

[Patrik Eliardsson]

> > Underflows occur on transmit, nothing can drop because this is a lack 
> > of samples.

That's true! But I don't want the rest of the samples to be delayed due to the 
underrun.
> 
> If I understand correctly, the transmit situation that Patrik 
> describes is behaviour _after_ the underflow. For a 
> continuous stream, the effect to subsequent samples is an 
> added time offset - equal to the duration of the underflow - 
> relative to the original start of the stream.
> 

Yes you understood me correct and it is this offset I want to be zero again 
after an underrun. But I have a continuous stream. For example: if I expect 
that eth-packets (1) should be moved to the USRP2 and then transmitted, but if 
I get an underrun the sequence can be like this (2) then there is a offset 
between the real-time for p2 and the actual transmitting time. The solution is 
then to drop p2 (and maybe p3) in the host so the sequence becomes (3)(if we 
also drop p3 p1,U,E,p4,p5 E=empty) where p4,p5 are transmitted at the original 
expected time(compare (1) with (3)).  

p1,p2,p3,p4,p5          (1) excpected sequence
p1,U ,p2,p3,p4,p5               (2) with underrun
p1,U ,p3,p4,p5          (3) with underrun and dropping

> For certain real-time applications, paired spectrum TDMA for 
> example, this makes underruns devastating. In these cases, 
> samples that were supposed to be transmitted when the 
> underrun occurred, but didn't for whatever reason, are 
> irrelevant and need to be dropped rather than transmitted 
> best effort. AFAIK, the only way to currently handle this is 
> to catch the underrun at the host and drop a handful of 
> packets so that the next start-of-burst reaches the USRP2 
> ahead of the deadline.
> 
> >> I've been looking in the source code and tried to find out where to 
> >> implement the sample dropping. My thoughts so far is that it should 
> >> be somewhere in vrt_packet_handler.hpp and/or io_impl.cpp in the send 
> >> functions and get_send_buffs function.
> >>
> >
> > Is there something that you think the streaming API is missing please 
> > let me know. I think you can accomplish what you need with the API 
> > without modifying the underlying implementation.

Yes, sure I could probably solve this with the API. But I utilize that the 
send-function in the API fragments the payload(samples) to fit in eth-packets 
to the usrp2. For example: if I send 25Msamp @ 25Msamp/s with one call to the 
send function those samples will be split into several eth-packets and 
transmitted during 1 second if we don't get any underruns (if we get underruns 
they are transmitted but it takes more time than 1 second), correct? If I 
handle the underruns with the API, I have to drop some samples and wait for 
some part of 1 second to get synchronized alignment on the next second after 
that. This creates a gap of some part of second where I'm not transmitting.

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? 

-Patrik