RTAI LiveCD + DB update

Philippe Gerum rpm at xenomai.org
Sat Oct 16 16:44:39 CEST 2004


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.





More information about the Rtai mailing list