On 1/31/2012 10:02 AM, Ed Nisley wrote:
> On Mon, 2012-01-30 at 23:35 -0500, gene heskett wrote:
>> htop shows 2 cpu's with the 2nd one sitting at 0.0% use.
> As I understand it, that's the way it should be.
>
> The point of isolating the second CPU / core / whatever is to dedicate
> it to the real-time parts of RTAI, thus reducing interrupt latency. The
> CPU will sit there, completely idle, most of the time, so that when a
> real-time interrupt / task needs work, it can be dispatched immediately.
>
> Pinning AXIS to that "idle" CPU will definitely make the UI run much
> faster, but then the interrupt latency will (uh, should) get much worse,
> with the usual horrible effects on software step pulse generation.
>
> At least, that's how I think it works...
I think it's time for us to make an appeal to the developers who
understand the issues best.
Here's what I've gleaned from various places.
1) from the source code rtai_rtapi.c
---snip---
184 #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,0)
185 /* on SMP machines, we want to put RT code on the last CPU */
186 n = NR_CPUS-1;
187 while ( ! cpu_online(n) ) {
188 n--;
189 }
190 rtapi_data->rt_cpu = n;
191 #else
192 /* old kernel, the SMP hooks aren't available, so use CPU 0 */
193 rtapi_data->rt_cpu = 0;
194 #endif
---end snip---
2) from the RealTime entry in the Wiki
---snip---
"try restricting Linux from using one processor core
You do this by adding a kernel boot parameter to GRUB: "isolcpus=1" (or
"isolcpus=2,3" if you leave HT on) This will prevent Linux from
scheduling processes on the second core. If you have compiled RTAPI
against SMP kernel headers, then RTAPI will automatically use the
highest numbered CPU for realtime tasks.
If you do this, and don't see much improvement, then here's one more
thing to try. You'll need two terminals open for this. Run latency-test
in one terminal, and in the other, enter the following line, which will
run forever (until you press ctrl-C):
while true ; do echo "nothing" > /dev/null ; done
In my experience, the "cpu hog" (*) is able to reduce latencies from
10-20 microseconds down to perhaps 5-7uS.
jmkasunich theorizes that the hog uses very little memory, and since it
keeps one CPU busy, that CPU never runs any other code. So the RT code
doesn't get flushed out of cache, and doesn't have to get fetched back
into cache later."
---end snip---
I believe these items support Ed's response (and my earlier response as
well).
I still don't believe the usual process monitoring tools can "see" the
realtime processes. I think you (Gene) are seeing activity on cpu1 only
because you've explicitly moved non-realtime processes onto it.
It may well be that this placement of some non-realtime activity on cpu1
fulfills the function of the "cpu hog" that is described in the RealTime
entry.
I appeal for enlightenment from the RTAI experts.
Regards,
Kent
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
