The automated chart seems exactly the thing for me (I have some testing
tools development experience).
I'll look into it and will soon send a initial design.
Of course any pinters/advice/suggestions will be highly appreciated.
Philippe Gerum wrote:
> On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote:
>> I imagined thats the policy.
>> But is it worth investing time in? or is there higher priority task I
>> can be assigned to?
> I don't think RTP is high priority for now.
> Two other tasks would have a much more significant impact, both for
> Xenomai users and developers.
> 1) Make Valgrind usable with Xenomai apps; of course without any
> real-time guarantee anymore, but this would nevertheless plug a serious
> hole in the development toolset available to users.
> 2) We do, certainly, definitely, desperately miss an automated way to
> get performance charts for a few selected Xenomai tests, which would
> allows us to conduct comparative analysis between versions, and find out
> what's right or wrong with our changes.
> For instance, we are currently maintaining seven architecture ports;
> each time something changes in some part of Xenomai's generic code, we
> have no freaking idea whether all archs benefit from such change, or if
> at least no arch gets penalized by it. And the very same goes for the
> interrupt pipeline, for which any hazardous change may generate adverse
> effects on an even much larger scale. Let me put this bluntly: this
> won't fly much longer; we are losing precious time getting rid of any
> regression way after it has actually happened into the code, because we
> cannot easily and routinely COMPARE how different versions behave. Aside
> of this, we don't have any factual data regarding how Xenomai evolved
> over time in terms of latency, code footprints and so on.
> What we need is a simple automated way to a given test on any given
> Xenomai version (actually a SVN commit number would be much better)
> extracted from our repository, draw a few charts summing up the results,
> and move those results to our website periodically or even as soon as
> they are available. _This_ would help users to understand the current
> trend and why we did some changes (or why we should not have done them),
> and allow developers to pull the brake each time a serious regression is
> visible from those charts.
> Simple and easy:
> TEST/x86: interrupt latency to kernel handler [latency -t2]
> (latency in us)
> | x (XX us) <= Houston, we have a
> | x (ZZ us)
> | x (YY us)
> commit#72 ... commit#2004 commit#<any>
> (v2.0) (v2.3)
> Another test could analyse the task dispatch latency, another one the
> code footprints in kernel space, and so on. Once this framework is
> available, we would find the various hardware to run the tests on and
> get the results from, that is not an issue anymore.
> Besides, tackling this issue is quite a good way to have his feet wet
> almost immediately with the Xenomai framework as a power user, and also
> to get immediate reward for such work, since we would push its results
> online routinely.
> Please, somebody implement this, damnit! Or I'm going to rewrite the
> entire Xenomai stack in Bourne shell with Java applets for speedups, so
> you could not complain about bad latencies and unwanted overhead
> Thank you,
>> Philippe Gerum wrote:
>>> On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote:
>>>> Hello again,
>>>> As of VxWorks 6.x vxworks implement RTP which is an implementation of
>>>> user space processes with real time capabilities, which of course
>>>> include an extended API, which from my testings I discovered that we do
>>>> not support yet.
>>>> Currently extending the VxWorks API is not in Xenomai task list, does it
>>>> have any demand?
>>>> If I'll take it as a my task, do we have any legal issues with using
>>>> Wind River's headers?
>>> This matter is muddy; fair use, interoperability, and copyrights of
>>> header files and/or their contents is a legal mess.
>>> Our policy is simple: paste-copy of any portion of any proprietary
>>> licensed header is unwanted and will be systematically rejected. You
>>> need to implement your own header, defining what you need for satisfying
>>> all the references within the emulator your are writing from scratch.
>>> You should also explicitly mention in the copyright notice that the
>>> resulting software is an emulator. We claim to mimick the original
>>> software as correctly as possible, according to the API specs which have
>>> been made publically available by the copyright holder of the original
>>> work, with all the limitations inherent to such exercise. In any case,
>>> we don't claim to produce a copy of the original software we only
>>> emulate. In short, Xenomai is a Chameleon, not a clone.
>>>> If any of my assumptions is false or if you have any comment/answers
>>>> please reply.
Ravid Baruch Naali
+972 4 6732729
+972 52 5830021
Xenomai-core mailing list