Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Rfnoc siggen offset freq (Tobias Mitterer)
2. Re: Rfnoc siggen offset freq (Jonathon Pendlum)
3. Announcing NEWSDR at Tufts University on Thr/Fri June 1/2
(Neel Pandeya)
4. Re: High CPU usage (Vladica Sark)
5. Re: High CPU usage ([email protected])
6. Re: High CPU usage (Vladica Sark)
7. Fwd: E310 filter configuration (Yake Li)
8. Re: High CPU usage ([email protected])
9. Re: High CPU usage (Vladica Sark)
10. Re: High CPU usage (Vladica Sark)
11. Re: High CPU usage ([email protected])
12. Re: High CPU usage (Vladica Sark)
----------------------------------------------------------------------
Message: 1
Date: Wed, 10 May 2017 18:51:11 +0200
From: "Tobias Mitterer" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Rfnoc siggen offset freq
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello everyone,
Idk if anyone else noticed the same problem but I found the source. It was
in the phase_accum.v file and originated in the rounding of the phase_inc
value in combination with the phase jump at +-Pi. This resulted in a linear
increase of the max phase value which resulted in the behaviour in the time
domain I saw in my plots.
Btw, sorry for the html in my previous e-mails, I sent them from my phone
where the app did not allow to use plain text.
I have an additional question, is it normal and intended behaviour that when
sending a complex signal through the rfnoc:radio block over an LFTX
daughterboard, that the Real part of the signal is being sent on one channel
of the board and the Imaginary part of the signal is being sent on the other
channel ?
Thanks in advance for the help,
Tobias
------------------------------
Message: 2
Date: Wed, 10 May 2017 12:54:46 -0500
From: Jonathon Pendlum <[email protected]>
To: Tobias Mitterer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rfnoc siggen offset freq
Message-ID:
<CAGdo0uRAK5Ne95qfQ_1qVOyuvkjzrxp-g=zMQkajdTv_O=s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tobias,
Pleaes feel free to send me a patch or PR if you have a fix for your issue
with phase_accum.v.
It is expected to have I and Q come out on TX A and TX B on the LFTX, those
correspond with the I/Q outputs of the DAC (with some signal conditioning).
Take a look at our X3xx schematic:
https://files.ettus.com/schematics/x300/x3xx.pdf and the LFTX schematic:
http://files.ettus.com/schematics/lftx/lftx.pdf
Jonathon
On Wed, May 10, 2017 at 11:51 AM, Tobias Mitterer via USRP-users <
[email protected]> wrote:
> Hello everyone,
>
> Idk if anyone else noticed the same problem but I found the source. It was
> in the phase_accum.v file and originated in the rounding of the phase_inc
> value in combination with the phase jump at +-Pi. This resulted in a linear
> increase of the max phase value which resulted in the behaviour in the time
> domain I saw in my plots.
>
> Btw, sorry for the html in my previous e-mails, I sent them from my phone
> where the app did not allow to use plain text.
>
> I have an additional question, is it normal and intended behaviour that
> when
> sending a complex signal through the rfnoc:radio block over an LFTX
> daughterboard, that the Real part of the signal is being sent on one
> channel
> of the board and the Imaginary part of the signal is being sent on the
> other
> channel ?
>
> Thanks in advance for the help,
> Tobias
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20170510/51ba7303/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 10 May 2017 11:57:18 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Announcing NEWSDR at Tufts University on Thr/Fri
June 1/2
Message-ID:
<CACaXmv9Din40f0RF25MoyW0GCgR_mr9y_sG625CsXtcdHA=s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*********************************************************************
CALL-FOR-PARTICIPATION
*********************************************************************
NEWSDR 2017
New England Workshop on Software Defined Radio
Seventh-Annual
Evening Workshops
Thursday June 1
17:30 to 21:00
Day-Long Symposium
Friday June 2
08:00 to 16:00
Tufts University
Medford, MA, USA
http://www.sdr-boston.org/
Free Pre-Registration
Pre-registration deadline is Friday May 19
Poster Submissions and Pre-Registrations
Accepted Until Friday May 19
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2017 New England Workshop on
Software Defined Radio (NEWSDR 2017), which is the seventh installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).
This year, NEWSDR will be held at Tufts University, and consists of
a day-long symposium on Friday, as well as several hands-on technical
workshops the evening before on Thursday. You are welcome to attend
either or both events, which are entirely free when pre-registering.
Attendance is typically about 100 people, and attendees are evenly
split between academia and industry.
*********************************************************************
EVENING WORKSHOPS
THURSDAY JUNE 1
17:00 to 21:00
Tufts University
Medford, Massachusetts
AGENDA
16:00 ? 17:30 Setup session for the Workshop Events (optional)
17:30 ? 21:00 Workshop Events
Two hands-on technical workshops are being offered in parallel:
* "SDR Using USRP E310 and Simulink"
by MathWorks
* "FPGA Programming on the USRP with the RFNoC Framework"
by Ettus Research
MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops is listed below. Attendance is free, but
pre-registration is required. Free pizza and soda will be provided.
*********************************************************************
DAY-LONG SYMPOSIUM
FRIDAY JUNE 2
08:00 to 16:00
Breed Memorial Hall
Tufts University
51 Winthrop Street
Medford, Massachusetts
AGENDA
07:30 to 08:00 Coffee and Light Refreshments
08:00 to 08:15 Welcome and Introduction
08:15 to 09:40 Sponsor Overview Presentations (20 minutes each)
09:40 to 10:15 Elevator-Pitch Oral Presentations
of Poster Presenters (2 minutes each)
10:15 to 10:45 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos
10:45 to 11:45 Industry Tutorial Presentation by MediaTek:
"Prototyping Next Generation Wireless Devices"
11:45 to 13:00 Lunch and Attendee Networking
13:00 to 14:00 Keynote Presentation by Professor Dennis Roberson
14:00 to 14:30 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos
14:30 to 15:30 Industry Tutorial Presentation by Analog Devices:
"ADALM-PLUTO SDR Prototyping with Matlab"
15:30 to 16:00 Closing Remarks, Best Poster Award, Announcements
Keynote Speaker:
* Professor Dennis Roberson, Illinois Institute of Technology
Technical Poster Presentations:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
Corporate Sponsors:
* Analog Devices
* Ettus Research
* MathWorks
* MediaTek Wireless
The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.
The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.
*********************************************************************
WORKSHOP DESCRIPTION
SDR with E310 using Simulink
MathWorks
This tutorial focuses on demonstrating modeling SDR-based designs in
MATLAB and Simulink, and configuring and deploying on the USRP E310.
Topics presented will include modeling communication systems using
Simulink, implementing radio I/O with E310 and Simulink, and
prototyping deployment with real-time data via HW/SW co-design.
Prior knowledge of programming Xilinx Zynq SoCs with MATLAB and
Simulink, and knowledge of communications systems and hardware design
are prerequisites.
Outline:
Model Communication system using Simulink:
* Model and simulate RF signal chain and communication algorithms.
* Overview of Software Defined Radio concepts and workflows.
* Simulate a communication system that includes a transmitter,
AD9361 transceiver, channel, and receiver (RF test environment).
Implement Radio I/O with E310 SDR and Simulink:
* Verify the operation of baseband transceiver algorithm using real
data streamed from the AD9361 into MATLAB and Simulink.
* Overview of System objects and hardware platforms.
* Perform baseband processing in MATLAB and Simulink on received
signal.
* Verify algorithm performance for real data versus simulated data.
Hardware-Software Co-Design for Software:
* Split and deploy Tx/Rx algorithms to PL and PS.
* Overview of Zynq HW/SW co-design workflow.
* Implement transmitter and receiver on PL/PS using HW/SW co-design
workflow.
* Download generated code to the ARM & FPGA, and tune system
parameters in real-time operation via Simulink.
*********************************************************************
WORKSHOP DESCRIPTION
FPGA Programming on the USRP with the RFNoC Framework
Ettus Research
Ettus Research's RFNoC (RF Network-on-Chip) software is meant
to decrease the development time for experienced FPGA engineers
seeking to integrate IP into the USRP signal processing chain.
RFNoC is the architecture for USRP devices that use Xilinx 7-series
FPGAs (E310, E312, X300, X310). RFNoC is built around a packetized
network infrastructure in the FPGA that handles the transport of
control and sample data between the host CPU and the radio. Users
target their custom algorithms to the FPGA in the form of
Computation Engines (CE), which are processing blocks that attach to
this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.
Prerequisites:
* Attendees are expected to bring their own laptops to the workshop.
The laptop should have a minimum of 4 GB memory, 60 GB of free disk
space, one Ethernet port available, and one USB 3.0 port available.
* Attendees are expected to install VirtualBox 5.1.18 or newer.
All necessary USRP hardware will be provided in the workshop.
Attendees do not need to bring any USRP hardware.
*********************************************************************
REGISTRATION
* Pre-register for the Symposium, or for the Workshop, or both
* Pre-registration is required, but is completely free
* Pre-registration takes less than 5 minutes
* Pre-registration includes free meals at the event
* Parking available
* You must pre-register online
* Attendance, meals, parking are all limited, so please
pre-register online as soon as possible to secure your spot
* Pre-registration deadline is Friday May 19
* See link at the bottom of this announcement to pre-register online
*********************************************************************
LINKS
Attendee Pre-registration:
https://goo.gl/Oy99HU
Poster Abstract Submission:
https://goo.gl/pJohKn
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170510/9ca3a53e/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 May 2017 13:00:59 +0200
From: Vladica Sark <[email protected]>
To: Claudio Cicconetti <[email protected]>,
[email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
So I measured the times where the cpu time is spent and that happens in
recv_async_msg(tx_md, 0.005), which is executed in a loop till async msg
is received .
Basically, 80% of the time is spent in waiting for the async msg.
Next what I tried is to run this in loop with a sleep of 1 ms and
timeout of 1 ms like:
recv_async_msg(tx_md, 0.001);
boost::this_thread::sleep(boost::posix_time::milliseconds(1));
The cpu usage is again 200%. It seems that a thread spawned by uhd in
the background is actively using the cpu.
From user perspective it seems hard to fix this. Obviously the uhd is
doing something in the background.
BR,
Vladica
On 10.05.2017 17:17, Claudio Cicconetti wrote:
> Dear Vladica,
> It sounds like you have an active wait in the tx threads.
>
> I suggest you double-check all loops and make sure they do not spin
> faster than intended.
>
> For instance, if you have something like:
>
> while (true) {
> // do something without blocking
> recv_async_msg(/* ... */); // [1]
> // do something without blocking
> }
>
> As I understand, you are assuming that [1] blocks, but if it does not
> then you have a problem because the CPU will be 100% on the loop.
>
> Same if you have other library/system calls that _should_ block but
> _may_ not due to any reason.
>
> Adding some log lines with a timestamp or measuring the function call
> times should point you straight to the issue.
>
> Best regards,
> Claudio
>
> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>> Hi,
>>
>> With 8 samples per burst and 0.195312 MSps, again 200% of processor usage.
>> Lower sample rate is not supported by the N210s.
>>
>> BR,
>> Vladica
>>
>>
>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>> What happens if you reduce the sample rate, say, to 10e3 samples per
>>> second?
>>> And what happens if you reduce the # of generated samples to a very low
>>> number, e.g., 8?
>>>
>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi,
>>>
>>> I have an app which transmits 8192 samples each 10 ms on two N210s
>>> which
>>> are combined together and seen as 2 channels. The samples are
>>> transmitted as timed samples. After the send command, I wait in
>>> recv_async_msg command, till the samples get transmitted and than I
>>> schedule a new transmission in 10 ms.
>>>
>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at 100%.
>>> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
>>> Of course, no signal processing is involved at this point, only ready
>>> samples are being transmitted.
>>>
>>> The machine has a i5 vPro processor with 4 cores.
>>>
>>> Any way to reduce this?
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Thu, 11 May 2017 13:22:06 +0200
From: [email protected]
To: Vladica Sark <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Dear Vladica,
Uhm, I don't think the UHD spawns threads in the background.
You should be able to verify this claim using, e.g., htop.
Anyway, your pattern is correct (= always worked fine for me). In other
words, if you do this in a loop:
1. prepare burst
2. send burst (with end-of-burst flag)
3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
the 3. waits for the specified timeout to occur, CPU is not busy
waiting.
Rather, a short timeout such as 1 ms should not be necessary since the
library call will return immediately after the ack indication is
received. For instance, I use 100 ms (likely copied from Ettus
examples).
Best regards,
Claudio
On 11.05.2017 13:00, Vladica Sark wrote:
> Hi,
>
> So I measured the times where the cpu time is spent and that happens
> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
> async msg is received .
>
> Basically, 80% of the time is spent in waiting for the async msg.
>
> Next what I tried is to run this in loop with a sleep of 1 ms and
> timeout of 1 ms like:
>
> recv_async_msg(tx_md, 0.001);
> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>
> The cpu usage is again 200%. It seems that a thread spawned by uhd in
> the background is actively using the cpu.
>
> From user perspective it seems hard to fix this. Obviously the uhd is
> doing something in the background.
>
> BR,
> Vladica
>
>
> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>> Dear Vladica,
>> It sounds like you have an active wait in the tx threads.
>>
>> I suggest you double-check all loops and make sure they do not spin
>> faster than intended.
>>
>> For instance, if you have something like:
>>
>> while (true) {
>> // do something without blocking
>> recv_async_msg(/* ... */); // [1]
>> // do something without blocking
>> }
>>
>> As I understand, you are assuming that [1] blocks, but if it does not
>> then you have a problem because the CPU will be 100% on the loop.
>>
>> Same if you have other library/system calls that _should_ block but
>> _may_ not due to any reason.
>>
>> Adding some log lines with a timestamp or measuring the function call
>> times should point you straight to the issue.
>>
>> Best regards,
>> Claudio
>>
>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>> Hi,
>>>
>>> With 8 samples per burst and 0.195312 MSps, again 200% of processor
>>> usage.
>>> Lower sample rate is not supported by the N210s.
>>>
>>> BR,
>>> Vladica
>>>
>>>
>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>> What happens if you reduce the sample rate, say, to 10e3 samples per
>>>> second?
>>>> And what happens if you reduce the # of generated samples to a very
>>>> low
>>>> number, e.g., 8?
>>>>
>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>> <[email protected] <mailto:[email protected]>>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have an app which transmits 8192 samples each 10 ms on two
>>>> N210s
>>>> which
>>>> are combined together and seen as 2 channels. The samples are
>>>> transmitted as timed samples. After the send command, I wait in
>>>> recv_async_msg command, till the samples get transmitted and
>>>> than I
>>>> schedule a new transmission in 10 ms.
>>>>
>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at
>>>> 100%.
>>>> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
>>>> Of course, no signal processing is involved at this point, only
>>>> ready
>>>> samples are being transmitted.
>>>>
>>>> The machine has a i5 vPro processor with 4 cores.
>>>>
>>>> Any way to reduce this?
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected] <mailto:[email protected]>
>>>>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
------------------------------
Message: 6
Date: Thu, 11 May 2017 14:05:07 +0200
From: Vladica Sark <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Claudio,
Please find attached the htop screenshot. The application of interest is
"loc_an".
Also the command:
pstree -p 3899
returns that there are 6 threads.
loc_an(3899)???{loc_an}(3904)
??{loc_an}(3905)
??{loc_an}(3906)
??{loc_an}(3907)
??{loc_an}(3908)
??{loc_an}(3909)
My program runs only one.
Here is how I prepare the burst.
tx_md.start_of_burst = true;
tx_md.end_of_burst = true;
tx_md.has_time_spec = true;
tx_md.time_spec = at_tm;
size_t num_tx_samps = tx_stream->send(&tx_frame_s_tm_filt.front(),
TX_BUF_SIZE, tx_md);
And activelly wait for recv_async_msg. I tried also with 100 ms of
timeout and no change.
BR,
Vladica
On 11.05.2017 13:22, [email protected] wrote:
> Dear Vladica,
> Uhm, I don't think the UHD spawns threads in the background.
>
> You should be able to verify this claim using, e.g., htop.
>
> Anyway, your pattern is correct (= always worked fine for me). In other
> words, if you do this in a loop:
>
> 1. prepare burst
> 2. send burst (with end-of-burst flag)
> 3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
>
> the 3. waits for the specified timeout to occur, CPU is not busy waiting.
>
> Rather, a short timeout such as 1 ms should not be necessary since the
> library call will return immediately after the ack indication is
> received. For instance, I use 100 ms (likely copied from Ettus examples).
>
> Best regards,
> Claudio
>
> On 11.05.2017 13:00, Vladica Sark wrote:
>> Hi,
>>
>> So I measured the times where the cpu time is spent and that happens
>> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
>> async msg is received .
>>
>> Basically, 80% of the time is spent in waiting for the async msg.
>>
>> Next what I tried is to run this in loop with a sleep of 1 ms and
>> timeout of 1 ms like:
>>
>> recv_async_msg(tx_md, 0.001);
>> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>>
>> The cpu usage is again 200%. It seems that a thread spawned by uhd in
>> the background is actively using the cpu.
>>
>> From user perspective it seems hard to fix this. Obviously the uhd is
>> doing something in the background.
>>
>> BR,
>> Vladica
>>
>>
>> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>>> Dear Vladica,
>>> It sounds like you have an active wait in the tx threads.
>>>
>>> I suggest you double-check all loops and make sure they do not spin
>>> faster than intended.
>>>
>>> For instance, if you have something like:
>>>
>>> while (true) {
>>> // do something without blocking
>>> recv_async_msg(/* ... */); // [1]
>>> // do something without blocking
>>> }
>>>
>>> As I understand, you are assuming that [1] blocks, but if it does not
>>> then you have a problem because the CPU will be 100% on the loop.
>>>
>>> Same if you have other library/system calls that _should_ block but
>>> _may_ not due to any reason.
>>>
>>> Adding some log lines with a timestamp or measuring the function call
>>> times should point you straight to the issue.
>>>
>>> Best regards,
>>> Claudio
>>>
>>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>>> Hi,
>>>>
>>>> With 8 samples per burst and 0.195312 MSps, again 200% of processor
>>>> usage.
>>>> Lower sample rate is not supported by the N210s.
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>>
>>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>>> What happens if you reduce the sample rate, say, to 10e3 samples per
>>>>> second?
>>>>> And what happens if you reduce the # of generated samples to a very
>>>>> low
>>>>> number, e.g., 8?
>>>>>
>>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>>> <[email protected] <mailto:[email protected]>>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have an app which transmits 8192 samples each 10 ms on two N210s
>>>>> which
>>>>> are combined together and seen as 2 channels. The samples are
>>>>> transmitted as timed samples. After the send command, I wait in
>>>>> recv_async_msg command, till the samples get transmitted and
>>>>> than I
>>>>> schedule a new transmission in 10 ms.
>>>>>
>>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at
>>>>> 100%.
>>>>> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
>>>>> Of course, no signal processing is involved at this point, only
>>>>> ready
>>>>> samples are being transmitted.
>>>>>
>>>>> The machine has a i5 vPro processor with 4 cores.
>>>>>
>>>>> Any way to reduce this?
>>>>>
>>>>> BR,
>>>>> Vladica
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-05-11 13-50-20.png
Type: image/png
Size: 102958 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170511/94289caf/attachment-0001.png>
------------------------------
Message: 7
Date: Thu, 11 May 2017 09:55:56 -0230
From: Yake Li <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: E310 filter configuration
Message-ID:
<CADXWyQdGwcSTiFzJNwLzFU4z=prxot_22iqpfq1ojfw+k8-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I had an Ettus E310 sampling problem. After some talk with Rob, I know what
direction I should try but I am still a little bit confused. Please see
below our discussion and thanks for Rob's help.
My question is as follows: I can only do 6 MS/s sampling for a short while
because E310 tells me overflow after 40 seconds of data transmission using
GigE (USRP to UDP). But I can live with it for proof of concept. I have two
pulses (1 us length which roughly equals to a bandwidth of 2 MHz) with
different carriers (one is 2030 MHz and the other is 1970 MHz) that I want
to capture and measure the leading edge (phase is not important). As the
two Rx channels of E310 share one Rx LO, I cannot do baseband sampling for
both. So I want to configure the Rx channels to 2000 MHz so that I get 30
MHz IF, and then do passband smapling for both using 6 MS/s. But the test
results show that the passband sampling is not working. I still see the
pulses, but the amplitude is significantly attenuated and huge artificials
appear. I guess the filters in E310 is not correctly configured. Can
anybody help me for the filter configuration?
I prefer gnuradio python solution but UHD is also ok if it solves the
problem.
Regards,
Yake
---------- Forwarded message ----------
From: Rob Kossler <[email protected]>
Date: 2017-05-10 23:36 GMT-02:30
Subject: Re: [USRP-users] E310 filter configuration
To: Yake Li <[email protected]>
Yake,
If you contact the list again, explain that you are trying to receive 2
signals, one at 1.97 and one at 2.03 GHz, each with 3 MHz bandwidth using
an E310. With this information, I think that someone can help explain how
to do it. Also, explain if you are using UHD directly from C++ or if you
are using gnuradio.
Rob
On Wed, May 10, 2017 at 9:24 PM, Rob Kossler <[email protected]> wrote:
> Yake,
> It is possible with the USRP to have the analog LO at one frequency and
> then a digital LO at another frequency. Perhaps my explanation is not
> great, but the point is that you can have the FPGA center its decimation
> filter at a different location than the analog LO. In the Ettus UHD
> manual, the "set_rx_freq" function has an argument that is a "tune_request"
> and this can have both a "rf_freq" and a "dsp_freq". Actually the rf_freq
> should be set to the freq that you want (in your case 2.03 GHz) and the
> dsp_freq should be set to 30 MHz. This will automatically cause the analog
> LO to be at 2.0 GHz.For your other signal, you can set rf_freq=1.97 GHz and
> dsp_freq=-30MHz. Then, you should get both of the signals you wanted and
> they will be at baseband.
>
> The only trouble that I see with this is that perhaps there is an analog
> anti-aliasing filter of around 56 MHz. But, maybe this would be OK as the
> filter roll-off might be slow enough. The other trouble I see is that
> perhaps you will need to run the master clock at 61.44 MHz or something
> like that in order that you have this kind of bandwidth for both of your
> signals. I really don't know if that is possible with 2 channel. But, my
> suggestion is to play around with this and if you still have trouble, maybe
> contact the list again. If you have trouble, maybe try a test case with
> signals at 1.99 and 2.01 GHz and try this method to receive both signals.
> This should be easily possible.
>
> Let me know how it goes.
> Rob
>
> On Wed, May 10, 2017 at 3:04 PM, Yake Li <[email protected]> wrote:
>
>> Rob,
>>
>> Now I understand. Yes, I am trying to use the aliased version near DC to
>> reconstruct the pusles. So the master clock rate is for ADC and FPGA, and
>> the sampling rate is the decmiated rate. In my original setting, I use 48
>> MHz as my masker clock rate and this will sample the 30 MHz without
>> aliasing. Then the FPGA applies a low pass filter before decimating the
>> sampling rate to 6 MHz, so the IF is attenuated in this process.
>>
>> The reason I was trying to do bandpass sampling is because we have
>> another signal comes at 1970 MHz. As the two Rx of E310 share the same LO,
>> we cannot sample the two signals both at the baseband. That is how the
>> passband IF requirement comes up.
>>
>> I did another test, though. I set the master clock to be 10 MHz (I guess
>> both ADC and FPGA work at this 10 MHz?) and sampling rate to be 5 MHz
>> (still using 30 MHz IF). In this configuration, I will actually sample the
>> aliased spectrum at DC. However, the same problem happens. I guess
>> somewhere else in E310 is still preventing the 30 MHz IF signal to go
>> through. Maybe the AD9361 is not capable of doing passband sampling.
>>
>> Is there any possible way in E310 that could allow me to do the bandpass
>> sampling?
>>
>> Regards,
>>
>> Yake
>>
>> 2017-05-10 12:08 GMT-02:30 Rob Kossler <[email protected]>:
>>
>>> Yake,
>>> So, you are trying to "undersample" the 30 MHz IF signal with the
>>> knowledge that the aliased version near DC will suffice? If so, this is
>>> not a method that can work with the USRP. At least not with the existing
>>> FPGA code. The USRP does not actually sample at the rate you specify in
>>> the sample rate. The USRP A/D typically operates at a higher rate and then
>>> the FPGA implements digital filtering and downconversion to provide the
>>> samples at the specified sample rate.
>>>
>>> So, in your case, I think that the analog filtering is not even
>>> relevant. This filtering is intended to reject large out-of-band signals
>>> that can cause problems at the RF front end. This filtering will not
>>> impact any signal that is only 30 MHz from the LO. The problem for you is
>>> the digital filtering & downconversion DSP that is implemented in the
>>> FPGA. This is the filtering that is rejecting your 30 MHz signal. But, I'm
>>> not as familiar with the E310 as I am with the X310 so it is possible that
>>> the "master clock rate" is also relevant.
>>>
>>> In any event, can you explain why you need to have the LO at 2 GHz for
>>> your application. Why not have the LO at 2.03 GHz?
>>> Rob
>>>
>>> On Wed, May 10, 2017 at 8:50 AM, Yake Li <[email protected]> wrote:
>>>
>>>> Hi Rob,
>>>>
>>>>
>>>>
>>>> Thanks for your reply.
>>>>
>>>>
>>>>
>>>> I think I did not explain my problem well. Our application needs us to
>>>> use 2GHz to demodulate the 2.03 GHz pulses, which means we have to deal
>>>> with the 30 MHz IF signal. However, we do not need the phase information of
>>>> the IF signal. We only care about the leading edge of the pulse, that is
>>>> why we are only interested in the 2.5 MHz bandwidth but not the 30 MHz
>>>> center frequency. If we use 6 MHz to sample the 2.5 MHz bandwidth IF signal
>>>> centered at 30 MHz, we are actually sampling the spectrum copy of the IF
>>>> signal that is centered at zero frequency. The result should approximately
>>>> be rectangular pulses in time domain.
>>>>
>>>>
>>>>
>>>> Therefore, theoretically, if the 30 MHz IF signal can pass the filters
>>>> before ADC without distortion and attenuation, we should be able get the
>>>> same result as shown in fig1 of my last email. But now it is not the case
>>>> (we actually got fig2).
>>>>
>>>>
>>>>
>>>> I do not know if my theory was wrong or my settings of E310 were wrong.
>>>>
>>>>
>>>>
>>>> Yake
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Rob Kossler [mailto:[email protected]]
>>>> *Sent:* May 9, 2017 3:09 PM
>>>> *To:* Yake Li <[email protected]>
>>>>
>>>> *Subject:* Re: [USRP-users] E310 filter configuration
>>>>
>>>>
>>>>
>>>> Hi Yake,
>>>>
>>>> I think that perhaps you do not understand how the USRP provides
>>>> baseband complex samples (not real, IF samples). If you want to measure a
>>>> signal at 2.03 GHz with a bandwidth of 2.5 MHz, you can simply set the RF
>>>> center frequency to 2.03 GHz and the sample rate to about 3 MS/s. With
>>>> complex samples, the bandwidth is essentially the sample rate.
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>> On Tue, May 9, 2017 at 12:51 PM, Yake Li <[email protected]> wrote:
>>>>
>>>> Please see attached the results. I sent two identical pulses (1 us
>>>> width in time and roughly 2.5 MHz bandwidth in freq domain) which have 2.03
>>>> GHz center frequency. The sampling rate is 6 MS/s. Fig1 is the result when
>>>> I tuned the Rx LO to 2.028 GHz (I notice the filter before ADC passes
>>>> signal above 1 MHz, so I set IF to be 2 MHz). Fig2 is the result if I tune
>>>> the Rx LO to be 2.0 GHZ (30MHz IF). I did not use set_bandwidth() command
>>>> in both cases. In my understanding, if the 30 MHz IF signal passed the
>>>> filter before ADC, I should be able to sample it using 6 MHz because the
>>>> bandwidth is only 2.5MHz. But as shown by the figure, the amplitude is
>>>> suppressed, unbalanced and artificial is presented. I guess the problem
>>>> could be the filters.
>>>>
>>>>
>>>>
>>>> *From:* Rob Kossler [mailto:[email protected]]
>>>> *Sent:* May 9, 2017 1:23 PM
>>>> *To:* Marcus D. Leech <[email protected]>
>>>> *Cc:* Yake Li <[email protected]>; [email protected]
>>>> *Subject:* Re: [USRP-users] E310 filter configuration
>>>>
>>>>
>>>>
>>>> Typo in my message. I meant to say set the sample rate to 6e6 as you
>>>> indicated originally...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <[email protected]> wrote:
>>>>
>>>> Ignoring the set_bandwidth() command, if you set the center freq to 2e9
>>>> and the sample rate to 3e6, your results will show signals in the range
>>>> 1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
>>>> which is 30 MHz away from 2 GHz.
>>>>
>>>>
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>> The "set_bandwidth" method sets the analog bandwidth in front of the
>>>> ADC.
>>>>
>>>> The RF filters are selected automatically based on your desired tuning
>>>> frequency.
>>>>
>>>> It would help us if you describe how the result is "incorrect" --
>>>> perhaps an FFT plot?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> My question is could I set the filters separately in Ettus E310? I
>>>> noticed there are different filters in E310. First, there are filter banks
>>>> right after the receiving antenna. Second, the AD9361 has Rx low pass
>>>> filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
>>>> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is
>>>> only one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in UHD)
>>>> to set the RF bandwidth of front end. What is the response of each filters
>>>> mentioned above after using this command? Could I set separately the
>>>> response of different filters?
>>>>
>>>>
>>>>
>>>> I am asking because I want to, for example, sample a signal centered at
>>>> 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to
>>>> sample this signal with 6 MHz sampling rate. What I did is that I use
>>>> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
>>>> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth,
>>>> and under no settings I got the right result. Is there something wrong with
>>>> my settings?
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> Yake
>>>>
>>>>
>>>>
>>>> [image:
>>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>
>>>> Virus-free. www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> 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/20170511/f8fb8e09/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 11 May 2017 16:19:44 +0200
From: [email protected]
To: [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Dear Vladica,
You are right regarding threads spawned by UHD.
The approach you take is the same as that in the example tx_burst
shipped with the UHD libraries.
I am wondering what happens if you run:
tx_bursts --repeat --freq 1e9 --rate 1e6 --channel 0,1
on my computer I have three spawned threads (4 in total), all with
real-time priority, all with negligible CPU utilization.
Ettus radio: X300
UHD version: 3.10.1.1
What happens on yours?
Best regards,
Claudio
On 11.05.2017 14:05, Vladica Sark via USRP-users wrote:
> Hi Claudio,
>
> Please find attached the htop screenshot. The application of interest
> is "loc_an".
>
> Also the command:
> pstree -p 3899
>
> returns that there are 6 threads.
>
> loc_an(3899)???{loc_an}(3904)
> ??{loc_an}(3905)
> ??{loc_an}(3906)
> ??{loc_an}(3907)
> ??{loc_an}(3908)
> ??{loc_an}(3909)
>
> My program runs only one.
>
> Here is how I prepare the burst.
>
> tx_md.start_of_burst = true;
> tx_md.end_of_burst = true;
> tx_md.has_time_spec = true;
> tx_md.time_spec = at_tm;
>
> size_t num_tx_samps = tx_stream->send(&tx_frame_s_tm_filt.front(),
> TX_BUF_SIZE, tx_md);
>
> And activelly wait for recv_async_msg. I tried also with 100 ms of
> timeout and no change.
>
> BR,
> Vladica
>
>
> On 11.05.2017 13:22, [email protected] wrote:
>> Dear Vladica,
>> Uhm, I don't think the UHD spawns threads in the background.
>>
>> You should be able to verify this claim using, e.g., htop.
>>
>> Anyway, your pattern is correct (= always worked fine for me). In
>> other
>> words, if you do this in a loop:
>>
>> 1. prepare burst
>> 2. send burst (with end-of-burst flag)
>> 3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
>>
>> the 3. waits for the specified timeout to occur, CPU is not busy
>> waiting.
>>
>> Rather, a short timeout such as 1 ms should not be necessary since the
>> library call will return immediately after the ack indication is
>> received. For instance, I use 100 ms (likely copied from Ettus
>> examples).
>>
>> Best regards,
>> Claudio
>>
>> On 11.05.2017 13:00, Vladica Sark wrote:
>>> Hi,
>>>
>>> So I measured the times where the cpu time is spent and that happens
>>> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
>>> async msg is received .
>>>
>>> Basically, 80% of the time is spent in waiting for the async msg.
>>>
>>> Next what I tried is to run this in loop with a sleep of 1 ms and
>>> timeout of 1 ms like:
>>>
>>> recv_async_msg(tx_md, 0.001);
>>> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>>>
>>> The cpu usage is again 200%. It seems that a thread spawned by uhd in
>>> the background is actively using the cpu.
>>>
>>> From user perspective it seems hard to fix this. Obviously the uhd is
>>> doing something in the background.
>>>
>>> BR,
>>> Vladica
>>>
>>>
>>> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>>>> Dear Vladica,
>>>> It sounds like you have an active wait in the tx threads.
>>>>
>>>> I suggest you double-check all loops and make sure they do not spin
>>>> faster than intended.
>>>>
>>>> For instance, if you have something like:
>>>>
>>>> while (true) {
>>>> // do something without blocking
>>>> recv_async_msg(/* ... */); // [1]
>>>> // do something without blocking
>>>> }
>>>>
>>>> As I understand, you are assuming that [1] blocks, but if it does
>>>> not
>>>> then you have a problem because the CPU will be 100% on the loop.
>>>>
>>>> Same if you have other library/system calls that _should_ block but
>>>> _may_ not due to any reason.
>>>>
>>>> Adding some log lines with a timestamp or measuring the function
>>>> call
>>>> times should point you straight to the issue.
>>>>
>>>> Best regards,
>>>> Claudio
>>>>
>>>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>>>> Hi,
>>>>>
>>>>> With 8 samples per burst and 0.195312 MSps, again 200% of processor
>>>>> usage.
>>>>> Lower sample rate is not supported by the N210s.
>>>>>
>>>>> BR,
>>>>> Vladica
>>>>>
>>>>>
>>>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>>>> What happens if you reduce the sample rate, say, to 10e3 samples
>>>>>> per
>>>>>> second?
>>>>>> And what happens if you reduce the # of generated samples to a
>>>>>> very
>>>>>> low
>>>>>> number, e.g., 8?
>>>>>>
>>>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have an app which transmits 8192 samples each 10 ms on two
>>>>>> N210s
>>>>>> which
>>>>>> are combined together and seen as 2 channels. The samples are
>>>>>> transmitted as timed samples. After the send command, I wait
>>>>>> in
>>>>>> recv_async_msg command, till the samples get transmitted and
>>>>>> than I
>>>>>> schedule a new transmission in 10 ms.
>>>>>>
>>>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at
>>>>>> 100%.
>>>>>> It does not depend on the sample rate. Tried 10, 25 and 50
>>>>>> MSps.
>>>>>> Of course, no signal processing is involved at this point,
>>>>>> only
>>>>>> ready
>>>>>> samples are being transmitted.
>>>>>>
>>>>>> The machine has a i5 vPro processor with 4 cores.
>>>>>>
>>>>>> Any way to reduce this?
>>>>>>
>>>>>> BR,
>>>>>> Vladica
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>>
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 9
Date: Thu, 11 May 2017 16:31:55 +0200
From: Vladica Sark <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
One more update.
I also tried with tx_waveforms example, and it also happens the same, no
matter what is the transmit sample rate. By receiving samples, it is ok,
i.e. the cpu utilization looks quite normal.
I tried tx_waveforms with different USRP models and the CPU utilization is
N210 - 100%
B205mini-i - 100%
X310 - 200% - on a different machine compared to the previous 2
The OS is Ubuntu 16.04
BR,
Vladica
On 11.05.2017 14:05, Vladica Sark wrote:
> Hi Claudio,
>
> Please find attached the htop screenshot. The application of interest is
> "loc_an".
>
> Also the command:
> pstree -p 3899
>
> returns that there are 6 threads.
>
> loc_an(3899)???{loc_an}(3904)
> ??{loc_an}(3905)
> ??{loc_an}(3906)
> ??{loc_an}(3907)
> ??{loc_an}(3908)
> ??{loc_an}(3909)
>
> My program runs only one.
>
> Here is how I prepare the burst.
>
> tx_md.start_of_burst = true;
> tx_md.end_of_burst = true;
> tx_md.has_time_spec = true;
> tx_md.time_spec = at_tm;
>
> size_t num_tx_samps = tx_stream->send(&tx_frame_s_tm_filt.front(),
> TX_BUF_SIZE, tx_md);
>
> And activelly wait for recv_async_msg. I tried also with 100 ms of
> timeout and no change.
>
> BR,
> Vladica
>
>
> On 11.05.2017 13:22, [email protected] wrote:
>> Dear Vladica,
>> Uhm, I don't think the UHD spawns threads in the background.
>>
>> You should be able to verify this claim using, e.g., htop.
>>
>> Anyway, your pattern is correct (= always worked fine for me). In other
>> words, if you do this in a loop:
>>
>> 1. prepare burst
>> 2. send burst (with end-of-burst flag)
>> 3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
>>
>> the 3. waits for the specified timeout to occur, CPU is not busy waiting.
>>
>> Rather, a short timeout such as 1 ms should not be necessary since the
>> library call will return immediately after the ack indication is
>> received. For instance, I use 100 ms (likely copied from Ettus examples).
>>
>> Best regards,
>> Claudio
>>
>> On 11.05.2017 13:00, Vladica Sark wrote:
>>> Hi,
>>>
>>> So I measured the times where the cpu time is spent and that happens
>>> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
>>> async msg is received .
>>>
>>> Basically, 80% of the time is spent in waiting for the async msg.
>>>
>>> Next what I tried is to run this in loop with a sleep of 1 ms and
>>> timeout of 1 ms like:
>>>
>>> recv_async_msg(tx_md, 0.001);
>>> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>>>
>>> The cpu usage is again 200%. It seems that a thread spawned by uhd in
>>> the background is actively using the cpu.
>>>
>>> From user perspective it seems hard to fix this. Obviously the uhd is
>>> doing something in the background.
>>>
>>> BR,
>>> Vladica
>>>
>>>
>>> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>>>> Dear Vladica,
>>>> It sounds like you have an active wait in the tx threads.
>>>>
>>>> I suggest you double-check all loops and make sure they do not spin
>>>> faster than intended.
>>>>
>>>> For instance, if you have something like:
>>>>
>>>> while (true) {
>>>> // do something without blocking
>>>> recv_async_msg(/* ... */); // [1]
>>>> // do something without blocking
>>>> }
>>>>
>>>> As I understand, you are assuming that [1] blocks, but if it does not
>>>> then you have a problem because the CPU will be 100% on the loop.
>>>>
>>>> Same if you have other library/system calls that _should_ block but
>>>> _may_ not due to any reason.
>>>>
>>>> Adding some log lines with a timestamp or measuring the function call
>>>> times should point you straight to the issue.
>>>>
>>>> Best regards,
>>>> Claudio
>>>>
>>>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>>>> Hi,
>>>>>
>>>>> With 8 samples per burst and 0.195312 MSps, again 200% of processor
>>>>> usage.
>>>>> Lower sample rate is not supported by the N210s.
>>>>>
>>>>> BR,
>>>>> Vladica
>>>>>
>>>>>
>>>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>>>> What happens if you reduce the sample rate, say, to 10e3 samples per
>>>>>> second?
>>>>>> And what happens if you reduce the # of generated samples to a very
>>>>>> low
>>>>>> number, e.g., 8?
>>>>>>
>>>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have an app which transmits 8192 samples each 10 ms on two
>>>>>> N210s
>>>>>> which
>>>>>> are combined together and seen as 2 channels. The samples are
>>>>>> transmitted as timed samples. After the send command, I wait in
>>>>>> recv_async_msg command, till the samples get transmitted and
>>>>>> than I
>>>>>> schedule a new transmission in 10 ms.
>>>>>>
>>>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at
>>>>>> 100%.
>>>>>> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
>>>>>> Of course, no signal processing is involved at this point, only
>>>>>> ready
>>>>>> samples are being transmitted.
>>>>>>
>>>>>> The machine has a i5 vPro processor with 4 cores.
>>>>>>
>>>>>> Any way to reduce this?
>>>>>>
>>>>>> BR,
>>>>>> Vladica
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>>
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>
------------------------------
Message: 10
Date: Thu, 11 May 2017 16:49:24 +0200
From: Vladica Sark <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Claudio,
I tried this with the models I have. So basically,
- B205mini with 1 channel, negligible CPU utilization
- N210 with one channel also negligible utilization
- 2 x N210 with two channels also negligible utilization
- X310 with two channels negligible utilization but reports some UUUU
(the X310s are on another machine)
UHD:
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.11.0.git-162-g2790b51f
Kernel:
Linux IHP606 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux
Have you tried with tx_waveforms to check what is the cpu utilization?
BR,
Vladica
On 11.05.2017 16:19, Claudio Cicconetti via USRP-users wrote:
> Dear Vladica,
> You are right regarding threads spawned by UHD.
>
> The approach you take is the same as that in the example tx_burst
> shipped with the UHD libraries.
>
> I am wondering what happens if you run:
>
> tx_bursts --repeat --freq 1e9 --rate 1e6 --channel 0,1
>
> on my computer I have three spawned threads (4 in total), all with
> real-time priority, all with negligible CPU utilization.
>
> Ettus radio: X300
> UHD version: 3.10.1.1
>
> What happens on yours?
>
> Best regards,
> Claudio
>
> On 11.05.2017 14:05, Vladica Sark via USRP-users wrote:
>> Hi Claudio,
>>
>> Please find attached the htop screenshot. The application of interest
>> is "loc_an".
>>
>> Also the command:
>> pstree -p 3899
>>
>> returns that there are 6 threads.
>>
>> loc_an(3899)???{loc_an}(3904)
>> ??{loc_an}(3905)
>> ??{loc_an}(3906)
>> ??{loc_an}(3907)
>> ??{loc_an}(3908)
>> ??{loc_an}(3909)
>>
>> My program runs only one.
>>
>> Here is how I prepare the burst.
>>
>> tx_md.start_of_burst = true;
>> tx_md.end_of_burst = true;
>> tx_md.has_time_spec = true;
>> tx_md.time_spec = at_tm;
>>
>> size_t num_tx_samps = tx_stream->send(&tx_frame_s_tm_filt.front(),
>> TX_BUF_SIZE, tx_md);
>>
>> And activelly wait for recv_async_msg. I tried also with 100 ms of
>> timeout and no change.
>>
>> BR,
>> Vladica
>>
>>
>> On 11.05.2017 13:22, [email protected] wrote:
>>> Dear Vladica,
>>> Uhm, I don't think the UHD spawns threads in the background.
>>>
>>> You should be able to verify this claim using, e.g., htop.
>>>
>>> Anyway, your pattern is correct (= always worked fine for me). In other
>>> words, if you do this in a loop:
>>>
>>> 1. prepare burst
>>> 2. send burst (with end-of-burst flag)
>>> 3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
>>>
>>> the 3. waits for the specified timeout to occur, CPU is not busy
>>> waiting.
>>>
>>> Rather, a short timeout such as 1 ms should not be necessary since the
>>> library call will return immediately after the ack indication is
>>> received. For instance, I use 100 ms (likely copied from Ettus
>>> examples).
>>>
>>> Best regards,
>>> Claudio
>>>
>>> On 11.05.2017 13:00, Vladica Sark wrote:
>>>> Hi,
>>>>
>>>> So I measured the times where the cpu time is spent and that happens
>>>> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
>>>> async msg is received .
>>>>
>>>> Basically, 80% of the time is spent in waiting for the async msg.
>>>>
>>>> Next what I tried is to run this in loop with a sleep of 1 ms and
>>>> timeout of 1 ms like:
>>>>
>>>> recv_async_msg(tx_md, 0.001);
>>>> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>>>>
>>>> The cpu usage is again 200%. It seems that a thread spawned by uhd in
>>>> the background is actively using the cpu.
>>>>
>>>> From user perspective it seems hard to fix this. Obviously the uhd is
>>>> doing something in the background.
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>>
>>>> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>>>>> Dear Vladica,
>>>>> It sounds like you have an active wait in the tx threads.
>>>>>
>>>>> I suggest you double-check all loops and make sure they do not spin
>>>>> faster than intended.
>>>>>
>>>>> For instance, if you have something like:
>>>>>
>>>>> while (true) {
>>>>> // do something without blocking
>>>>> recv_async_msg(/* ... */); // [1]
>>>>> // do something without blocking
>>>>> }
>>>>>
>>>>> As I understand, you are assuming that [1] blocks, but if it does not
>>>>> then you have a problem because the CPU will be 100% on the loop.
>>>>>
>>>>> Same if you have other library/system calls that _should_ block but
>>>>> _may_ not due to any reason.
>>>>>
>>>>> Adding some log lines with a timestamp or measuring the function call
>>>>> times should point you straight to the issue.
>>>>>
>>>>> Best regards,
>>>>> Claudio
>>>>>
>>>>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>>>>> Hi,
>>>>>>
>>>>>> With 8 samples per burst and 0.195312 MSps, again 200% of processor
>>>>>> usage.
>>>>>> Lower sample rate is not supported by the N210s.
>>>>>>
>>>>>> BR,
>>>>>> Vladica
>>>>>>
>>>>>>
>>>>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>>>>> What happens if you reduce the sample rate, say, to 10e3 samples per
>>>>>>> second?
>>>>>>> And what happens if you reduce the # of generated samples to a very
>>>>>>> low
>>>>>>> number, e.g., 8?
>>>>>>>
>>>>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have an app which transmits 8192 samples each 10 ms on two
>>>>>>> N210s
>>>>>>> which
>>>>>>> are combined together and seen as 2 channels. The samples are
>>>>>>> transmitted as timed samples. After the send command, I wait in
>>>>>>> recv_async_msg command, till the samples get transmitted and
>>>>>>> than I
>>>>>>> schedule a new transmission in 10 ms.
>>>>>>>
>>>>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at
>>>>>>> 100%.
>>>>>>> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
>>>>>>> Of course, no signal processing is involved at this point, only
>>>>>>> ready
>>>>>>> samples are being transmitted.
>>>>>>>
>>>>>>> The machine has a i5 vPro processor with 4 cores.
>>>>>>>
>>>>>>> Any way to reduce this?
>>>>>>>
>>>>>>> BR,
>>>>>>> Vladica
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Thu, 11 May 2017 16:52:48 +0200
From: [email protected]
To: Vladica Sark <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Dear Vladica,
Please send the exact command line arguments of tx_waveforms, I will
send results on my computer.
However, I noticed that you are using an UNSTABLE branch of the UHD.
This might well explain the odd behavior. Do you have a change to switch
to a stable version, such as 3.9.6 or 3.10.1.1?
Best regards,
Claudio
On 11.05.2017 16:49, Vladica Sark wrote:
> Hi Claudio,
>
> I tried this with the models I have. So basically,
> - B205mini with 1 channel, negligible CPU utilization
> - N210 with one channel also negligible utilization
> - 2 x N210 with two channels also negligible utilization
> - X310 with two channels negligible utilization but reports some UUUU
> (the X310s are on another machine)
>
> UHD:
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.git-162-g2790b51f
>
> Kernel:
> Linux IHP606 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> Have you tried with tx_waveforms to check what is the cpu utilization?
>
> BR,
> Vladica
>
>
> On 11.05.2017 16:19, Claudio Cicconetti via USRP-users wrote:
>> Dear Vladica,
>> You are right regarding threads spawned by UHD.
>>
>> The approach you take is the same as that in the example tx_burst
>> shipped with the UHD libraries.
>>
>> I am wondering what happens if you run:
>>
>> tx_bursts --repeat --freq 1e9 --rate 1e6 --channel 0,1
>>
>> on my computer I have three spawned threads (4 in total), all with
>> real-time priority, all with negligible CPU utilization.
>>
>> Ettus radio: X300
>> UHD version: 3.10.1.1
>>
>> What happens on yours?
>>
>> Best regards,
>> Claudio
>>
>> On 11.05.2017 14:05, Vladica Sark via USRP-users wrote:
>>> Hi Claudio,
>>>
>>> Please find attached the htop screenshot. The application of interest
>>> is "loc_an".
>>>
>>> Also the command:
>>> pstree -p 3899
>>>
>>> returns that there are 6 threads.
>>>
>>> loc_an(3899)???{loc_an}(3904)
>>> ??{loc_an}(3905)
>>> ??{loc_an}(3906)
>>> ??{loc_an}(3907)
>>> ??{loc_an}(3908)
>>> ??{loc_an}(3909)
>>>
>>> My program runs only one.
>>>
>>> Here is how I prepare the burst.
>>>
>>> tx_md.start_of_burst = true;
>>> tx_md.end_of_burst = true;
>>> tx_md.has_time_spec = true;
>>> tx_md.time_spec = at_tm;
>>>
>>> size_t num_tx_samps = tx_stream->send(&tx_frame_s_tm_filt.front(),
>>> TX_BUF_SIZE, tx_md);
>>>
>>> And activelly wait for recv_async_msg. I tried also with 100 ms of
>>> timeout and no change.
>>>
>>> BR,
>>> Vladica
>>>
>>>
>>> On 11.05.2017 13:22, [email protected] wrote:
>>>> Dear Vladica,
>>>> Uhm, I don't think the UHD spawns threads in the background.
>>>>
>>>> You should be able to verify this claim using, e.g., htop.
>>>>
>>>> Anyway, your pattern is correct (= always worked fine for me). In
>>>> other
>>>> words, if you do this in a loop:
>>>>
>>>> 1. prepare burst
>>>> 2. send burst (with end-of-burst flag)
>>>> 3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
>>>>
>>>> the 3. waits for the specified timeout to occur, CPU is not busy
>>>> waiting.
>>>>
>>>> Rather, a short timeout such as 1 ms should not be necessary since
>>>> the
>>>> library call will return immediately after the ack indication is
>>>> received. For instance, I use 100 ms (likely copied from Ettus
>>>> examples).
>>>>
>>>> Best regards,
>>>> Claudio
>>>>
>>>> On 11.05.2017 13:00, Vladica Sark wrote:
>>>>> Hi,
>>>>>
>>>>> So I measured the times where the cpu time is spent and that
>>>>> happens
>>>>> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
>>>>> async msg is received .
>>>>>
>>>>> Basically, 80% of the time is spent in waiting for the async msg.
>>>>>
>>>>> Next what I tried is to run this in loop with a sleep of 1 ms and
>>>>> timeout of 1 ms like:
>>>>>
>>>>> recv_async_msg(tx_md, 0.001);
>>>>> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>>>>>
>>>>> The cpu usage is again 200%. It seems that a thread spawned by uhd
>>>>> in
>>>>> the background is actively using the cpu.
>>>>>
>>>>> From user perspective it seems hard to fix this. Obviously the uhd
>>>>> is
>>>>> doing something in the background.
>>>>>
>>>>> BR,
>>>>> Vladica
>>>>>
>>>>>
>>>>> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>>>>>> Dear Vladica,
>>>>>> It sounds like you have an active wait in the tx threads.
>>>>>>
>>>>>> I suggest you double-check all loops and make sure they do not
>>>>>> spin
>>>>>> faster than intended.
>>>>>>
>>>>>> For instance, if you have something like:
>>>>>>
>>>>>> while (true) {
>>>>>> // do something without blocking
>>>>>> recv_async_msg(/* ... */); // [1]
>>>>>> // do something without blocking
>>>>>> }
>>>>>>
>>>>>> As I understand, you are assuming that [1] blocks, but if it does
>>>>>> not
>>>>>> then you have a problem because the CPU will be 100% on the loop.
>>>>>>
>>>>>> Same if you have other library/system calls that _should_ block
>>>>>> but
>>>>>> _may_ not due to any reason.
>>>>>>
>>>>>> Adding some log lines with a timestamp or measuring the function
>>>>>> call
>>>>>> times should point you straight to the issue.
>>>>>>
>>>>>> Best regards,
>>>>>> Claudio
>>>>>>
>>>>>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> With 8 samples per burst and 0.195312 MSps, again 200% of
>>>>>>> processor
>>>>>>> usage.
>>>>>>> Lower sample rate is not supported by the N210s.
>>>>>>>
>>>>>>> BR,
>>>>>>> Vladica
>>>>>>>
>>>>>>>
>>>>>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>>>>>> What happens if you reduce the sample rate, say, to 10e3 samples
>>>>>>>> per
>>>>>>>> second?
>>>>>>>> And what happens if you reduce the # of generated samples to a
>>>>>>>> very
>>>>>>>> low
>>>>>>>> number, e.g., 8?
>>>>>>>>
>>>>>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have an app which transmits 8192 samples each 10 ms on two
>>>>>>>> N210s
>>>>>>>> which
>>>>>>>> are combined together and seen as 2 channels. The samples
>>>>>>>> are
>>>>>>>> transmitted as timed samples. After the send command, I wait
>>>>>>>> in
>>>>>>>> recv_async_msg command, till the samples get transmitted and
>>>>>>>> than I
>>>>>>>> schedule a new transmission in 10 ms.
>>>>>>>>
>>>>>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores
>>>>>>>> at
>>>>>>>> 100%.
>>>>>>>> It does not depend on the sample rate. Tried 10, 25 and 50
>>>>>>>> MSps.
>>>>>>>> Of course, no signal processing is involved at this point,
>>>>>>>> only
>>>>>>>> ready
>>>>>>>> samples are being transmitted.
>>>>>>>>
>>>>>>>> The machine has a i5 vPro processor with 4 cores.
>>>>>>>>
>>>>>>>> Any way to reduce this?
>>>>>>>>
>>>>>>>> BR,
>>>>>>>> Vladica
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> <mailto:[email protected]>
>>>>>>>>
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 12
Date: Thu, 11 May 2017 17:43:21 +0200
From: Vladica Sark <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Dear Claudio,
I just compiled 3.9.6 and installed it and everything works well at the
moment. No high CPU usage anymore.
Thanks for the help.
BR,
Vladica
On 11.05.2017 16:52, [email protected] wrote:
> Dear Vladica,
> Please send the exact command line arguments of tx_waveforms, I will
> send results on my computer.
>
> However, I noticed that you are using an UNSTABLE branch of the UHD.
> This might well explain the odd behavior. Do you have a change to switch
> to a stable version, such as 3.9.6 or 3.10.1.1?
>
> Best regards,
> Claudio
>
> On 11.05.2017 16:49, Vladica Sark wrote:
>> Hi Claudio,
>>
>> I tried this with the models I have. So basically,
>> - B205mini with 1 channel, negligible CPU utilization
>> - N210 with one channel also negligible utilization
>> - 2 x N210 with two channels also negligible utilization
>> - X310 with two channels negligible utilization but reports some UUUU
>> (the X310s are on another machine)
>>
>> UHD:
>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_3.11.0.git-162-g2790b51f
>>
>> Kernel:
>> Linux IHP606 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC
>> 2017 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Have you tried with tx_waveforms to check what is the cpu utilization?
>>
>> BR,
>> Vladica
>>
>>
>> On 11.05.2017 16:19, Claudio Cicconetti via USRP-users wrote:
>>> Dear Vladica,
>>> You are right regarding threads spawned by UHD.
>>>
>>> The approach you take is the same as that in the example tx_burst
>>> shipped with the UHD libraries.
>>>
>>> I am wondering what happens if you run:
>>>
>>> tx_bursts --repeat --freq 1e9 --rate 1e6 --channel 0,1
>>>
>>> on my computer I have three spawned threads (4 in total), all with
>>> real-time priority, all with negligible CPU utilization.
>>>
>>> Ettus radio: X300
>>> UHD version: 3.10.1.1
>>>
>>> What happens on yours?
>>>
>>> Best regards,
>>> Claudio
>>>
>>> On 11.05.2017 14:05, Vladica Sark via USRP-users wrote:
>>>> Hi Claudio,
>>>>
>>>> Please find attached the htop screenshot. The application of interest
>>>> is "loc_an".
>>>>
>>>> Also the command:
>>>> pstree -p 3899
>>>>
>>>> returns that there are 6 threads.
>>>>
>>>> loc_an(3899)???{loc_an}(3904)
>>>> ??{loc_an}(3905)
>>>> ??{loc_an}(3906)
>>>> ??{loc_an}(3907)
>>>> ??{loc_an}(3908)
>>>> ??{loc_an}(3909)
>>>>
>>>> My program runs only one.
>>>>
>>>> Here is how I prepare the burst.
>>>>
>>>> tx_md.start_of_burst = true;
>>>> tx_md.end_of_burst = true;
>>>> tx_md.has_time_spec = true;
>>>> tx_md.time_spec = at_tm;
>>>>
>>>> size_t num_tx_samps = tx_stream->send(&tx_frame_s_tm_filt.front(),
>>>> TX_BUF_SIZE, tx_md);
>>>>
>>>> And activelly wait for recv_async_msg. I tried also with 100 ms of
>>>> timeout and no change.
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>>
>>>> On 11.05.2017 13:22, [email protected] wrote:
>>>>> Dear Vladica,
>>>>> Uhm, I don't think the UHD spawns threads in the background.
>>>>>
>>>>> You should be able to verify this claim using, e.g., htop.
>>>>>
>>>>> Anyway, your pattern is correct (= always worked fine for me). In
>>>>> other
>>>>> words, if you do this in a loop:
>>>>>
>>>>> 1. prepare burst
>>>>> 2. send burst (with end-of-burst flag)
>>>>> 3. "actively" wait for EVENT_CODE_BURST_ACK via recv_async_msg
>>>>>
>>>>> the 3. waits for the specified timeout to occur, CPU is not busy
>>>>> waiting.
>>>>>
>>>>> Rather, a short timeout such as 1 ms should not be necessary since the
>>>>> library call will return immediately after the ack indication is
>>>>> received. For instance, I use 100 ms (likely copied from Ettus
>>>>> examples).
>>>>>
>>>>> Best regards,
>>>>> Claudio
>>>>>
>>>>> On 11.05.2017 13:00, Vladica Sark wrote:
>>>>>> Hi,
>>>>>>
>>>>>> So I measured the times where the cpu time is spent and that happens
>>>>>> in recv_async_msg(tx_md, 0.005), which is executed in a loop till
>>>>>> async msg is received .
>>>>>>
>>>>>> Basically, 80% of the time is spent in waiting for the async msg.
>>>>>>
>>>>>> Next what I tried is to run this in loop with a sleep of 1 ms and
>>>>>> timeout of 1 ms like:
>>>>>>
>>>>>> recv_async_msg(tx_md, 0.001);
>>>>>> boost::this_thread::sleep(boost::posix_time::milliseconds(1));
>>>>>>
>>>>>> The cpu usage is again 200%. It seems that a thread spawned by uhd in
>>>>>> the background is actively using the cpu.
>>>>>>
>>>>>> From user perspective it seems hard to fix this. Obviously the uhd is
>>>>>> doing something in the background.
>>>>>>
>>>>>> BR,
>>>>>> Vladica
>>>>>>
>>>>>>
>>>>>> On 10.05.2017 17:17, Claudio Cicconetti wrote:
>>>>>>> Dear Vladica,
>>>>>>> It sounds like you have an active wait in the tx threads.
>>>>>>>
>>>>>>> I suggest you double-check all loops and make sure they do not spin
>>>>>>> faster than intended.
>>>>>>>
>>>>>>> For instance, if you have something like:
>>>>>>>
>>>>>>> while (true) {
>>>>>>> // do something without blocking
>>>>>>> recv_async_msg(/* ... */); // [1]
>>>>>>> // do something without blocking
>>>>>>> }
>>>>>>>
>>>>>>> As I understand, you are assuming that [1] blocks, but if it does
>>>>>>> not
>>>>>>> then you have a problem because the CPU will be 100% on the loop.
>>>>>>>
>>>>>>> Same if you have other library/system calls that _should_ block but
>>>>>>> _may_ not due to any reason.
>>>>>>>
>>>>>>> Adding some log lines with a timestamp or measuring the function
>>>>>>> call
>>>>>>> times should point you straight to the issue.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Claudio
>>>>>>>
>>>>>>> On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> With 8 samples per burst and 0.195312 MSps, again 200% of processor
>>>>>>>> usage.
>>>>>>>> Lower sample rate is not supported by the N210s.
>>>>>>>>
>>>>>>>> BR,
>>>>>>>> Vladica
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>>>>>>>>> What happens if you reduce the sample rate, say, to 10e3
>>>>>>>>> samples per
>>>>>>>>> second?
>>>>>>>>> And what happens if you reduce the # of generated samples to a
>>>>>>>>> very
>>>>>>>>> low
>>>>>>>>> number, e.g., 8?
>>>>>>>>>
>>>>>>>>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>>>>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have an app which transmits 8192 samples each 10 ms on two
>>>>>>>>> N210s
>>>>>>>>> which
>>>>>>>>> are combined together and seen as 2 channels. The samples are
>>>>>>>>> transmitted as timed samples. After the send command, I
>>>>>>>>> wait in
>>>>>>>>> recv_async_msg command, till the samples get transmitted and
>>>>>>>>> than I
>>>>>>>>> schedule a new transmission in 10 ms.
>>>>>>>>>
>>>>>>>>> The issue is that the CPU utilization is 200%, i.e. 2 cores at
>>>>>>>>> 100%.
>>>>>>>>> It does not depend on the sample rate. Tried 10, 25 and 50
>>>>>>>>> MSps.
>>>>>>>>> Of course, no signal processing is involved at this point,
>>>>>>>>> only
>>>>>>>>> ready
>>>>>>>>> samples are being transmitted.
>>>>>>>>>
>>>>>>>>> The machine has a i5 vPro processor with 4 cores.
>>>>>>>>>
>>>>>>>>> Any way to reduce this?
>>>>>>>>>
>>>>>>>>> BR,
>>>>>>>>> Vladica
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list
>>>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>>>>
>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 81, Issue 11
******************************************
