Hi,
I’m using two USRP2 with XCVR2450s, gnuradio 3.2.2 and Ubuntu 9.10.
I ran the benchmark_tx/rx example from gnuradio-examples/ofdm and
measured packet inter-arrival times at the receiver. I also modified
the sender to wait for some time (like 200ms) between individual
packets. I also set the msg queue size to one. In python code I’m
printing a bunch of time.time() values to keep the timeline of the
events.
What I observe is the following:
- inter-departure times are constant, the packet size and the bit rate
would of course influence the time spent sending, but that would still
be a relatively small value.
- at the receiver, most packets are received with the inter-arrival
time comparable to the inter-departure time at the sender, however,
occasionally I would see a huge lag between two consecutive packets
(almost a second).
I read the NSDI’09 paper
(http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1
performance, however, what I observe is way higher delay and it’s
USRP2. Thus, I’m sure that there’s something I can do to fix this
delay. Any hints?
Cheers,
Veljko
On Fri, Feb 12, 2010 at 12:52:00PM -0800, Veljko P. wrote:
(http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1
performance, however, what I observe is way higher delay and it’s
USRP2. Thus, I’m sure that there’s something I can do to fix this
delay. Any hints?
Are packets getting dropped?
Is the USRP2 on a dedicated ethernet port?
Is there a switch between the host and the USRP2?
Eric
I narrowed down the problem to this:
-
In a standard benchmark_rx.py example from “digital” immediately
after a packet is received the callback is triggered.
-
In the ofdm case the the callback is triggered in groups separated
by one second. So, if a sender sends a bunch of packets they will be
buffered at the receiver (or perhaps at the sender?) and then the
callback is issued sequentially for each of the packets in that group.
Then, after a one second gap, another group of packets will be
processed.
I checked the times of when “msg = self.rcvd_pktq.delete_head()” from
ofdm.py is called and confirmed the above. Sometimes it waits for a
second, and then it gets fired in a number of bursts corresponding to
the number of pkts received.
Is there a way to force the receiver to wait for less then a second?
Or is it the sender that buffers the packets? Although, it doesn’t
look like that from my measurements.
Thanks,
Veljko
2010/2/12 Veljko P. [email protected]:
On Sat, Feb 20, 2010 at 01:43:24PM -0800, Veljko P. wrote:
processed.
Thanks,
Veljko
Are you sure that the transmitter is transmitting continuously, or is
it transmitting a group of packets once per second?
The simplest way to check this is to watch with a spectrum analyzer.
It’s unlikely that there is any code in the receiver that is holding
back the processing of the packets.
Eric
Hi Eric,
2010/2/12 Eric B. [email protected]:
events.
I read the NSDI’09 paper
(http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1
performance, however, what I observe is way higher delay and it’s
USRP2. Thus, I’m sure that there’s something I can do to fix this
delay. Any hints?
Are packets getting dropped?
I don’t get any overruns/underruns reported, but, yes, there’s some
packet loss. However, I’m only considering the interarrival time of
those packets with consecutive packet numbers.
Is the USRP2 on a dedicated ethernet port?
yes, it is.
Is there a switch between the host and the USRP2?
no
Eric
cheers
Veljko