On Tue, 2007-01-02 at 16:28 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > ...
> > Not that I would be particularly fond of that, mm, thing, but this would
> > allow to fix the bogus x86+8254 setup relic, which is likely the only
> > one which would cause any significant delay among the supported
> > archs/platforms.
> BTW, could we define some concrete metrics to asses all the ongoing
> changes performance-wise? We have the timerbench, we have cyclictest
> (for large number of timers and for POSIX tests), we have the enhanced
> runtime statistics for threads and IRQs, now we just need to create
> meaningful test scenarios and run them / let them run on the different
> Interesting is, e.g., how the timer subsystem scales worst case-wise and
> what piece of the cake remains for Linux under high timer load.
> Moreover, there is still that tsc2ns conversion improvement to work out
> - and then to evaluate...
To add a piece to the puzzle, I would very much like that such metrics
would be applicable - at least some of them - to the older Xeno releases
too. A work I have in mind for some time now would be to get a chart of
the overall Xenomai performances over time (e.g. basic latency tests to
start with), release after release; something we could automate and
publish on the website. A very useful regression test, and a nice
marketing tool (well, provided we don't screw things up too often...).
Xenomai-core mailing list