Kirk Wallace wrote: >On Tue, 2008-07-29 at 17:36 +0100, paul_c wrote: > > >>Hi Dan >> >>On Friday 25 July 2008, Organic Engines wrote: >> >> >>> After a whole bunch of thought it occurred to me that sound is >>>essentially real time and probably a resource hog. >>> >>> >>I'd suggest using tools like top or htop to profile the system in >>order to identify the resource hogs - Sound doesn't consume much CPU >>time in comparison to some of the other stuff. If you are running >>Gnome or KDE desktop, replace it with a lightweight window manager >>such as xfce4 or fluxbox. >> >> >I know enough about realtime to fill a thimble, but I got the impression >that the non-reatime stuff gets attention when the reatime stuff is >done. So realtime processes will take what they need until the >non-realtime processes stop running. Therefore, playing with the >non-realtime processes will only help the remaining non-realtime >processes(?). > That's basically correct. The thing that doesn't quite fit the model is uninterruptible areas of kernel code. There are certain things you really want to do as a unit (these are "atomic" operations).
>I think I would like to have an EMC realtime optimized PC >(headless or optional interface) controlled by a non-realtime EMC >application that could run on any standard linux PC (wink, wink, nudge, >nudge). At one time, I thought parts of EMC ran as semi-independent >programs, would it be difficult to segregate these parts across two PC's >(or Beowulf)? Would there be anything to gain? > > The user interfaces can run separate from the realtime PC. AXIS needs an environment variable to be set so it doesn't attempt to export HAL pins - HAL isn't networkable at the moment (at least not in RT - I think someone did make an ethernet HAL transport, but I don't remember the specifics). It's theoretically possible to run the IO controllers (spindle, lube, coolant ...) on a separate PC as well, since IO control is done with NML messages. NML can go over a network just as well as it can travel via a shared memory buffer, albeit slower. From what I've seen, networking causes RT blips in the 10 microsecond range. This should vary based on hardware, so YMWV. Disk access (on ext3) causes some issues. I didn't see a lot of change when I got rid of all the other stuff that runs on a normal Ubuntu system, other than going to a non-graphical boot. The experimentation I did was on a dual-core system, using a SMP RT kernel with isolcpus=1, so the RT code all ran on a separate core from the rest of the system. - Steve ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
