On Feb 25, 2013, at 1:46 PM, Michael Haberler <mai...@mah.priv.at> wrote: > looking at the system call timestamps should give a clue where time is spent > since it's for sure not the application code per se, which is trivial in this > case
I ran again with -r and the results are here: http://bgp.nu/~tom/pub/1204.systime.txt 12.04/Xenomai on Atom 2700 http://bgp.nu/~tom/pub/1004.systime.txt 10.04/rtai on Atom 2500 What stands out as different in these are set_thread_area differences: 10.04: 0.000338 set_thread_area({entry_number:-1 -> 6, base_addr:0xb77689a0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 12.04 0.008819 set_thread_area({entry_number:-1 -> 6, base_addr:0xb73ae700, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 And in 12.04 after the last "close(3") there are a whole bunch of things that don't appear in the 10.04 version (including nanosleep?): 0.000073 close(3) = 0 0.000065 futex(0xb74261f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 0.000066 futex(0xb7426134, FUTEX_WAKE_PRIVATE, 2147483647) = 0 0.000073 futex(0xb74262d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 0.001331 rt_sigaction(SIGXCPU, {0xb74214d0, [], SA_SIGINFO}, NULL, 8) = 0 0.000292 rt_sigaction(SIGINT, {0x804a440, [INT], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 0.000161 rt_sigaction(SIGTERM, {0x804a440, [TERM], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 0.000143 rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 0.000193 shmget(0x48484c34, 8, 0666) = 4882437 0.001290 shmctl(4882437, IPC_64|IPC_STAT, 0xbffa4878) = 0 0.000182 shmat(4882437, 0, 0) = 0xb7725000 0.000128 shmget(0x48414c32, 262000, 0666) = 5046292 0.000069 shmctl(5046292, IPC_64|IPC_STAT, 0xbffa48a8) = 0 0.000066 shmat(5046292, 0, 0) = 0xb736d000 0.000416 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 0.001391 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7724000 0.000107 write(1, "wcomp float IN 5.001 wcomp.3.max"..., 33) = 33 0.000330 write(1, "\n", 1) = 1 0.004085 shmdt(0xb736d000) = 0 0.000140 shmctl(5046292, IPC_64|IPC_STAT, 0xbffa48fc) = 0 0.000068 munlockall() = 0 0.000108 munlockall() = 0 0.000101 nanosleep({0, 100000000}, NULL) = 0 0.100206 nanosleep({0, 100000000}, NULL) = 0 0.100234 exit_group(0) = ? > Summary: to make figures comparable, you need comparable build options. Here both are set to run in place... > That said: what exactly is the tuning effort about? There are various ways to > access pins, and I think pretty much all of them would be orders of magnitude > faster than 'halcmd show pin x' ? The tuning effort is that we are writing a GUI that talks to Linuxcnc over wifi and would like it to be as responsive as possible. Currently we are using a simple web server (http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server). What other way(s) would you suggest for getting/setting pins? Thanks for the help, Michael. -Tom ------------------------------------------------------------------------------ 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
