On Sat, 2004-10-16 at 14:13, Panagiotis Issaris wrote: > Hi, > > 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, > Takis -- Philippe.
