Re: [Xenomai-core] Benchmarks
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@gna.org > https://mail.gna.org/listinfo/xenomai-core Cheers Luotao Fu
Re: [Xenomai-core] Benchmarks
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@gna.org > https://mail.gna.org/listinfo/xenomai-core Cheers Luotao Fu ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix to RTDM open problems
Jan Kiszka schrieb: .. > Yep, correct. Don't know, I must have smoked something while trying to > fix this bug some weeks ago. ... Ah, now I know why it always smells a little funny in your office, must be good stuff. :-) SCNR. Cheers Fu
Re: [Xenomai-core] [PATCH] Fix to RTDM open problems
Jan Kiszka schrieb: .. > Yep, correct. Don't know, I must have smoked something while trying to > fix this bug some weeks ago. ... Ah, now I know why it always smells a little funny in your office, must be good stuff. :-) SCNR. Cheers Fu ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch
Hi, As I've noticed, the tracer ist still not compeletly in the SVN trunk. Thus it causes some problems (missing header files) while compiling the timer Benchmark module. Here is a small patch, which fix this problem. Cheers Luotao Fu diff -uNr xenomai/ksrc/drivers/benchmark/timerbench.c xenomai-wd/ksrc/drivers/benchmark/timerbench.c --- xenomai/ksrc/drivers/benchmark/timerbench.c 2006-01-04 16:22:05.0 +0100 +++ xenomai-wd/ksrc/drivers/benchmark/timerbench.c 2006-01-04 17:23:00.0 +0100 @@ -18,7 +18,9 @@ #include #include -#include +#ifdef CONFIG_IPIPE_TRACE + #include +#endif /* CONFIG_IPIPE_TRACE */ #include #include
Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch
Hi, As I've noticed, the tracer ist still not compeletly in the SVN trunk. Thus it causes some problems (missing header files) while compiling the timer Benchmark module. Here is a small patch, which fix this problem. Cheers Luotao Fu diff -uNr xenomai/ksrc/drivers/benchmark/timerbench.c xenomai-wd/ksrc/drivers/benchmark/timerbench.c --- xenomai/ksrc/drivers/benchmark/timerbench.c 2006-01-04 16:22:05.0 +0100 +++ xenomai-wd/ksrc/drivers/benchmark/timerbench.c 2006-01-04 17:23:00.0 +0100 @@ -18,7 +18,9 @@ #include #include -#include +#ifdef CONFIG_IPIPE_TRACE + #include +#endif /* CONFIG_IPIPE_TRACE */ #include #include ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Linking failure while compiling POSIX skin as built-in module
Hi folks, I detected a minor problem while compiling 2.6.14.2 with the most recent xenomai code from svn. The Compilation would quit at linking if one tries to build the posix skin as built-in module. Abort message: ipc/built-in.o: In function `sem_init': : multiple definition of `sem_init' kernel/built-in.o:: first defined here ld: Warning: size of symbol `sem_init' changed from 296 in kernel/built-in.o to 55 in ipc/built-in.o The problem is the sem_init() method of the SysV IPC routine in the linux kernel, which is unluckily called excactly the same as the posix sem_init() but differently declared. It's declared as void __init sem_init (void) in SysV IPC and int sem_init(sem_t *sem, int pshared, unsigned value); in POSIX. Thus the linker get confused trying to link the two symbols in one kernel image. Workaround coulb be deactivating the SysV IPC routine in the kernel or compile Posix skin as a loadable module. Cheers Luotao Fu
[Xenomai-core] Linking failure while compiling POSIX skin as built-in module
Hi folks, I detected a minor problem while compiling 2.6.14.2 with the most recent xenomai code from svn. The Compilation would quit at linking if one tries to build the posix skin as built-in module. Abort message: ipc/built-in.o: In function `sem_init': : multiple definition of `sem_init' kernel/built-in.o:: first defined here ld: Warning: size of symbol `sem_init' changed from 296 in kernel/built-in.o to 55 in ipc/built-in.o The problem is the sem_init() method of the SysV IPC routine in the linux kernel, which is unluckily called excactly the same as the posix sem_init() but differently declared. It's declared as void __init sem_init (void) in SysV IPC and int sem_init(sem_t *sem, int pshared, unsigned value); in POSIX. Thus the linker get confused trying to link the two symbols in one kernel image. Workaround coulb be deactivating the SysV IPC routine in the kernel or compile Posix skin as a loadable module. Cheers Luotao Fu ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
