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
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
