Packet interarrival time

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs