[Top][All Lists]
[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