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
