Am 27.05.2013 um 10:26 schrieb John Candlish <[email protected]>:
> On Mon, May 27, 2013 at 7:54 AM, Michael Haberler <[email protected]>wrote: > >> >> >> - the branch you compiled, and the configure options >> > > 25may pull from v2.5_branch > > - the operating system version and source >> > > Kernel: vmlinuz-2.6.38.8-120804.a-multitouch-rtai > this is 2.6.38.8 with multitouch and rtai (3.9magma from august '12) > applied. > OS: Debian 'jessie' amd64 > > - the invocation line of the hostmot2 driver >> > > loadrt hm2_pci config="firmware=hm2/5i23/SVST8_4.BIT" > > >> >> so far I do not even know this is a kernel or userland build; >> /var/log/messages hints at userland but I cannot tell >> >> since RTAPI messages go some very different flows depending on branch and >> build options, all guesses are off >> >> > I am rather confident that is is a simple non-blocking buffering problem > from 'rtapi_print_msg'. Since this a v2.5_branch RTAI build, this rtapi_print uses the rt_printk function like here: line 449 http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/rtapi/rtai_rtapi.c;h=a43f082b65ef0219bc8ac506c9101d765f1cc343;hb=refs/heads/v2.5_branch#l446 without looking at the RTAI code, but with knowing several 'RT print' like implementations, my prediction is: there is a limited size buffer or ring buffer behind this, and messages are dequeued outside the RT context since hm2 writes _a lot_ in this phase, its not unlikely such a buffer is overrun since the dequeuer task cant keep up nice? no. A linuxcnc problem? not either. A problem at all? likely not. if you want to investigate, investigate rt_printk(); I would think you're thundering down the wrong alley looking at linuxcnc > > I note that the behavior of this call has changed in > 'rtos-integration-preview3', with the output messages going to hal's tty > rather than the system message logging facility. yes, and the code finally merged will change this once more, so dont invest time here it has a portable abstraction of the abovementioned ringbuffer code to get rid of various per-thread-scheme 'print something safely' type functions, and to make such messages accessible to the rest of linuxCNC in a coherent way > I have, within the last 2 hours configured and compiled > 'rtos-integration-preview3' against '3.2.0-4-rt-amd64 #1 SMP PREEMPT RT > Debian 3.2.41-2+deb7u2 x86_64', which is the vanilla -rt kernel from > 'jessie'. > > In this instance the pin enumeration is correct. that confirms my above suspicion it's an rt_printk issue > Well, your preview3 stuff against a vanilla jessie kernel enumerates > hostmot2 pins correctly on hal's tty rather than /var/log/messages. > v2.5_branch against vmlinuz-2.6.38.8-120804.a-multitouch-rtai writes > 'rtapi_print_msg' to /var/log/messages, incorrectly. > > vmlinuz-2.6.38.8-120804.a-multitouch-rtai has less that 5us latency. > 3.2.0-4-rt-amd64 has ~50us latency. This is better than Xenomai for me. I think to compare apples with apples, you want to resolve the SMI issue first - otherwise that statement doesnt make a whole lot of sense the way I gauge the Xenomai folks you should have that resolved in rather short time if it is possible at all; they are quite eager to polish and improve usability > Further with respect to 3.2.0-4-rt-amd64 latency. There are latency spikes > on invocation, but once it 'warms up' the latency goes down to about > ~25us. Is this consistent with what others have observed? yes, that is quite likely. It would be useful to nail this down though, so any hints as to correlation with setups, certain components etc would be welcome. > Finally, is 64bit getting good test coverage? I note that vast majority of > users are on 32bits. > > I will most likely proceed with v2.5_branch against > vmlinuz-2.6.38.8-120804.a-multitouch-rtai. I would like to try to fix > (read: understand) its issue with 'rtapi_print_msg'. The vibrant community at [email protected] is at your disposition, all three of them ;) - Michael ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
