Re: [Discuss-gnuradio] Strange behavior in digital benchmark examples

[Josh Blum]

I am not seeing the same buffering issues with GMSK. I' am guessing that
the recent work on gr-digital may have accidentally messed up our d*psk
blocks. Maybe massive filter coefficients are being calculated?

When Tom gets back I think he can offer some insight.

Can you try/compare the GMSK mod/demod blocks instead?

-Josh

On 11/03/2011 08:52 PM, Tuan (Johnny) Ta wrote:
> Just a thought. Could this be the overhead of the new stream tags? Since I
> didn't see it before.
> 
> On Thu, Nov 3, 2011 at 10:23 PM, Tuan (Johnny) Ta <address@hidden>wrote:
> 
>> Josh,
>>
>> I've upgraded to 3.5rc0. The same thing happened. I got some more details:
>>
>> When I ran benchmark_tx on 1 machine, at low bitrate (0.1Mbps or 0.2MSps -
>> I'm using bpsk) the CPU utilization is roughly 9%.
>> But the receiver, running benchmark_rx showed 110% CPU utilization.
>>
>> If I up the bitrate to 1Mbps,
>> the transmitter showed 90% CPU utilization so it scaled linearly.
>> the receiver starts out showing 110% CPU utilization, so I guess it
>> processed noise also, which makes sense because there's no carrier-sense.
>> It did nothing for a while (~30 sec), then started showing correct
>> receptions. Until a point, it started to show overrun. Here's part of the
>> output on the receiver:
>>
>> ok =  True  pktno =  859  n_rcvd =  859  n_right =  859
>> ok =  True  pktno =  860  n_rcvd =  860  n_right =  860
>> ok =  True  pktno =  861  n_rcvd =  861  n_right =  861
>> ok =  True  pktno =  862  n_rcvd =  862  n_right =  862
>> ok =  True  pktno =  863  n_rcvd =  863  n_right =  863
>> ok =  True  pktno =  864  n_rcvd =  864  n_right =  864
>> ok =  True  pktno =  865  n_rcvd =  865  n_right =  865
>> ok =  True  pktno =  866  n_rcvd =  866  n_right =  866
>> ok =  True  pktno =  867  n_rcvd =  867  n_right =  867
>> Ook =  True  pktno =  868  n_rcvd =  868  n_right =  868
>> OOOok = False  pktno =  869  n_rcvd =  869  n_right =  868
>> OOOOOOOok = False  pktno =  879  n_rcvd =  870  n_right =  868
>> OOOOOOOOOok = False  pktno =  902  n_rcvd =  871  n_right =  868
>> OOOOOOOok = False  pktno =  914  n_rcvd =  872  n_right =  868
>> OOOOOOOOok = False  pktno =  929  n_rcvd =  873  n_right =  868
>> OOOOOOOOOOOok = False  pktno =  950  n_rcvd =  874  n_right =  868
>> OOOOOOOOOOOOOOOok = False  pktno =  970  n_rcvd =  875  n_right =  868
>> OOOOOOOOOOOOOOOOOOOOOOOOOOok = False  pktno =  983  n_rcvd =  876  n_right
>> =  868
>> OOOOOOOok = False  pktno =  987  n_rcvd =  877  n_right =  868
>> OOOOOOok = False  pktno =  990  n_rcvd =  878  n_right =  868
>> OOOOOOok = False  pktno =  993  n_rcvd =  879  n_right =  868
>> OOOOOOok = False  pktno =  996  n_rcvd =  880  n_right =  868
>>
>>
>> Another thing is when I started the transmitter first, then the receiver
>> started to show received samples right away. If I started the receiver
>> first, then it had the 30 sec delay mentioned above.
>>
>> Before I used to run these code on the old gnuradio version (3.2.2) and
>> Ethernet driver and didn't have this problem. Could this be related to the
>> new implementation of gnuradio and/or the UHD driver? Or is there any other
>> possible explanation?
>>
>> Thank you,
>> Johnny
>>
>>
>> On Thu, Nov 3, 2011 at 4:54 PM, Josh Blum <address@hidden> wrote:
>>
>>>
>>>
>>> On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:
>>>> Hello all,
>>>>
>>>> I just came across a strange behavior in the digital benchmark examples
>>>> that I haven't seen before. The transmitter wouldn't stop itself after
>>> it
>>>> finishes sending the requested data size (specified by -M argument).
>>>> Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z
>>> and
>>>> kill the job after.
>>>>
>>>> This behavior starts when bitrate exceeds 1M.
>>>>
>>>> If I ran benchmark_rx2.py then a short period after receiving all
>>> packets
>>>> (~30 sec), the receiver would continuously spill out "O" (overrun). This
>>>> didn't happen if I ran benchmark_rx.py. (I ran the corresponding tx
>>> code.)
>>>>
>>>> I'm not sure what could be causing it. I was able to run digital
>>> benchmark
>>>> code on my older machine at 1.5Mbps prior to UHD (I used Ethernet
>>> driver)
>>>> so I'm sure CPU speed isn't a problem.
>>>>
>>>> To make it work with UHD driver, I made some changes to the
>>> usrp_options.py
>>>> and generic_usrp.py.
>>>>
>>>
>>> I believe that tom ported all of the gnuradio "classic" example
>>> applications in 3.5 release. You may want to try those examples, because
>>> I know that he has tested them recently.
>>>
>>> I hope that helps,
>>> -Josh
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>