On Sat, 2004-10-16 at 16:19, Panagiotis Issaris wrote: > Hi, > > Philippe Gerum wrote: > > >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. > > > > > Thanks for the explanation! > Then I shall remove them from the LiveCD and DB. > > >>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. > > > > > I will add those. > > >>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); > > > > > I'll add them as soon as they are available. > > >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; > > > > > Does dd if=/dev/hdc of=/dev/null count=X bs=1M give a > similar effect with respect to bus saturation? >
Yes. Compared to hackbench, such kind of load is much more stressful to co-schedulers like LXRT/fusion. hackbench is better to stress RT when performed using the genuine Linux scheduling infrastructure; co-schedulers escape a significant portion of the induced load here. OTOH, trivial "dd" to/from hdd is likely best enemy to both of them, even if it still impacts co-schedulers less, due to a lesser sensitivity to VM paging storms and fs journalling artefacts. > With friendly regards, > Takis -- Philippe.
