RTAI LiveCD + DB
rpm at xenomai.org
Sun Oct 17 00:57:16 CEST 2004
On Sat, 2004-10-16 at 12:49, Panagiotis Issaris wrote:
> It still has a few problems though:
> 1. The actual method of running the test. The tests are now
> being executed (somewhat simplified) as follows:
> find / &
> hackbench 5 &
> timestamp 1 (for calculating runtime)
> timestamp 2 (for calculating runtime)
> Several questions/problems here:
> * Are the shown applications good for generating an artificial load?
> I normally use pingflooding as well. Should I add it to the test? Any
> other apps I could add to the test?
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.
> * 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.
> * 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.
> * 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.
> The last point requires modification of the database, so I'd like to fix
> one as soon as possible.
> With friendly regards,
More information about the Rtai