Re: [Discuss-gnuradio] inband timestamp issues

[Steve Peters]

Hi George,

Thanks for the quick and thought-out response.  I actually tried with
the new rbf yesterday.  It produces no noticeable differences in the
output I'm interested in at this point.

Second, we are not seeing any underrun.  I have verified this in two
ways.  First, I check pkt->underrun() after reading the packet in
usrp_rx.cc.  Second, I logged the packets to file, ran ./read_packets
<filename> (redirecting output to another file), and did a
case-insensitive grep of that new file for "underrun".  Nothing ever
comes up.

However, to see if the usrp_rx mblock is being starved, I turned on
some verbose printing in the usrp_server and usrp_usb_interface.  The
following is a typical sequence:

<a few thousand or so packets successful, context switching between
mblocks balanced; usrp_rx reads roughly 8 packets before switching
context>
<about 180 usb_packets are successively read by the usrp_rx before the
next context switch.  Of these, the 130th or 135th one contains a
spike in the timestamp>
<normal operation for awhile before another long block of reads by
usrp_rx and another timestamp spike>

(also, long reads by the usrp_rx are often preceded by long gaps where
the usrp_rx is not executing)

In short, it appears as if the timestamp spike is occurring in the
middle of a string of successive packets read from the usrp without
context switching.

Anyway, I figured one solution might be to have the usrp_rx do an
omni_thread::yield() operation after reading several packets.  I tried
this out with various numbers of maximum iterations of the while loop
(80, 30, 8), and the problem persists.  It seems to happen in the
middle of the longest burst of packets, if that makes sense.  So if I
yield after 80 packets, the timestamp will spike around the 47th
packet.  If I yield after 30 packets, the timestamp spikes at around
the 12th packet.

The strange thing to us is that the timestamp spike invariably changes
the "steady state" operation of the timestamp offset between the two
channels.  This says "FPGA" to us, especially since we aren't getting
an underrun flag.

Steve

On Tue, Jul 22, 2008 at 10:46 PM, George Nychis <address@hidden> wrote:
>
>
> Eric Blossom wrote:
>>
>> On Tue, Jul 22, 2008 at 05:59:17PM -0500, Ketan Mandke wrote:
>>>
>>> My colleague Steve and I have been working with the inband receive
>>> code in an effort to understand how the timestamps work. Specifically,
>>> we have been printing the timestamps from the usrp_rx block while
>>> running test_usrp_inband_2rx.cc in usrp/host/apps-inband. There is
>>> some puzzling behavior that we have observed and unable to explain. We
>>> are operating with a decimation rate of 64 (i.e. a 1 MHz sample rate).
>>>
>>> Note, this is using the gnuradio trunk rev 8586, with the
>>> gnuradio/trunk/usrp/ code unchanged except to print timestamp data in
>>> usrp_rx.cc. There don't seem to be any major changes since this revision.
>>
>> Paging George Nychis,... Paging George Nychis...
>> Please come to the white courtesy telephone...
>>
>
> I've known about a inband timestamp issue.  but I'm not sure its the same.
>
> I've fixed this in the code a while ago, but never committed new RBFs from
> being busy to build them.
>
> Here is the fix I made on 05/15/08:
> http://gnuradio.org/trac/changeset/8430
>
> I didn't actually get to build the new RBFs until earlier this week:
> http://gnuradio.org/trac/changeset/8924
> http://gnuradio.org/trac/changeset/8935
>
> I'm not sure this fix explains the jumps in timestamps you're seeing, as it
> was mainly a reset issue causing the TX and RX timestamps to be on different
> clocks.  But, I'd like you to try it out with the new RBFs so we are at
> least on the same page and I know you're working with the newest and
> greatest RBFs.  Then if the issue still occurs, I can poke before I merge to
> trunk.
>
> If you want my opinion though, I don't think its an FPGA issue, I think that
> its an underrun issue.  Can you try checking if the underrun flag is set on
> any of the packets around your sudden jumps?  You can use the read_packets
> application in usrp/host/apps-inband to read a packet dump.  You can enable
> the packet dump by editing usrp/host/lib/inband/usrp_rx.cc and setting
> d_disk_write(true) and d_write_pkt(true):
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/lib/inband/usrp_rx.cc#L47
>
> Just use read_packets on your dump, which should be something like
> rx_data_chan0.dat and rx_data_chan1.dat ... it should print underrun on the
> packet if it was set.
>
> The 2TX/RX stuff in the inband code is very iffy in my opinion.  All of the
> message passing going on and the context switching between the m-blocks
> means that the lowest level usrp_rx block might be waiting a while before it
> gets time on the CPU again ... leaving the FPGA to drop USB blocks in the
> mean time.  But, the underrun flag should tell you this.
>
> - George
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>