Timestamps, data rates

GNU Radio
1

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

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).
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 G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ5OHKgfOzzR5bXIgRAlkzAJ9PJBBrzXgvgi7ZxFaFz96IZal28ACghE+D
LtLDt7yvoHqnThKVUGv2CQ8=
=j2wh
-----END PGP SIGNATURE-----

2

On Tue, Apr 14, 2009 at 02:19:38PM -0500, Douglas G. wrote:

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

3

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.

How accurate is sync_to_pps? Can you do MIMO with just sync_to_pps
(assuming your cables are equal length)?

Off topic: We have been playing around with my USRP2 and it seems very
nice. I noticed that even though the FAQ strongly discourages
connecting the USRP2 to your main network, it does actually work. We
have a fairly large LAN and I assume that the USRP2 could possibly
flood the network when doing 25 MHz. Is there any other reason for not
just putting the USRP2 in your LAN?

juha

4

Just a note from my experience with the USRP2 on our LAN, we didn’t see
any
problems initially, but something changed around RC1 that seriously
disabled
LAN clients/switches in the immediate physical segment. We didn’t look
into
any further yet, but it was an instantaneous effect upon attaching a
USRP2
running that RC1 firmware, even before any data collection has begun.

5

On Thu, 2009-04-16 at 15:13 +0000, Juha V. wrote:

How accurate is sync_to_pps? Can you do MIMO with just sync_to_pps
(assuming your cables are equal length)?

Yes. Two USRP2s synced to the same 10 MHz reference and PPS will have
sampling times accurate to the PPS arrival time, and will have precisely
100M samples per second.

Is there any other reason for not just putting the USRP2 in your LAN?

Aside from bringing your network to its knees, the USRP2 receive side
does not implement any sort of flow control, and has a fairly small
packet buffer. So, especially at higher data rates, it is possible for
side traffic to cause missing packets at the host PC.

Similar issues exist on the transmit side.

That being said, the USRP2 will otherwise work just fine sitting on a
switch and not being directly connected to the host. In fact, it is
possible to use it at low data rates with a host PC that does not have
GbE ports by plugging both the USRP2 and the PC into a switch that does
100/1000 auto-sense.

Finally, the USRP2 uses Ethernet directly and does not use IP, so it
must be in the same layer 2 broadcast domain as the host PC.

So it is possible, but not recommended.

Johnathan

6

On Thu, Apr 16, 2009 at 08:34:25AM -0700, Johnathan C. wrote:

Similar issues exist on the transmit side.

Actually they are quite different. When we assert flow control, we flow
control everything upstream between the USRP2 and the host. Unless
you want your network to die, die, die, don’t put a switch between
the USRP2 and the host if you are transmitting, and for sure, don’t
plug anything else into the switch.

You may find corner cases where it might work, but it’s highly
dependent on what kind of switch, how much buffering it has, how the
switch was instructed to negotiate flow control etc. There are big
portions of the Internet universe that consider it “evil” for an end
point to assert flow control. That’s what we do.

For all the gory details on this, see a good reference on Gigabit
ethernet flow control. I found Rich Seifert’s, “Gigabit Ethernet:
Technology and Applications for High-Speed LANS” useful. You could
also read the GigE ethernet spec.

Eric

7

On Thu, Apr 16, 2009 at 03:13:51PM +0000, Juha V. wrote:

Off topic: We have been playing around with my USRP2 and it seems very
nice. I noticed that even though the FAQ strongly discourages
connecting the USRP2 to your main network, it does actually work. We
have a fairly large LAN and I assume that the USRP2 could possibly
flood the network when doing 25 MHz. Is there any other reason for not
just putting the USRP2 in your LAN?

If you are receive-only, there’s a pretty good chance it’ll work, even
if there’s a switch in between. When transmitting, we are using
ethernet PAUSE frames to provide backpressure to the host. Whether
this works through switches is depends on a lot of things that we
don’t have any control over. Thus our recommendation to connect the
USRP2 directly to the host on a dedicated port.

Eric

8

Similar issues exist on the transmit side.

Ok.

Actually they are quite different. When we assert flow control, we flow
control everything upstream between the USRP2 and the host. Unless
you want your network to die, die, die, don’t put a switch between
the USRP2 and the host if you are transmitting, and for sure, don’t
plug anything else into the switch.

Mental note to self: unplug USRP from campus-wide LAN first thing
tomorrow. I just checked and I could find_usrps my USRP2 from home,
and I’m on a 100 Mbit hub, 1 km away from work, on the same large
LAN.

I guess I’ll then go for a PCI Express card with many independent
ethernet interfaces. I just would’ve been so practical to just plug
USRP2s into a switch.

How about overflows. What is the probability that a USRP2 will drop
samples guring 24 h of 10 MHz receiving when connected directly to a
computer? I guess there is no mechanism that guarantees that the data
is delivered, but there has to be a mechanism that guarantees that you
know if samples have been lost?

For all the gory details on this, see a good reference on Gigabit
ethernet flow control. I found Rich Seifert’s, “Gigabit Ethernet:
Technology and Applications for High-Speed LANS” useful. You could
also read the GigE ethernet spec.

I’ll try to look this up. but I think I’m mentally about six-seven
layers above or below this stuff in the OSI model :wink:

juha

9

On Thu, Apr 16, 2009 at 09:05:50PM +0000, Juha V. wrote:

How about overflows. What is the probability that a USRP2 will drop
samples guring 24 h of 10 MHz receiving when connected directly to a
computer? I guess there is no mechanism that guarantees that the data
is delivered, but there has to be a mechanism that guarantees that you
know if samples have been lost?

Not right now, though if you’re looking at the timestamps you’ll see a
discontinuity.

Eric