On Tue, 2009-06-23 at 11:30 +0200, Philippe Gerum wrote: > On Mon, 2009-06-22 at 09:23 -0400, Andreas Glatz wrote: > > Hi, > > > > > > > What bothers me is that you seem to determine a latency based on > > > measurements of a round trip time, obtained on an ethernet network. So > > > it is a bit difficult for me to give any interpretation about the 70 us > > > figure; too many variables in that equation. > > > > > > > > > > > > > I finally upgraded Xenomai from version 2.4.4 to 2.4.8 > > as you strongly suggested last time and I can say > > that this fixes all of the bugs we found in the earlier > > version. Thanks a lot for that!! > > > > Furthermore I did some serious measurements with the new > > Xenomai version on an MPC8360. In short, I measured > > an interrupt latency around 7us when running in kernel-space > > and around 35us when running in user-space. You can find > > the details of those measurements the end of this Email! > > > > I have two more questions: > > > > 1) In the legacy code I am porting, critical sections are > > protected by disabling/enabling ALL interrupts (like > > sti/cli in kernel-space). This method is much faster than > > locking a mutex, which might put a task to sleep. > > Usually yes, but at the expense of wrecking the priority-based model of > the RTOS when misused. > > > Are there > > similar, portable functions available under Xenomai or IPIPE? > > You should never rely directly on I-pipe features, using a Xenomai > interface is the way to go.
I may have misunderstood your question actually: were you asking for a way to block interrupts for user-space? If so, then forget about it. There is no way to do this sanely, and safely. You should use mutexes; 2.5 even supports fastsynchs underneath, which could be roughly compared as Xenomai's counterparts of Linux futexes. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
