RTAI LiveCD + DB

Panagiotis Issaris panagiotis.issaris at mech.kuleuven.ac.be
Sun Oct 17 04:30:19 CEST 2004


Hi,

Philippe Gerum wrote:

> 
>Well, as an illustration, just to have me freak out during the initial
>performance work on fusion, Gilles once started to stress our test box
>with the following stuff on a 100m/b lan, after having enabled the
>"echo" service (udp) on it:
>socket <my-box-ipaddr> echo < /dev/urandom > /dev/null
>
>Unfortunately, the network flooding won't be noticeable if sent to the
>loopback address. We need external IRQs there.
>
>Well, there is still the option to ask LiveCD users to connect pins 9-10
>of the parallel port on their box using a paper clip, but, well... ok.
>Never mind...
>  
>
:-)
Just out of curiosity -and because I know virtually nothing about
the parallelport- does that actually work?

>  
>
>>* If hackbench is of any use for evaluating RTAI's performance
>>   under stress, deciding which parameter to use is not that simple.
>>   If the parameter is to big, the machine get loads of 600 and more
>>   and is unresponsive _for a long time_. If it is too small, it is 
>>worthless
>>   to add it.
>>    
>>
>
>hackbench alone fails to stress co-schedulers to their limits; I'd
>suggest to keep a reasonable value for starting it, i.e. some value
>which does not shatter the Linux kernel, because LXRT/fusion would not
>be that affected anyway (e.g. a test started here on a lame box with
>miserable laptop hw does not raise the max above 42us at 10Khz, whilst
>loops of 1Gb file dd strikes a nifty 65us). However, it's a good
>"companion" load to be coupled with network traffic for instance.
>  
>
OK, that's what I supposed. And I kept it running together
with the dd.

>>* When find is run for the first time, it intensively accesses the HD. But,
>>   on the second run, all seems to be cached, and I assume that therefore
>>   the find does not contribute to stresstesting RTAI?
>>    
>>
>
>No it doesn't anymore. I'd replace this with a plain dd, syncing between
>runs for now. Of course stressing with dd is not representative of a
>"normal" load, especially for embedded configs, but the idea is to get
>worst-case figures I guess, and bandwidth saturation is good usually
>good at this.
>  
>
A rather stupid problem I'm having with dd is, that I copied from
the CD as a source, which gives me read errors, because
the CD-image is only 17MB big :-)
Not a real problem though, as I'll just switch it back to HD.

>>* For the latency tests, I only upload the maximum latency. Is it usefull
>>  to also add the average and possibly the minimal latency? The data from
>>  the other tests (preempt and switch) are not being uploaded to the
>>  database. Any suggestions on what data is most useful for those tests?
>>
>>    
>>
>
>I'd say that all three are useful. Min tells us about calibration
>accuracy, distance between avg and max tells us about RTAI's sensitivity
>to system perturbations (e.g. memory bandwidth problem), and max, well,
>max tells us if we are basically toast or safe using this hw, or if some
>config switch still needs to be tweaked somewhere.
>  
>
I've added both avg and min to the LiveCD and database (which
already contained max).

Initially I was thinking about adding the kernel configuration and the
RTAI configuration, but instead I added a version number. This
can be associated with the used config for the kernel and RTAI.

With friendly regards,
Takis

-- 
------------------------------------------------------------------------
Panagiotis Issaris
Katholieke Universiteit Leuven
Division Production Engineering,
Machine Design and Automation
Celestijnenlaan 300B              panagiotis.issaris at mech.kuleuven.ac.be
B-3001 Leuven Belgium                 http://www.mech.kuleuven.ac.be/pma
------------------------------------------------------------------------





More information about the Rtai mailing list