Am 14.11.2012 um 08:19 schrieb John Morris: > On 11/12/2012 11:27 PM, John Morris wrote: >> I'm going back to try to recreate your setup. Found your kernel config >> file. If you have one around, please send a LinuxCNC build log to help >> guess what the differences might be. > > While sitting around waiting for the umpteenth time for the Xenomai > kernel to build, this time with Michael's config just to help narrow > things down, I compiled up LinuxCNC xenomai-user. > > Latency-test works. And on the same kernel that, combined with > xenomai-kernel, hangs! 64-bit uniprocessor running several glxgears > (why's that the test we always use?), loading up Firefox with a buggy > load of saved tabs, compiling that same xenomai kernel and spinning > shapes around in FreeCAD, latency-test reported 7ms/6ms jitter.
That result both Kent and me are puzzled about.. conventional wisdom would imply 'kernel threads might have lower latency'. The really hard question for the future (LinuxCNC3) is: does it make sense to support kernel threads builds at all? if the above results turn out to be reproducible, the answer to this might be 'sorry, to gain exactly _what_?' which opens a wide range of options to simplify things in LinuxCNC3 > Also, Michael told me today that xenomai-user will also compile for > Raspberry Pi, one of which my friend dropped in my lap a few weeks ago > and which I had no idea what to do with until now. note operative word 'compile': I didnt get the GUI's to run because of some Python OpenGL support missing, this could be me or support for OpenGL on the Pi; likely me. runtests is ok. what does work nicely is HAL+RTAPI; also I cooked up a primitive Pi GPIO driver (src/hal/drivers/hal_gpio) which wiggles pins just fine. Now if only motion had a sane message interface we already would have a working 'RT outboard' by now. With xenomai as RT base, the range of architectures is in fact wide open: http://www.xenomai.org/index.php/Embedded_Device_Support the architecture dependent code in src/rtapi/rtapi_bitops.h can nowadays be handled by GCC builtin atomic operations which obviates the need for assembly, this is enabled by --enable-gcc-atomic-ops and forced by --with-platform=raspberry . That should in fact compile on any washer & dryer supported by gcc. I need to write up the status, and the pre-merge laundry list. The viability of PCI I/O in userthreads builds is still pending verification. The upside of doing this: debugging RT code with gdb like any other user program simplifies things drastically. - Michael > > Woo hoo! What a wonderful turn of events after a crummy week. > > John > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
