[USRP-users] Problems with "uhd::set_thread_priority_safe"

Marcus D. Leech patchvonbraun at gmail.com
Wed Jul 1 11:25:54 EDT 2020


On 07/01/2020 12:24 AM, Nando Pellegrini wrote:
>
> Marcus,
> Believe me! i have been spending a life in the software field as 
> software engineer and quite familiar since when the CPUs were made of 
> discrete components to the multi cpu chips we are using today .
> Just to explain to you i''ll tell what makes the difference, the first 
> try i made was  running perfectly at 56Mhz bandwidth (max possible 
> with a B200) then i have been updating Linux and the main change was 
> the kernel because someone had the bright idea of distributing the 
> Linux 20 kernel also into Linux 18 and the fact that a function return 
> a good value does not mean that the execution was doing what expected 
> (especially with Linux).
Generally, if a *kernel* function returns a "success" code, it has done 
what you asked it to do.  There are exceptions, but for the most part,
   care is taken in kernel code to return meaningful information about 
whether the requested operation succeeded.  To not do so would lead
   to a huge amount of chaos.

I've been involved with Unix and Linux since 1979, and have been a 
kernel developer on-and-off since then.
> That probably means that the error is inside Linux but what i see as 
> not working is an Ettus function.
> Jut to convince you all most any benchmark i made was very favorable 
> to the laptop compared with the tower.
> nando
You can follow the code yourself:

..../uhd/host/lib/utils/thread.cpp

It doesn't do anything particularly magical or "going below the C 
library" (your quote).   It just calls standard OS functions, and 
pthread functions.

You can set that if uhd::set_thread_priority_safe returns 'true' (1), 
then the underlying functions have NOT raised an exception. Since those
   exceptions would result in a print-out, then as far as UHD is 
concerned the thread priority has been set as asked for.

You can use ps -m -l [PID]  to look at the priorities of your threads on 
a particular process to confirm your priority setting.

Not sure what you mean by "Linux 18" and "Linux 20" -- are you referring 
to Ubuntu?

Moving an application to a new piece of hardware and new OS can have 
surprising performance "hits", even when moving to
   notionally-better hardware.  The main culprit is often the USB3 
controller--what kind do you have on your laptop--it may simply
   not be "good enough" to move more than 40Msps out of your USRP.

What does:

lspci -v |grep -i usb

Show?

What does:

uname -a

Show?

Also, and you STILL haven't answered this:   are you using 
"num_recv_frames" in your device argument?






> On 6/30/2020 20:36, Marcus D. Leech wrote:
>> On 06/30/2020 12:09 PM, Nando Pellegrini wrote:
>>> Unfortunately no, actually the return code is 1 (true)  which 
>>> usually means all OK!
>> Yes, so, it's not a thread-priority issue.
>>
>> Have you set your CPU(s) on your laptop to "Performance" mode?
>>
>> Again, what is your device argument when you create the UHD device?  
>> Are you using larger USB buffers (via num_recv_frames?)
>>
>> What type of CPU is your laptop?  (You can copy/paste the output of:  
>> cat /proc/cpuinfo)
>>
>>
>>>
>>> On 6/30/2020 17:55, Marcus D. Leech wrote:
>>>> On 06/30/2020 11:36 AM, Nando Pellegrini wrote:
>>>>> Thanks Marcus for the suggestion but....
>>>>> I am not a real an expert of Linux but i know that the standard c 
>>>>> library which i knew since the Unix time does not work anymore and 
>>>>> that's because  Ettus research provided a special interface 
>>>>> (working at a level lower than the clib).
>>>>> I am also confident in the identification of the problem because 
>>>>> if i remove the call to the Ettus function from the old tower 
>>>>> system (which is slower then the new laptop) that is exactly 
>>>>> what's happening.
>>>>> To complete the story and since i know that you too are involved 
>>>>> in pulsar detection. I suspended my astronomic activity few years 
>>>>> ago because of the big rfi from radar, now i implemented what i 
>>>>> believe could be a good rfi mitigation done on the fly and
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Monday, June 29, 2020 at 10:41:09 AM UTC-4, Eric Ross wrote:
>>>>>>
>>>>>>     I am helping my 13 and 15 year old daughters build a
>>>>>>     hydrogen-line 21-cm telescope for a Milky Way study (training
>>>>>>     the next generation of scientists: they are doing all the
>>>>>>     work and I am an advisor). We had our first complete system
>>>>>>     test yesterday (image below) but question the results. We'd
>>>>>>     appreciate any advice you might be able to provide us.
>>>>>>
>>>>>>     We first tested our SDR/system with an FM antenna at FM
>>>>>>     frequencies to make sure the software/collection/SDR worked
>>>>>>     (which it did). We then connected our home-built 1.7m
>>>>>>     Yagi-Uda antenna and as a test yesterday obtained spectra of
>>>>>>     the sun (pointed directly at the sun). And it appears we
>>>>>>     obtained some kind of signal at roughly 1.4024 GHz when
>>>>>>     pointed directly at the sun which is roughly what we
>>>>>>     expected. We also checked to make sure by pointing the
>>>>>>     antenna 90 degrees away from the sun in multiple directions
>>>>>>     (virtually zero signal, but a tiny amount), disconnecting
>>>>>>     power to the LNA (no signal we could discern from the noise)
>>>>>>     and disconnecting the antenna completely (just noise). So it
>>>>>>     would seem we are obtaining some sort of real signal of the sun.
>>>>>>
>>>>>>     However, in my naivete I had expected at best we might obtain
>>>>>>     a wide blob spectra at 1.420405 GHz. But instead we obtained
>>>>>>     multiple distinct spectral lines around 1.420405 GHz but none
>>>>>>     exactly on the expected midpoint. Also, they were strong but
>>>>>>     "intermittent" (i.e. they were mostly present, but then
>>>>>>     disappeared for short times) -- you can see the waterfall
>>>>>>     spectra in blue/yellow. These aren't averaged signals: the
>>>>>>     chart is just raw in from the SDR (I assume if we average the
>>>>>>     signals we'd get very nice signal/noise but very sharp peaks
>>>>>>     at the same frequencies not exactly at 1.420405 GHz).
>>>>>>
>>>>>>     So are these actual signals? (I hope they are because I can't
>>>>>>     explain them otherwise.) Are the separate lines simply some
>>>>>>     sort of ringing or harmonics around a midpoint or issue with
>>>>>>     our electronics or antenna? -- something we can/should fix?
>>>>>>     Any advice you might have for us? -- we're excited to move to
>>>>>>     the next step (night observations ideally of the Milky Way)
>>>>>>     but want to understand/fine-tune our equipment and results first.
>>>>>>
>>>>>>     Thank you for your expertise.
>>>>>>
>>>>>>
>>>>>>     (if the below chart is difficult to read, the spectra starts
>>>>>>     at 1,420.0 MHz on the far left and goes by 0.2 MHz
>>>>>>     increments, ending at 1,421.8 MHz on the far right.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> -- 
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Society of Amateur Radio Astronomers" group.
>>>>>> To post to this group, send email to sara-list at googlegroups.com
>>>>>> To unsubscribe from this group, send email to
>>>>>> sara-list-unsubscribe at googlegroups.com
>>>>>> For more options, visit this group at
>>>>>> http://groups.google.com/group/sara-list?hl=en
>>>>>> ---
>>>>>> You received this message because you are subscribed to the 
>>>>>> Google Groups "Society of Amateur Radio Astronomers" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>> send an email to sara-list+unsubscribe at googlegroups.com 
>>>>>> <mailto:sara-list+unsubscribe at googlegroups.com>.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/sara-list/f16f93bf-9df1-48dc-80c4-7f2293aeddbbo%40googlegroups.com 
>>>>>> <https://groups.google.com/d/msgid/sara-list/f16f93bf-9df1-48dc-80c4-7f2293aeddbbo%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>> practically wiping away all the radar signals touching only 2-3% 
>>>>> of the samples to discovery that i had a very high background 
>>>>> noise coming from the tower PC.
>>>>> That's why i am making an attempt with a laptop of last generation.
>>>>> Glad to hear from you, my best wishes and hope to have some pulsar 
>>>>> news shortly.
>>>>> nando
>>>>>
>>>> Are you getting an error message about set_thread_priority_safe not 
>>>> working?  It usually gives you a warning if it doesn't work.
>>>>
>>>> If so, you need to make certain that your user is in group "usrp", 
>>>> and that
>>>>
>>>> /etc/security/limits.conf contains a line:
>>>>
>>>> @usrp  - rtprio 50
>>>>
>>>>
>>>> But my *suspicion* is that this won't help.
>>>>
>>>> You may need to add:
>>>>
>>>> num_recv_frames=128
>>>>
>>>> To your device argument string.
>>>>
>>>> Also, does the laptop have a real USB3 port?  Are you using the 
>>>> default sample width of 16-bits?
>>>>
>>>>
>>>>>
>>>>> On 6/30/2020 17:00, Marcus D. Leech via USRP-users wrote:
>>>>>> On 06/30/2020 06:38 AM, Nando Pellegrini via USRP-users wrote:
>>>>>>> I am a B200mini user since few years used for radio astronomy 
>>>>>>> observations with home made software. No trouble so far.
>>>>>>> I decided now to move to a new laptop PC running Ubuntu 18.4 
>>>>>>> with latest update (kernel 5.3.0-61) , after porting my software 
>>>>>>> i am not able to receive anything above 40M samples /sec without 
>>>>>>> dropping in overflow error.
>>>>>>> I suspected that the setting of high priority was not running 
>>>>>>> anymore.
>>>>>>> I tried a short code  loop of receiving streamed blocks from 
>>>>>>> B200 (a single thread coding) and with or without issuing 
>>>>>>> "uhd::set_thread_priority_safe" the result was the same 
>>>>>>> (overflow after a number of blocks received very variable) much 
>>>>>>> different that previous installation being able to receive and 
>>>>>>> handle 56 samples/sec.
>>>>>>> I could not find any way to check the real priority via c++ or 
>>>>>>> available tools.
>>>>>>> Any help/suggestions very appreciated.
>>>>>>> Nando Pellegrini
>>>>>>>
>>>>>> Nando:
>>>>>>
>>>>>> It's unlikely that scheduling priority has much to do with your 
>>>>>> problems, but here's is the MAN page for getpriority()
>>>>>>
>>>>>> https://man7.org/linux/man-pages/man2/getpriority.2.html
>>>>>>
>>>>>>
>>>>>> What device arguments are you using?  Are you using the 
>>>>>> "num_recv_frames" argument?
>>>>>>
>>>>>> You note a move to a new laptop.  What are its specs?
>>>>>>
>>>>>> The performance of your application depends on a LOT of factors, 
>>>>>> including things like what kind of USB controller you have, how 
>>>>>> fast the
>>>>>>  CPU is, how fast the memory interface is, etc, etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users at lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200701/205d6346/attachment.html>


More information about the USRP-users mailing list