On Thu, Jul 22, 2004 at 05:41:00PM +0200, Philippe Gerum wrote: > > # while true; do echo `seq 1 46`; done > > # virtual destop switching in X > > nanosleep jitter: min = 9537 ns, max = 123902 ns, avg = 30370 ns > > sema4 handshake: min = 3855 ns, max = 43500 ns, avg = 12672 ns
> Never put X in the loop; results cannot be reliable with it and it makes > no sense to interpret them since the user-space X driver can do whatever > it wants to with your hadware, especially when switching back and forth > vt7. So I cannot comment these figures. I was not switching from X to linux text mode, but switching through the virtual desktops provided by my desktopmanager (fluxbox). But I will measure again without running X :) On another system (PI 266 MMX, embedded, no X, frambuffer (is this okay?)), the nanosleep jitter running lxrt under full load (echo and ping -f) was about as high as xenomai with my skin in idle modus. > > Philippe, can you explain why we have such a high nanosleep jitter? Of > > course there is a certain overhead if we schedule userspace threads, but > > the kernel-only example shows jitter of the same magnitude. > Because vesuvio (and kilauea) implementation uses a threaded interrupt > model and internal mutexes that proved to be nice on the paper but > inefficient performance-wise; this is why I killed them from the fusion > branch. In order to have the latest performance figures for Xenomai, you > should do your tests on fusion, since recent optimizations to the > scheduler, interrupt model and aperiodic timer went there, and cannot be > backported without heavily changing the Xenomai support in vesuvio, > which I won't do. okay - then I'll port my skin to fusion :) thanks - Marc -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh
