Dmitry Adamushko schrieb:
> Hi there,
> after a preliminary discussion with Philipe and, well, a few days later
> than I expected, I'm starting a new effort of writting some simple (i.e.
> too complex :) yet, hopefully, useful benchmarking utilites.
> The idea of each utility is to emulate a certain use case but
> at the level which is significant enough to prove that
> the system is (or is not) working properly latency-wise.
> This, hopefully, will help to determine some bottlenecks and
> the parts of code that need to be reworked/tweaked.
> Then we may use such tests on release-by-release basis as indicators
> of either progress or regress we are making with a certain release.
Actually, I'm doing here some measurementstuffs to compare the Realtime
Performance of Xenomai and Preempt-RT stuffs. :-)
> As an example, the first utility would implement the following use case :
> (based on the latency program)
> - a given number of periodic threads are running;
> - configurable periods (so that e.g. a few threads can become active
> at the same moment of time). Actually, that's what we would need.
> - timer : periodic or apperiodic;
I've already implemented something in this way in POSIX. I took the
accuracy.c out of the posix demo from Gille and changed it. So that you
can start few threads with different nsleep duration. Except that it
writes a log, which can be plotted. The util does quite the same stuffs
like the cyclictest by Thomas Gleixner.
Further I implemented a tool for Interruptmeasurement with rtdm. Still
tuning on it, because the Pre-RT Kernel get ocassionally problems with
I even implemented Rhealstone Benchmark with xenomai-complaint Posix, it
however provides only middlevalues and might not be very interesting.
> the utility will not likely produce any screen-output during its work, but
> rather the comprehensive statistic in a handy form after finishing.
Exactly what I thought :-)
> other utils could make use of some scenarious where synch. primitives/
> rt_queue's/pipes could be highly used etc.
Generally I'm quite interested on some xenomai specific latency
behaviour caused by i.E. Domain Switching, Function Wrapping and so on.
I'm still considering on some concrete Workload-scenarious.
> I guess, Xenomai already provides a valid amount of functionality and it's
> quite stable for the time being. So it's time to work on optimizing it!
> Everyone is wellcome to come up with any scenarios on which such utilities
> could be based.
> Any comments on the one with a given number of threads are wellcome too.
I'm now busy writing my stuffs together. no time to debug my hacks. so I
think I'd release them somehow later some time after I've given them
first to Jan for quice code review.
> Best regards,
> Dmitry Adamushko
> Xenomai-core mailing list
Xenomai-core mailing list