Re: [Discuss-gnuradio] Timestamps, data rates

[Eric Blossom]

On Tue, Apr 14, 2009 at 02:19:38PM -0500, Douglas Geiger wrote:
>  I'm running some experiments with my two USRP2's - as I want to get
> synchronized samples out of them. I have the clock's locked to my
> external 10Mhz, and they sync_to_pps correctly (i.e. the timestamp
> resets on the next PPS).
>  However, the difference between timestamps from the two USRP2's does
> not seem to be a constant at low data rates: they are constant between
> subsequent received frames (i.e. USRP2 A vs. USRP2 B) - but each time I
> start my application, or even if I send sync_to_pps commands while
> streaming, the difference changes. I'm trying to figure out if this is
> due to some non-deterministic timing on the USRP2, or some other source.
>  At higher data rates (e.g. decimation <= 16), the difference between
> timestamps from the two USRP2's gets more erratic, and tends to
> fluctuate (quite wildly down at -d 4).

Doug,

I wouldn't expect the time stamps in the streams to start at the same
point (the start_rx_streaming command doesn't accept a "start at
time T argument).  I would expect that there is a constant delta_t
between subsequent frames, and that that delta_t would be the same for
both of the USRP2s.

At -d 4 you are likely to be getting overruns (indicated by an 'S'
(sequence error) on stderr).  That is, the host can't keep up.

Are both USRP2's connected to the same host?
If so, are they each connected to their own dedicated ethernet port,
or are they connected to a switch that feeds a single ethernet port?

If both USRP2s are connected to a single machine, and even if they are
connected to dedicated ethernet ports, I'd be pleasantly surprised if
you could run -d 8 on both of them.  I doubt the problem is in the
USRP2 firmware; the overhead of the host code and lack of sufficient
horsepower on the host is almost certainly the bottleneck.

>  My plan has been to setup buffers to align samples based on timestamp -
>  but with such variations it looks to me like it could be quite
> difficult to implement. Or at the very least, I'd need very large
> buffers, and could end up needing/wanting to change their size often.
>  Any suggestions on how to best deal with this? Should I be looking into
> the USRP2 firmware code to try to get some more predictable behavior out
> of it?
>  Thanks,
>   Doug

Doug, assuming that the host can keep up without overruns, aligning
samples from the two USRP2s should be no big deal.  I wouldn't expect
that you need more than 200 ms of buffer.  If the host isn't keeping
up, all bets are off.

I'd start with something like -d 64 of each of them, get that working,
then start reducing the decimation rate until you get failures.  Then
go after those.

Eric