On 11/2/2012 11:18 AM, Michael Haberler wrote: > I have now integrated the RT-PREEMPT branch as provided by Charles, added the > now-working Xenomai-userland thread style, and massaged configure to deal > with all of this. The Xenomai-kernel branch I reported about yesterday is > fully integrated. If you played with that branch, it's safe to switch. > > this adds the following scenarios: > > ./configure --with-threads=xenomai-user > > ./configure --with-threads=rt-preempt-user > > ./configure --with-threads=rtai > > ./configure --enable-simulator [--enable-drivers for the hal_parport usermode > driver]
Are the machinations in debian/configure not relevant? > > > <...> > > Please pull from > http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/rtos-integration-preview1 > I'm feeling especially old and crusty today. Not being a git Master (in the sense of being master of all I survey) and failing in my several tries to "pull from ...", I used my father's time-honored advice "don't force it; get a bigger hammer", in this case, by creating and downloading a .tar.gz file via gitweb. Host: AMD Athlon II X4 640 cpu with 4GB memory on an ASUS M488T-M motherboard with Ubuntu 10.04LTS and LinuxCNC 2.6.0-pre built from sources. I previously posted results with this board to the Latency Test page on the Wiki. Installed your .deb files and did the housekeeping. OOPS - the syntax for adding a user to a group is # adduser <user> <group> and not addgroup as stated in the readme. --- The good news- LinuxCNC built for xenomai-kernel threads without a hitch. I love how fast a build goes with make running on multiple cores. Since this is a quadcore system, I set isolcpus=3 and rebooted into 3.2.21-xenomai+ The not so good news- I'm seeing the same sort of strange behavior I saw with the RT-PREEMPT patches earlier although not as strongly. RTAI - 1ms servo thread/25us base thread - max jitter 4401ns/2378ns after 3 hours Xenomai/kernel - 1ms servo thread/25us base thread - max jitter appeared to be running roughly 10000ns/10000ns after 45 minutes *but* then while I was doing something random the max jitter jumped to 89590ns/367129ns (at which point /proc/xenomai/stat said wait errors=8. last overrun=14, total overruns=76). Later, I reran the test unattended for an hour and again got roughly 10000ns/10000ns max jitter. Which is good but the burst is worrisome. The strange behavior is that as I increase the base period in 25us steps I see both base and servo jitters first increase for several steps then fall back somewhat to what seems to be a steady result at longish base periods. Here's what I get for a series of two-minute tests, always with a 1ms servo period. base period---max jitter (servo/base) 25us---5672ns/9734ns 50us---22037ns/32170ns 75us---24328ns/34338ns 100us---18712ns/30256ns 125us---17051ns/19064ns 150us---16775ns/19168ns 175us---14389ns/19667ms 200us---18403ns/21412ns I believe the last three or four sets are essentially equivalent. Does anyone understand why I'm getting this kind of behavior? It seems to be repeatable. Is it an artifact of latency-test or is it real? Were this a physical system, I'd wave my hands about being the system being in saturation at the shortest periods, but here...? I conjectured some time ago that the ASUS bios is perhaps causing a problem with both this board and the Atom board I'll be testing in a bit, but I need more data:-) Regards, Kent ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
