Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

On Thu, Aug 21, 2008 at 4:27 PM, Eric Schneider
<address@hidden> wrote:
> I'm assuming that at least some of the rx timestamp inaccuracy is due to the
> variable latency introduced by the rx_chan_fifo(s).  If usedw represents the
> number of samples currently in a FIFO, then the actual timestamp of the
> sample read out of the fifo is current_timestamp - usedw, correct?
>
> I do think that building the packets before buffering is a better idea, but
> adjusting the timestamps might be a quick interim fix.

I think doing the actual fix is better than doing some interim one.

> If timestamp_clock is near its max (every ~67s), and a packet is scheduled
> such that its future time will cause wraparound (making it a smallish
> number), then the reader will detect that pkt_timestamp < timestamp_clock
> and discard the packet even though in a "few" ticks timestamp_clock would be
> 0 again.

Right - looking at the code, I don't think the logic is there and a
testbench probably should be written to verify the problem/make sure
it works properly anyway.

One idea is that it may be OK to assume that packets will never be
delivered out of date and to always transmit and never drop.
Unfortunately, if one expired packet is delivered, it will be an
entire rollover before it gets back to transmitting - stalling the
pipe for quite a long time.

Another solution would be to have a "rollover" flag which tells the
FSM to first wait for a rollover before checking the timestamp.  This
flag could be set by the host when it detects a rollover in timing.  I
don't know if the host keeps track of the last transmission time or
who would be responsible for setting the flag.  Maybe it's getting a
bit complicated?

What do you think of those ideas?  Do you have a proposed solution?

Brian