On Tue, Jan 3, 2012 at 17:02, Marcus D. Leech wrote:
> Wrt: wxPython--don't forget that the FFT display is *heavily* decimated in
> the typical case, arranging for the FFT to be called only as often
> as is required the maintain the desired display rate (a few Hz,
> typically). But maybe that'
On Tue, Jan 3, 2012 at 8:02 PM, Marcus D. Leech wrote:
>
>>
>> The uhd_fft.py uses the wxPython GUI interface, which does most of its
>> work in Python. Can you separate the symbols to see more specifically where
>> the processing is happening?
>>
>> Tom
>>
>> I asked for symbols when I did the
The uhd_fft.py uses the wxPython GUI interface, which does most of its
work in Python. Can you separate the symbols to see more specifically
where the processing is happening?
Tom
I asked for symbols when I did the opreport, but for libpython, it
didn't produce a by-symbol breakdown, which
On Tue, Jan 3, 2012 at 7:41 PM, Marcus D. Leech wrote:
> Decided this evening to grab some quick profile data for a uhd_fft.py,
> running at 50Msps from a USRP2.
>
> The kernel was occupied 41% of the time--no great surprise. Handling
> interrupts, doing the network stack "stuff".
>
> The next l
Decided this evening to grab some quick profile data for a uhd_fft.py,
running at 50Msps from a USRP2.
The kernel was occupied 41% of the time--no great surprise. Handling
interrupts, doing the network stack "stuff".
The next largest chunk was libc (memcpy_sse) 12.5%
Then uhd (convert_sc
