All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-core] Benchmarks
@ 2006-02-09 14:21 Dmitry Adamushko
  2006-02-09 14:50 ` Luotao Fu
  0 siblings, 1 reply; 2+ messages in thread
From: Dmitry Adamushko @ 2006-02-09 14:21 UTC (permalink / raw)
  To: xenomai

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

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. not

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.

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;

...

the utility will not likely produce any screen-output during its work, but
rather the comprehensive statistic in a handy form after finishing.

---

other utils could make use of some scenarious where synch. primitives/
rt_queue's/pipes could be highly used etc.


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.


--
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 1851 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Xenomai-core] Benchmarks
  2006-02-09 14:21 [Xenomai-core] Benchmarks Dmitry Adamushko
@ 2006-02-09 14:50 ` Luotao Fu
  0 siblings, 0 replies; 2+ messages in thread
From: Luotao Fu @ 2006-02-09 14:50 UTC (permalink / raw)
  To: Dmitry Adamushko; +Cc: xenomai

Hi folks,

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.
> not
> 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
stability.

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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Cheers
Luotao Fu


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-02-09 14:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-09 14:21 [Xenomai-core] Benchmarks Dmitry Adamushko
2006-02-09 14:50 ` Luotao Fu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.