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 [EMAIL PROTECTED]
B-3001 Leuven Belgium http://www.mech.kuleuven.ac.be/pma
------------------------------------------------------------------------
