RTAI LiveCD + DB update
rpm at xenomai.org
Sat Oct 16 16:11:16 CEST 2004
On Sat, 2004-10-16 at 14:13, Panagiotis Issaris wrote:
> I just added transaction support to the webapp. It didn't
> have it up until about 5 minutes ago, and while it wasn't
> a problem with the current amount of parallel submissions ;-)
> I had to add it ASAP.
> Philippe Gerum wrote:
> >>* Furthermore I wanted to get an idea of the load while running
> >>the testsuite and for the moment I took the Linux load (/proc/loadavg)
> >>and stored it the database.
> >Unfortunately, LXRT kills these figures since daemons are sleeping in
> >TASK_UNINTERRUPTIBLE mode, so the load average skyrockets despite the
> >system is idle.
> But is their no difference whatsoever? I mean when I ran
> the hackbench application the load went up over 600. I can't
> recall seeing this amount of load with LXRT.
> In other words, can the loadaverage still be usefull, if you
> calculate in the fact that it is incorrect because of RTAI, but
> you should still see a "significant" differencce between plain
> LXRT load and LXRT load + hackbench load f.e.?
The problem might be that spurious LXRT load induced by such sleeping
state might keep increasing over time, at least to the point where they
become significant wrt hackbench figures. In fact, any LXRT task running
in hard mode also sleeps in TASK_UNINTERRUPTIBLE mode after it has been
stolen away from the Linux scheduler; this impacts the Linux loadavg the
same way, but in this case, this could be construed as a real load since
the RT side actually runs here. So we have two opposite situations
charged for the same result.
I did not specifically investigate the matter, but I suspect that such
results would carry too much uncertainty for proper interpretation.
> Or should I better remove that data from the DB? Or can
> I use some other metric for calculating load (which is valid
> when running RTAI/LXRT)?
Using the execution time figures available from /proc/rtai/ scheduler
might be a better information than Linux's loadavg for LXRT, even if
they don't refer to the same kind of load.
> What data should best be added from the other tests (preempt,switch)?
Interesting data that immediately come to my mind are:
o interrupt propagation time in the Adeos layer (Adeos needs to provide
the info here -- I'm going to add that in the next release);
o for x86, average programming time of the 8254, especially under
saturated bus conditions (e.g. dd if=/dev/zero of=<hdd-file> count=X
bs=1M); this directly impacts the quality of the scheduling latency
calibration in one-shot mode;
> I hope to update the database + LiveCD as soon as possible so people
> who run the CD will fill in all fields of the DB.
> With friendly regards,
More information about the Rtai