[Fwd: Re: [Discuss-gnuradio] Timestamps, data rates]

[Douglas Geiger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forgot to copy the list:

Eric Blossom wrote:
> On Tue, Apr 14, 2009 at 02:19:38PM -0500, Douglas Geiger wrote:
>
> 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.

 Right - I'd actually like to figure out what is required to implement
such a 'start at time T' call now - I realize this may be changed with
the usrp-vita transition, but if I can get it working now I think that
would make things easier for me. From my brief look at the firmware
where starting RX streaming is handled, this is not currently
implemented: so the firmware code would need this functionality added,
in addition to a call added on the host code. It looks like I would need
to be touching the start_rx_streaming_cmd in txrx.c in the firmware -
not sure where else I'd have to go though.

> 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.

 I have two gig-e ports on my machine, each connected to a USRP2
(through a dedicated gig-e switch) - it's a pretty hefty 8-core xeon
machine. I'm not seeing overruns with my experiments at the highest data
rates (at least not with this code).
 I do still have a nagging issue with the not-entirely constant delta
(between the two USRP2's): i.e. it will be constant for a long run of
received frames, then the delta will change, and be constant for a time,
then change again. I'm updating to the latest 3.2 release candidate now,
and will try updating with fresh firmware/fpga code, and see if that's
still the case (I'm talking about -d 128 or 512 here - no
overrun/sequence errors reported).

>
> 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

 As you suggest - I'm looking to get this working with low data rates
(-d 512, 128, etc.) and then moving down to the high rates (-d 4 is
where I need to get). Of course, 200ms of buffer at -d 4 is 5Ms, and
with 16-bit, complex samples (4 bytes/sample) that's ~19MB of buffer,
per USRP2. I do have plenty of RAM on this machine, but that still seems
a little extreme. Getting a quick and dirty 'rx_at_time' seems like a
better solution to me. Although perhaps implementing the buffers, and
doing the alignment on the host would be quicker to get done. This would
also catch the cases where the delta changes occasionally, like I've
seen. Perhaps the best solution long-term is a combination of both
(rx-at-time, and aligning on the host).

Thanks,
  Doug



- --
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
address@hidden
address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ53v8gfOzzR5bXIgRAuc+AJ91Tgqxg/f5/V5fzRuHIzJCd6oYTACgnePu
PQMjT0MpoUzeKC4YGJqmdxA=
=wLwZ
-----END PGP SIGNATURE-----