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. High CPU utilization (100%) when streaming two concurrent
channels regardless of sample rate (Pruitt, Paul N.)
2. Re: High CPU utilization (100%) when streaming two concurrent
channels regardless of sample rate (Josh Blum)
3. Re: E1XX update additional step (Macre, William R)
4. Re: High CPU utilization (100%) when streaming two concurrent
channels regardless of sample rate (Pruitt, Paul N.)
5. Re: E1XX update additional step (Philip Balister)
6. Re: High CPU utilization (100%) when streaming two concurrent
channels regardless of sample rate (Pruitt, Paul N.)
7. Re: High CPU utilization (100%) when streaming two concurrent
channels regardless of sample rate (Josh Blum)
8. Disable Pad for USRP (ZaInzAiN Jj)
9. Purpose of 24-bit CORDIC in DDC chain? (Florian Schlembach)
10. Re: Purpose of 24-bit CORDIC in DDC chain? ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 1 Apr 2013 12:45:55 -0400
From: "Pruitt, Paul N." <[email protected]>
To: <[email protected]>
Subject: [USRP-users] High CPU utilization (100%) when streaming two
concurrent channels regardless of sample rate
Message-ID:
<f82ab11a5a3e584b8a5148146c547541066c8...@0015-its-exmb14.us.saic.com>
Content-Type: text/plain; charset="us-ascii"
I am using an N210 with this software configuration:
linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4);
Boost_104400;
UHD_003.005.000-27-gfcfcc01f
When I stream data from one DDC using sc16 wire format at 1 MSPS,
according to htop, the CPU utilization is ~1% for the conversion thread
and nearly the same for the application thread that receives the data
and currently does nothing with it. At 10 MSPS, the CPU utilization is
16% for each of these threads. Very reasonable.
Now when I configure to stream simultaneously from both DDCs on the
motherboard, the conversion task spikes to 100% cpu utilization, the
main() thread spikes to 100%, while my application thread uses about the
same percentage as before. I have the main() thread blocked in a
boost::this_thread::sleep() and most of the cpu time is kernel. Strace
shows just the sleep calls in that thread and rapid sched_yield() calls
in the conversion thread. The behavior at 1 MSPS is nearly the same as
10 MSPS. I am not seeing any non-zero error codes in the packet
metadata.
Any ideas what might be causing this behavior?
I create an rx_streamer for two receive channels (0 and 1) on the same
motherboard:
// Create stream arguments
uhd::stream_args_t stream_args(m_stream_args);
// Add all channels
size_t num_channels = m_usrp->get_rx_num_channels();
for (size_t i = 0; i < num_channels; ++i)
{
stream_args.channels.push_back(i);
}
uhd::rx_streamer::sptr rx_stream =
m_usrp->get_rx_stream(stream_args);
and stream continuously:
uhd::stream_cmd_t stream_cmd(
uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.num_samps = 0;
stream_cmd.stream_now = 0;
// start on a second boundary. Round up to avoid a race.
uhd::time_spec_t cur_time = m_usrp->get_time_now();
int offset = 1;
if (cur_time.get_frac_secs() > 0.5)
{
offset += 1;
}
uhd::time_spec_t start_time =
uhd::time_spec_t(cur_time.get_full_secs() + offset);
stream_cmd.time_spec = start_time;
m_usrp->issue_stream_cmd(stream_cmd);
Conversion thread stack trace:
(gdb) back
#0 0x0000003f286cf3a7 in sched_yield () from /lib64/libc.so.6
#1 0x00007ffff691bae9 in
uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
long) ()
from /opt/radiomap/lib64/libuhd.so.003
#2 0x00007ffff69e2d33 in task_impl::task_loop(boost::function<void
()()> const&) ()
from /opt/radiomap/lib64/libuhd.so.003
#3 0x00007ffff6fbcc90 in thread_proxy () from
/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0
#4 0x0000003f29207851 in start_thread () from /lib64/libpthread.so.0
#5 0x0000003f286e890d in clone () from /lib64/libc.so.6
Thanks!
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130401/ceadb53a/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 01 Apr 2013 12:13:42 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming
two concurrent channels regardless of sample rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/01/2013 11:45 AM, Pruitt, Paul N. wrote:
> I am using an N210 with this software configuration:
>
> linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4);
> Boost_104400;
>
> UHD_003.005.000-27-gfcfcc01f
>
>
>
> When I stream data from one DDC using sc16 wire format at 1 MSPS,
> according to htop, the CPU utilization is ~1% for the conversion thread
> and nearly the same for the application thread that receives the data
> and currently does nothing with it. At 10 MSPS, the CPU utilization is
> 16% for each of these threads. Very reasonable.
>
>
The n>1 converter threads are actually spinning and thread yielding when
there are multiple channels per streamer. So, one of the effects is that
you would see CPU usage climb up for the core hosting that thread.
Is it a problem BTW? This could be addressed with condition variables
pretty easily.
-josh
------------------------------
Message: 3
Date: Mon, 1 Apr 2013 17:27:04 +0000
From: "Macre, William R" <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E1XX update additional step
Message-ID:
<5e9bdf6832e57149b46d9becf6ab21510cf44...@rrc-ats-exmb2.ats.atsinnovate.com>
Content-Type: text/plain; charset="utf-8"
Philp:
I also am having the same problem as Alex Gladd. After the upgrade I reboot
the unit and it hangs up immediately after loading the E110 FPGA. It gets to
the ?DONE=1? message and ?Configuration complete? then hangs. Very repeatable.
If I can replace the new FPGA build with the previous one, will it work with
the new UHD code???
Wrm
From: USRP-users [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, March 29, 2013 7:40 PM
To: [email protected]
Subject: [USRP-users] E1XX update additional step
After running upgrade, reboot the unit so you are running on the new kernel.
Philip
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130401/e2d8de09/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 1 Apr 2013 13:43:06 -0400
From: "Pruitt, Paul N." <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming
two concurrent channels regardless of sample rate
Message-ID:
<f82ab11a5a3e584b8a5148146c5475410672e...@0015-its-exmb14.us.saic.com>
Content-Type: text/plain; charset="us-ascii"
Josh,
Thank you for the prompt response!
Some background disk writes occur while streaming in this particular
application. With a single channel, that disk I/O "keeps up." When I
attempt to stream two simultaneous channels, even at lower aggregate
rates, it doesn't. Also, the system becomes unresponsive at times
during two-channel tests.
Though the conversion thread does run at realtime (SCHED_RR) priority,
it is very odd that the added CPU load would affect the system like
that. The software is running on a quad-core/8-thread Core i7 laptop
with several idle cores/threads. I am using Centos 6.4 and their 2.6.32
kernel, which is pretty old.
Now I see the yields in reusable_barrier. You would swap the barrier in
converter_thread_task() with condition variables? If you'd be willing to
sketch out what I should change, I will test it out and report back.
Best regards,
Paul
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf
Of Josh Blum
Sent: Monday, April 01, 2013 1:14 PM
To: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming two
concurrent channels regardless of sample rate
On 04/01/2013 11:45 AM, Pruitt, Paul N. wrote:
> I am using an N210 with this software configuration:
>
> linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4);
> Boost_104400;
>
> UHD_003.005.000-27-gfcfcc01f
>
>
>
> When I stream data from one DDC using sc16 wire format at 1 MSPS,
> according to htop, the CPU utilization is ~1% for the conversion
> thread and nearly the same for the application thread that receives
> the data and currently does nothing with it. At 10 MSPS, the CPU
> utilization is 16% for each of these threads. Very reasonable.
>
>
The n>1 converter threads are actually spinning and thread yielding when
there are multiple channels per streamer. So, one of the effects is that
you would see CPU usage climb up for the core hosting that thread.
Is it a problem BTW? This could be addressed with condition variables
pretty easily.
-josh
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Mon, 01 Apr 2013 14:51:21 -0400
From: Philip Balister <[email protected]>
To: "Macre, William R" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E1XX update additional step
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 04/01/2013 01:27 PM, Macre, William R wrote:
> Philp:
>
> I also am having the same problem as Alex Gladd. After the upgrade I reboot
> the unit and it hangs up immediately after loading the E110 FPGA. It gets to
> the ?DONE=1? message and ?Configuration complete? then hangs. Very
> repeatable. If I can replace the new FPGA build with the previous one, will
> it work with the new UHD code???
Can you try with a new sd card built from:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Images
It worked for me and at least one other person.
Philip
>
> Wrm
>
>
> From: USRP-users [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Friday, March 29, 2013 7:40 PM
> To: [email protected]
> Subject: [USRP-users] E1XX update additional step
>
> After running upgrade, reboot the unit so you are running on the new kernel.
>
> Philip
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
------------------------------
Message: 6
Date: Mon, 1 Apr 2013 19:27:07 -0400
From: "Pruitt, Paul N." <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming
two concurrent channels regardless of sample rate
Message-ID:
<f82ab11a5a3e584b8a5148146c5475410672e...@0015-its-exmb14.us.saic.com>
Content-Type: text/plain; charset="us-ascii"
I perpetrated this egregious, one-line hack to see the effect on CPU
utilization for my two-channel streaming case:
diff --git a/host/include/uhd/utils/atomic.hpp
b/host/include/uhd/utils/atomic.hpp
index 7a81d8d..0868447 100644
--- a/host/include/uhd/utils/atomic.hpp
+++ b/host/include/uhd/utils/atomic.hpp
@@ -100,6 +100,8 @@ namespace uhd{
if (_count.read() == boost::uint32_t(~0))
throw boost::thread_interrupted();
boost::this_thread::yield();
+ // pnp throttle
+
boost::this_thread::sleep(boost::posix_time::microseconds(10));
}
}
With the 10 usec delay in the loop, the CPU utilization went from two
tasks at 100+% each to 40% and 27% respectively at 10 MSPS * 2 channels.
No overruns. Load average much lower.
I am letting it run for a while.
Paul
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf
Of Josh Blum
Sent: Monday, April 01, 2013 1:14 PM
To: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming two
concurrent channels regardless of sample rate
On 04/01/2013 11:45 AM, Pruitt, Paul N. wrote:
> I am using an N210 with this software configuration:
>
> linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4);
> Boost_104400;
>
> UHD_003.005.000-27-gfcfcc01f
>
>
>
> When I stream data from one DDC using sc16 wire format at 1 MSPS,
> according to htop, the CPU utilization is ~1% for the conversion
> thread and nearly the same for the application thread that receives
> the data and currently does nothing with it. At 10 MSPS, the CPU
> utilization is 16% for each of these threads. Very reasonable.
>
>
The n>1 converter threads are actually spinning and thread yielding when
there are multiple channels per streamer. So, one of the effects is that
you would see CPU usage climb up for the core hosting that thread.
Is it a problem BTW? This could be addressed with condition variables
pretty easily.
-josh
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Mon, 01 Apr 2013 22:06:15 -0500
From: Josh Blum <[email protected]>
To: "Pruitt, Paul N." <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming
two concurrent channels regardless of sample rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/01/2013 06:27 PM, Pruitt, Paul N. wrote:
> I perpetrated this egregious, one-line hack to see the effect on CPU
> utilization for my two-channel streaming case:
>
> diff --git a/host/include/uhd/utils/atomic.hpp
> b/host/include/uhd/utils/atomic.hpp
> index 7a81d8d..0868447 100644
> --- a/host/include/uhd/utils/atomic.hpp
> +++ b/host/include/uhd/utils/atomic.hpp
> @@ -100,6 +100,8 @@ namespace uhd{
> if (_count.read() == boost::uint32_t(~0))
> throw boost::thread_interrupted();
> boost::this_thread::yield();
> + // pnp throttle
> +
> boost::this_thread::sleep(boost::posix_time::microseconds(10));
> }
> }
>
> With the 10 usec delay in the loop, the CPU utilization went from two
> tasks at 100+% each to 40% and 27% respectively at 10 MSPS * 2 channels.
> No overruns. Load average much lower.
> I am letting it run for a while.
>
Good idea actually :-)
This is a four line patch to serialize the conversions, no extra
threads: http://pastebin.com/0Q2UDB8x
I will try to get back to you in the morning using something with
condition variables.
-josh
> Paul
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf
> Of Josh Blum
> Sent: Monday, April 01, 2013 1:14 PM
> To: [email protected]
> Subject: Re: [USRP-users] High CPU utilization (100%) when streaming two
> concurrent channels regardless of sample rate
>
>
> On 04/01/2013 11:45 AM, Pruitt, Paul N. wrote:
>> I am using an N210 with this software configuration:
>>
>> linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4);
>> Boost_104400;
>>
>> UHD_003.005.000-27-gfcfcc01f
>>
>>
>>
>> When I stream data from one DDC using sc16 wire format at 1 MSPS,
>> according to htop, the CPU utilization is ~1% for the conversion
>> thread and nearly the same for the application thread that receives
>> the data and currently does nothing with it. At 10 MSPS, the CPU
>> utilization is 16% for each of these threads. Very reasonable.
>>
>>
>
> The n>1 converter threads are actually spinning and thread yielding when
> there are multiple channels per streamer. So, one of the effects is that
> you would see CPU usage climb up for the core hosting that thread.
>
> Is it a problem BTW? This could be addressed with condition variables
> pretty easily.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Tue, 2 Apr 2013 12:34:30 +0800 (SGT)
From: ZaInzAiN Jj <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Disable Pad for USRP
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear All,
I want to ask, How to disable Pad for USRP? I use USRP N210 and gnuradio 3.6.4.1
Best Regards,
Zai
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130402/228a1f59/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 02 Apr 2013 14:59:50 +0200
From: Florian Schlembach <[email protected]>
To: [email protected]
Subject: [USRP-users] Purpose of 24-bit CORDIC in DDC chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I am just analysing the FPGA code of the DDC chain. I just got stuck
when trying to find out the purpose of the CORDIC that comes right after
the ADCs.
According to my understanding, the only purpose of the CORDIC is to add
a certain phase increment using an efficient multiplier-free
implementation. The subsequent decimation of incoming, 100 MHz sampled
data (dealing with N210) is then performed via the CIC and Halfband filters.
Is that correct?
------------------------------
Message: 10
Date: Tue, 02 Apr 2013 09:57:58 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Purpose of 24-bit CORDIC in DDC chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 02 Apr 2013 08:59, Florian Schlembach wrote:
> I am just
analysing the FPGA code of the DDC chain. I just got stuck
> when
trying to find out the purpose of the CORDIC that comes right after
>
the ADCs.
> According to my understanding, the only purpose of the
CORDIC is to add
> a certain phase increment using an efficient
multiplier-free
> implementation. The subsequent decimation of
incoming, 100 MHz sampled
> data (dealing with N210) is then performed
via the CIC and Halfband filters.
>
> Is that correct?
>
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
It's
used to do arbitrary up/downconversion, with high precision, of the
sample stream coming off the ADC.
Many daughtercards have fairly
coarse tuning step size, so the CORDIC in the FPGA is used in those
cases to tune to a precise frequency, as requested by the user.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130402/4ccde842/attachment-0001.html>
------------------------------
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 32, Issue 1
*****************************************
