Re: [Discuss-gnuradio] packet interarrival time

[Veljko Pejovic]

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 Pejovic <address@hidden>:
> Hi Eric,
>
> 2010/2/12 Eric Blossom <address@hidden>:
>> On Fri, Feb 12, 2010 at 12:52:00PM -0800, Veljko Pejovic wrote:
>>> 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?
>>
>> 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
>