On Tuesday, January 31, 2012 09:53:43 AM andy pugh did opine: > On 31 January 2012 16:36, gene heskett <[email protected]> wrote: > > In grub, if the rtai kernel line has "isolcpus=1" appended, which > > takes cpu1 out of the scheduler, then after the boot in completed, > > everything is running on cpu0. > > > > Then, using taskset, put emc/linuxcnc to running on the now forcibly > > idled cpu1. > > I thought LinuxCNC did this automatically if isolcpus was set?
Apparently it does not, at least not on my box, Andy. There is a line in the dmsg output that seems to indicate it is aware of isolcpus, but IMO its wrong. In fact I'll look and see if taskset's use fixes that right now. No, that line: RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0). Hasn't changed. What little common sense I have left tells me that reported MASK: value s/b a 1, but its not. I also note that this rtai kernel has only a 250 hz timer, so that might cause a small loss in multitasking smoothness too. I use the older 1khz here on this box, but again, any diffs I see are likely 100% subjective. In any event it sure makes a HUGE difference here. Do your own test, install gkrellm and set it to show cpu usage by the core, then run linuxcnc. cpu1 will remain idle. Stop linuxcnc and use taskset 0x00000002 linuxcnc to run it again. Bingo, cpu1 now has some load showing, and you can probably cut the base thread time by half or more. The rest of the machine doesn't bother linuxcnc, and linuxcnc doesn't bother the rest of the machine. I've cut my base_thread time from 65 u- secs to 25 u-secs, which when it is running some gcode, shows cpu1 at about 50% usage. The rest of the machine seems to be running nominally where on the old single core athlonXP box, which ran at 1.4Ghz, a 25 u-secs base thread would have locked it up solidly. But when I get back out there to play today, I still have one more absolute show stopper. In doing a G38.2 f1 z2.5, it will probably stop well within a thou of contact. But then I am dead in the water because when I try to do a z move to #5063 + 0.01, it will move about .0005, breaking the contact, which is then reported as an error, shutting the machine down and no restart at that point is possible, only another full rerun from the top. IOW (& according to Gene,) linuxcnc should only pay attention to the probe status WHILE it is executing the G38.2, and shouldn't have any excuse to check the probe status AT ANY OTHER TIME. But it does & its a total show stopper, rendering the whole G38.2 concept unusable unless there is some Gcommand I could put in after the G38.2 to disable probe sensing until its needed again at the next tool change. Hasn't G38.2 completed its job when contact has been detected, the axis stopped and all 9 positions recorded in the #5061-#5070 block? Thanks Andy. Does anybody else have any clues, or is this a real, live bug in linuxcnc? Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> If we were meant to get up early, God would have created us with alarm clocks. ------------------------------------------------------------------------------ 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
