The Wheezy PREEMPT_RT kernel works well on the newer hardware I've tested on. Plenty good enough if you've got "hardware assist", and maybe OK for with software step-gen if you don't need super high rates. RTAI/Xenomai jitter numbers are still about 2-4x better, but both are significantly more invasive patchsets, while the PREEMPT_RT code is gradually getting mainlined.
Details on use and some performance numbers are on the wiki: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC On 2/21/2013 1:34 AM, Lars Segerlund wrote: > On the a somewhat related note, debian wheezy have RT kernels > included, just for information I haven't tried it out yet. But it's > nice to have prebuilt. > > 2013/2/20 Michael Haberler <[email protected]>: >> >> Am 20.02.2013 um 22:07 schrieb Tom Easterday: >> >>> Let me re-ask the question, for which I gave too much prior information. >>> Apologies for that. Are there pre-built packages for RTAI on Ubuntu 12.04 >>> Precise? >>> -Tom >> >> no, which was part of the reason for the Xenomai/RT-PREEMPT effort >> >> but you will very likely be able to run precise with the existing RTAI >> kernel just fine by manual installation with dpkg >> >> - Michael >> >> >>> >>> >>> >>> On Feb 20, 2013, at 3:52 PM, Michael Haberler <[email protected]> wrote: >>> >>>> Tom, >>>> >>>> Am 20.02.2013 um 20:29 schrieb Tom Easterday: >>>> >>>>> I have a problem that looks like either process scheduling, or buffering, >>>>> some sort of blocking on a linuxcnc host running 12.04/Xenomai and >>>>> 2.6.0pre. It does not display this problem on 10.04/RTAI and 2.6.0pre >>>>> (same base hardware, an intel atom board). The symptom is that when >>>>> continuously jogging, a DRO showing position on a remote device changes >>>>> smoothly when talking to 10.04/rtai. On 12.04/xenomai we get a distinct >>>>> pattern of three updates and a pause, three updates and a pause. The >>>>> pause is some number of milliseconds long (1/4 second maybe) and >>>>> distinctly visible. The remote connection is through our web server >>>>> (Rockhopper) over tcp (websocket) on wired ethernet. >>>>> >>>>> We first thought it was packet buffering or network latency and played >>>>> with TCP parameters and system buffers but that had no effect. We put >>>>> timing statements in the web server code at the point were we write the >>>>> data out and it appears that the whole web server process is being >>>>> blocked or something. We tried re-nicing the web server but it didn't >>>>> help. If we run Axis locally while doing this it doesn't display this >>>>> pause, it moves along smoothly as one would expect. >>>>> >>>>> For debugging I thought I might try 12.04 and rtai to see if it was just >>>>> with the xenomai kernel or if rtai on 12 does it as well. Are there rtai >>>>> packages available for 12.04 yet? I was going through the email list >>>>> archive on the new RT stuff but don't see any pointer to packages on rtai >>>>> specifically... >>>>> >>>>> Any thoughts on what we might look at to narrow it down further? >>>> >>>>> From the above I can tell: >>>> >>>> - you are running some of your own code because you cite some 'web server' >>>> which is not part of a released or working branch. Where is the code, the >>>> configuration you are using, and the exact sequence of commands leading up >>>> to it? >>>> - you say you are running '2.6.0pre', whatever that is, that tag isnt a >>>> unique identifier. Please state repository, branch name, commit, and which >>>> changes you did. >>>> - you do not say anything about hardware, exact lan setup including any >>>> intermediate hardware, the board, kernel version - how are we supposed to >>>> guess? >>>> >>>> With that level of information, my thought is that you will get zero help >>>> in narrowing down things further, simply because it is impossible. >>>> >>>> -- >>>> >>>> that said, what I suggest you do is: triage the problem into a) network >>>> driver and hardware b) tcp kernel stack and throughput c) application. >>>> >>>> a) Find throughput tests which measure at the packet loss level with the >>>> least kernel intervention, that is - raw throughput tests at the ethernet >>>> or UDP level. Find out if there are significant differences between >>>> operating systems on the same hardware. Change hubs/switches or whatever >>>> have in between. Try a crossover cable. >>>> >>>> b) do the same including the TCP stack which measures end-to-end >>>> throughput at the TCP level. Observe the TCP retransmission numbers in >>>> netstat which should give a clue. >>>> >>>> c) as for application level issues, install wireshark and pcap, and trace >>>> the flow between the programs which show the the issue - we dont know >>>> which they are since you do not tell. The packet capture will include >>>> timestamps and TCP retransmissions which hint at network problems. If you >>>> see any retransmissions, try alternate hardware and drivers - this zoo has >>>> many animals. Try with everyting on one machine to exclude network issues. >>>> >>>> And: read this: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html >>>> >>>> -- >>>> >>>> One reason why I suggest you produce a more thorough report, and not some >>>> ephemeral problem narrative: I spent several hours recently in a off-list >>>> debugging session on a 'reported Xenomai problem'. The problem was finally >>>> resolved by me demanding to 'yank that ethernet hub *now* and throw it in >>>> the wastebin' in no uncertain words. No more Xenomai issues since. Btw >>>> that was a device 'which always used to work so far'. So much for >>>> perceived causality. >>>> >>>> >>>> - Micahel >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_d2d_feb >>>> _______________________________________________ >>>> Emc-developers mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/emc-developers >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> Emc-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Charles Steinkuehler [email protected] ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
