discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop canno


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.
Date: Mon, 27 Sep 2010 06:39:14 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

> Hi all!
>
> I am Tx/Rx a FM signal at the same time, but I can see a lot of SSSSS
> 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 %MEM    TIME+     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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]