Am 02.11.2012 um 22:53 schrieb Kent A. Reed: > On 11/2/2012 11:18 AM, Michael Haberler wrote: > > Are the machinations in debian/configure not relevant?
not for building with 'sh autogen.sh; ./configure ..'; that is TBD > OOPS - the syntax for adding a user to a group is > > # adduser <user> <group> > > and not addgroup as stated in the readme. fixed > > 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+ support for more than one core running an RT thread each isnt in place yet. I just outlined an idea but it's TBD. > > 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. your observations closely match mine. leave it alone - figures look reasonable; do something with it, like network I/O - a sudden spike every now and then. first, there's some xenomai-specific tools in /usr/xenomai/bin worth exploring, for instance the xenomai latency test: root@atom:/usr/xenomai/bin# ./latency == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| -0.585| -0.517| 2.108| 0| 0| -0.585| 2.108 RTD| -0.933| -0.641| 12.546| 0| 0| -0.933| 12.546 RTD| -1.211| -0.617| 2.098| 0| 0| -1.211| 12.546 Note that latency-test uses RTAPI, and it's entirely possible I committed some goof in the code; it would be worth researching if the spikes we see also appear in the xenomai-supplied latency test It seems to be possible to run both simultaneously; I'm doing that right now to see if the spike in the RTAPI version is reflected in the Xenomai version too [guess what, spike wont show with both latency tests running :-/ - it's a Heisenspike!] then, the kernel config could be at fault, too I just went through http://www.xenomai.org/index.php/Configuring_x86_kernels and http://www.xenomai.org/index.php/FAQs#Tips_and_tricks_setting_up_your_x86_kernel, and looking through /boot/config-3.2.21-xenomai+ ; I couldnt find an obvious blunder right away -- depending upon results, there are a few things which could be done; for instance compiling the kernel with ipipe debugging support and see whether that uncovers anything but first I guess the right thing to do is to verify whether the RTAPI is at fault or not - Michael > > 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 ------------------------------------------------------------------------------ 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
