Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

2010-10-02 Thread Jorge Miguel
Tom,

This doesn't sound like a performance issue.
I absolutely agree.

I think you're probably looking at a sample rate mismatch somewhere.
 If it were the case. Don´t you think that FM transmitter by itself and FM
receiver by itself shouldn´t work neither?
The point is that both of them when running alone work. That is the fact I
do not understand.

Regards,
Jorge.



On 2 October 2010 17:03, Tom Rondeau trondeau1...@gmail.com wrote:

 On Thu, Sep 30, 2010 at 5:52 AM, Jorge Miguel jmig...@gmail.com wrote:
  Hi !
 
  Eric, thanks for your advise. Some results here.
 
  I set my computer into performance mode. At first sight nothing
 improves.
 
  With the example usrp2_fft.py I can low the decimation to 5 and the
  application works ok.
 
  As I said the FM modulator works ok by itself. The FM demodulator also
 works
  ok by itself. The problem is when I run both in the same flowgraph. I
 think
  it is not a problem of performance since my CPUs are not very work-loaded
  when my application is running.
 
  My problem is that changes, in the FM modulator, which I think they would
  increase performance (like increasing my 13 interpolation in the USRP and
  decreasing my software interpolation) make my receiver chain non-working
  (SSS messages) although the transmitter outputs a perfect FM signal.
 
  I do not understand these mesages since my CPUs are less than 15-20%
 used.
  However something is stopping the received data because I got a lot of
  dropped frames in my rx Ethernet interface (saw with ifconfig). I tried
 to
  increase the RX Ethernet buffer (sysctl -w net.core.rmem_max=X) but
 it
  didn't work. I also tried to set in my generated code the USRP source
  instance before the USRP sink but it didn't work neither.
 
  Could be any reason why by decreasing software computation (and Ethernet
  traffic as well) in the transmitter path affects the performance of the
 RX
  path?
 
  Many thanks,
  Jorge.

 This doesn't sound like a performance issue. I think you're probably
 looking at a sample rate mismatch somewhere.

 Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

2010-09-30 Thread Jorge Miguel
Hi !

Eric, thanks for your advise. Some results here.

I set my computer into performance mode. At first sight nothing improves.

With the example usrp2_fft.py I can low the decimation to 5 and the
application works ok.

As I said the FM modulator works ok by itself. The FM demodulator also works
ok by itself. The problem is when I run both in the same flowgraph. I think
it is not a problem of performance since my CPUs are not very work-loaded
when my application is running.

My problem is that changes, in the FM modulator, which I think they would
increase performance (like increasing my 13 interpolation in the USRP and
decreasing my software interpolation) make my receiver chain non-working
(SSS messages) although the transmitter outputs a perfect FM signal.

I do not understand these mesages since my CPUs are less than 15-20% used.
However something is stopping the received data because I got a lot of
dropped frames in my rx Ethernet interface (saw with ifconfig). I tried to
increase the RX Ethernet buffer (sysctl -w net.core.rmem_max=X) but it
didn't work. I also tried to set in my generated code the USRP source
instance before the USRP sink but it didn't work neither.

Could be any reason why by decreasing software computation (and Ethernet
traffic as well) in the transmitter path affects the performance of the RX
path?

Many thanks,
Jorge.

On 28 September 2010 05:43, Eric Blossom e...@comsec.com wrote:

 On Mon, Sep 27, 2010 at 10:07:07AM +0200, Jorge Miguel wrote:
  Hi all!
 
  I am Tx/Rx a FM signal at the same time, but I can see a lot of S
  messages that mean my CPU cannot keep up with all frames generated by the
  USRP2 and drop most of them.
  However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU
  M 520  @ 2.40GHz  on Ubuntu 10.4
 
  I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can
  balance the workload among all my four cores to see if my application
  improves (ethernet interface doens't drop any frame).
 

 First off, you don't really have 4 cores.  You've got 2 cores +
 hyperthreading (they may have renamed it, but that's what you've got).

 GNU Radio will automatically use whatever you've got, without you
 having to do anything special.

 Be sure that your laptop is in Performance mode, and not trying to
 save energy, or throttle back etc.  There are also some laptops out
 there that have poor thermal design and can't really run at full speed
 without overheating and thus throttling back the CPU.

 Start with something like usrp_fft.py and see how low of a decimation
 factor you can work with reliably.  That will give you a basic idea of
 how your system is working.

 If you're building your own flow graphs, it's quite easy to string
 together more blocks, or use a a higher sample rate, than your machine
 can keep up with.

 After you've ruled out the stuff above, oprofile will help you sort
 out which parts of your application are burning the most time.

 Eric

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

2010-09-27 Thread Jorge Miguel
Hi all!

I am Tx/Rx a FM signal at the same time, but I can see a lot of S
messages that mean my CPU cannot keep up with all frames generated by the
USRP2 and drop most of them.
However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU
M 520  @ 2.40GHz  on Ubuntu 10.4

I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can
balance the workload among all my four cores to see if my application
improves (ethernet interface doens't drop any frame).

Looking at other post of the mailing list I found:

1)Try using numactl.
Well, for me is not possible, after installing that library and running:
:~$ numactl -s
physcpubind: 0 1 2 3
No NUMA support available on this system.

2)Look at the output of cat /proc/cpuinfo physical id indicates which
cores are in which sockets
In all four processors physical id: 0

Furthermore whe I execute top command I can see:
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+ COMMAND
 3022 root 20   0  238m  66m  45m   S  166 3.6
3:32.12 python


Is my GRC file only executing in one core? How can I find it out?
Any idea to fix it?

Many thanks,
Jorge
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

2010-09-27 Thread Marcus D. Leech
 Hi all!

 I am Tx/Rx a FM signal at the same time, but I can see a lot of S
 messages that mean my CPU cannot keep up with all frames generated by
 the USRP2 and drop most of them.
 However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5
 CPU   M 520  @ 2.40GHz  on Ubuntu 10.4

 I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I
 can balance the workload among all my four cores to see if my
 application improves (ethernet interface doens't drop any frame).

 Looking at other post of the mailing list I found:

 1)Try using numactl.
 Well, for me is not possible, after installing that library and running:
 :~$ numactl -s
 physcpubind: 0 1 2 3
 No NUMA support available on this system.

 2)Look at the output of cat /proc/cpuinfo physical id indicates
 which cores are in which sockets
 In all four processors physical id: 0

 Furthermore whe I execute top command I can see:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+ COMMAND 
  3022 root 20   0  238m  66m  45m   S  166 3.6  
 3:32.12 python


 Is my GRC file only executing in one core? How can I find it out?
 Any idea to fix it?

 Many thanks,
 Jorge


   
CPU scheduling is generally the responsibility of the operating system
kernel, *NOT* Gnu Radio.  What Gnu Radio does is schedule
  blocks to threads, and the execution of those threads, and CPU
assignment is up to the kernel.  In general, the kernel does a good
  job of CPU scheduling.

Your problem is probably that your flow-graphs aren't optimal in some
way, and thus take more system resources than they should.

The other issue may be your GiGE network interface might be one that
isn't very good in the buffering department, and thus makes the
  system work *much* harder than it should handling continuous packet
traffic.

What bandwidth are you using?  (That is, what decimation/interpolation
are you using)?

You haven't shared much in the way of details about your flow-graph, and
I suspect that's where your problem lies.

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow

2010-09-27 Thread Jorge Miguel
* *CPU scheduling is generally the responsibility of the operating system
* *kernel, *NOT* Gnu Radio.  What Gnu Radio does is schedule
 blocks to threads, and the execution of those threads, and CPU
 assignment is up to the kernel.  In general, the kernel does a good
 job of CPU scheduling.

* *Your problem is probably that your flow-graphs aren't optimal in some
* *way, and thus take more system resources than they should.
Yes, I do not why it takes a lot of resources alhough I can see with
gkrellm application that my CPUs are about 50-60%, so it is not so
bad.

* *The other issue may be your GiGE network interface might be one that
* *isn't very good in the buffering department, and thus makes the
* *  system work *much* harder than it should handling continuous packet
* *traffic.

* *What bandwidth are you using?  (That is, what decimation/interpolation
* *are you using)?
I am using 30,76Mbps in the transmitter (USRP interpolation sink 104)
I am using  6,25Mbps in the receiver (USRP decimation source 512)

* *You haven't shared much in the way of details about your flow-graph, and
* *I suspect that's where your problem lies.
I can post my .py file which is:
from gnuradio import audio
from gnuradio import blks2
from gnuradio import gr
from gnuradio import usrp2
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.wxgui import forms
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class top_block(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title=Top Block)

##
# Variables
##
self.tune_osc_dem = tune_osc_dem = 9400
self.tune_filter = tune_filter = 75000
self.samp_rate = samp_rate = 32000
self.fm_freq_mod = fm_freq_mod = 9400

##
# Controls
##
_tune_osc_dem_sizer = wx.BoxSizer(wx.VERTICAL)
self._tune_osc_dem_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_tune_osc_dem_sizer,
value=self.tune_osc_dem,
callback=self.set_tune_osc_dem,
label=Tunned frequency demodulator,
converter=forms.float_converter(),
proportion=0,
)
self._tune_osc_dem_slider = forms.slider(
parent=self.GetWin(),
sizer=_tune_osc_dem_sizer,
value=self.tune_osc_dem,
callback=self.set_tune_osc_dem,
minimum=8800,
maximum=10800,
num_steps=800,
style=wx.SL_HORIZONTAL,
cast=float,
proportion=1,
)
self.Add(_tune_osc_dem_sizer)
_tune_filter_sizer = wx.BoxSizer(wx.VERTICAL)
self._tune_filter_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_tune_filter_sizer,
value=self.tune_filter,
callback=self.set_tune_filter,
label=LPF Cutoff Freq,
converter=forms.float_converter(),
proportion=0,
)
self._tune_filter_slider = forms.slider(
parent=self.GetWin(),
sizer=_tune_filter_sizer,
value=self.tune_filter,
callback=self.set_tune_filter,
minimum=15000,
maximum=15,
num_steps=1000,
style=wx.SL_HORIZONTAL,
cast=float,
proportion=1,
)
self.Add(_tune_filter_sizer)
_fm_freq_mod_sizer = wx.BoxSizer(wx.VERTICAL)
self._fm_freq_mod_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_fm_freq_mod_sizer,
value=self.fm_freq_mod,
callback=self.set_fm_freq_mod,
label=FM frequency modulator,
converter=forms.float_converter(),
proportion=0,
)
self._fm_freq_mod_slider = forms.slider(
parent=self.GetWin(),
sizer=_fm_freq_mod_sizer,
value=self.fm_freq_mod,
   

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

2010-09-27 Thread Eric Blossom
On Mon, Sep 27, 2010 at 10:07:07AM +0200, Jorge Miguel wrote:
 Hi all!
 
 I am Tx/Rx a FM signal at the same time, but I can see a lot of S
 messages that mean my CPU cannot keep up with all frames generated by the
 USRP2 and drop most of them.
 However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU
 M 520  @ 2.40GHz  on Ubuntu 10.4
 
 I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can
 balance the workload among all my four cores to see if my application
 improves (ethernet interface doens't drop any frame).
 

First off, you don't really have 4 cores.  You've got 2 cores +
hyperthreading (they may have renamed it, but that's what you've got).

GNU Radio will automatically use whatever you've got, without you
having to do anything special.

Be sure that your laptop is in Performance mode, and not trying to
save energy, or throttle back etc.  There are also some laptops out
there that have poor thermal design and can't really run at full speed
without overheating and thus throttling back the CPU.

Start with something like usrp_fft.py and see how low of a decimation
factor you can work with reliably.  That will give you a basic idea of
how your system is working.

If you're building your own flow graphs, it's quite easy to string
together more blocks, or use a a higher sample rate, than your machine
can keep up with.

After you've ruled out the stuff above, oprofile will help you sort
out which parts of your application are burning the most time.

Eric

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio