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

[Jordan Otomo]

I think the problematic block might be the FLL used in the PSK demodulator.  I 
haven't looked into the issue very deeply, but I have confirmed that given the 
same input parameters, the FLL from 3.4.2 works fine, while the 3.5.0 version 
causes a lot of overruns.

Jordan

On Nov 4, 2011, at 12:18 PM, Josh Blum wrote:

> 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
>>>> 
>>> 
>>> 
>> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio