RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

Okay, so to elaborate on the design options a little more...

I see to primary topologies: packet push, and packet pull.  Both designs
have a slimmed down packet_builder for each channel.  The multichannel
multiplexing would be similar in either design.

### Packet Push:

Packet buffers only, packets built on channel input.

This design pushes preformed packets into a packet FIFO, simply to be to be
read out via USB as is.

Multiple rxclk ticks would be required while writing the header information
to the FIFO, which limits our maximum sample speed.
(I think) Without any channel buffering, the maximum sample rate would be
1/6 master clock, since we need 4 additional master cycles to push out the
header before the first sample of a packet.  Maybe that is an issue, maybe
not.

1. New packet begins, I/Q samples waiting, save metadata, write headerH
2. Write headerL
3. Write timestampH
4. Write timestampL
5. write I
6. write Q

### Packet Pull:

Channel buffering only, packets built on USB read.

This design uses a separate FIFO/s for packet metadata (timestamp, etc)
parallel to the channel FIFO.  The actual packets are constructed via the
USB read process.  The metadata FIFO/s would be pretty shallow, as they are
1 write per packet.

This design should theoretically be able to read samples at master_clock
rates.  While the USB/host couldn't stream that, if operated on short burst
reads (less than the FIFO capacities), it could increase our maximum
sampling speeds.

Also, since the header isn't built until read, there is the possibility to
include information in the header that is not available at the first sample.
E.g.:  

* Packet size: don't need to know size in advance, read could be
interrupted, and the size can be adjusted on USB read.
* RSSI: e.g. peak, avg, last, etc.
* Padding: padding would be virtual space, not FIFO space.  Just send 0,
don't store them.

In general, it seems to me that the packet pull design offers more
performance and flexibility.  Unless someone points out some flaws in my
reasoning, I will proceed on that path.


--ets