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


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 
>>   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,

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