On Nov 24 2013 10:08 AM, Dewey Garrett wrote: > # 131124:10.05 > I successfully tested these kernel debs on top of a xubuntu-quantal > install on a lenovo sl510 (laptop) and built linuxcnc from > git-master: > > $ lsb_release -idcr > Distributor ID: Ubuntu > Description: Ubuntu 12.10 > Release: 12.10 > Codename: quantal > > $ uname -a > Linux u51 3.4.55-rtai-1 #1 SMP PREEMPT Mon Aug 5 21:16:12 MDT 2013 > i686 i686 i686 GNU/Linux > > $ cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-3.4.55-rtai-1 root=/dev/sda7 ro > > $ git l --oneline -1 > 519bb5d deb: provide build-arch and build-indep targets in > debian/rules > > Some latency plots: > > http://www.panix.com/~dgarrett/stuff/screenshots/latencyhistogram-rtai3.4.55.png > > http://www.panix.com/~dgarrett/stuff/screenshots/latencyplot-rtai3.4.55.png > > A long (>2000 secs) histogram run shows some spikes above 20uS > (but it is a laptop). > > No hardware is hooked to this machine but simulator inifiles > run ok. > > Thanks to the workers on this kernel. > dewey
Dewey, Thanks for the detailed latency plots and very good work! Borrowing from some of my experience in scale break analysis in ecological systems, looking at the plot on the left there appear to be at least 2 and likely 3 separate underlying processes which are inducing the latency. Basically, many real world phenomena exhibit an exponential decay of their dominant processes. When looking at system dynamics over several orders of magnitude you can see areas where different processes become dominate and either overpower the other processes, or what is more likely in our case, become additive. When you plot these on a log plot, they become linear and just pop out. Applying this to the latency plots, the clear primary process is producing a linear slope (on a log-linear plot) starting at 0 and heading steeply towards ~4us. The behaviour is symmetrical which means that as long as we can stand a 4us worst case latency that cleaning up the other processes will allow us to assume that the +/- delays will roughly cancel out (although I am sure that my comment will spark a roaring debate). You will notice that there is what appears as a horizontal shelf between 3us to 6us, and then the nice linear slope continues down to around 8us (with a hand full of outliers at 9, 10 and 20us). Looking at the Y scale, it looks like if 1 out of every 1,000,000 samples you added an additional 3us to 4us to the first processes response. If you did this I would expect that you would end up something along these lines. The fact that it is so clean makes me wonder if there is something configured to run on that kernel (or maybe an intrinsic piece of the hardware) which runs at a multiple of 25. In particular I wonder if your kernel has CONFIG_HZ_250 set. Even though this is not the 25 seconds I would like to perfectly see, you could could have these causing a problem one out of 100 times and you would not only get the behaviour that you are seeing, but it might also explain the 20us latencies as well. Can you try playing with your CONFIG_HZ* settings and try 100, 1000, and tickless (although that will likely require experimenting with a 3.10+ kernel)? In particular moving away from any periodic timers to on-demand may help alleviate this, but I understand that bumping the kernel revision can be a LOT of work for RTAI as I have done ity a few times in the past... Hope my ramblings are useful... EBo -- ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
