[Rtai] Some benchmarking...

Paolo Mantegazza mantegazza at aero.polimi.it
Fri May 23 18:46:23 CEST 2008


Bernhard Pfund wrote:
> All,
> 
> I'm currently testing my already mentioned quadcore setup with the test
> suite.
> 
> These are the results of the user/preempt test after running 80min under
> _heavy_ load (see below). Top showed a load average of 32:
> 
> RTH|     lat min|     lat avg|     lat max|    jit fast|    jit slow
> RTD|        -615|        -358|        7332|        9220|        8050
> 

If here we have single (microsec) digit latency without CPU reservation 
under heavy load then it is the first time I can see it. I must honestly 
say that it is only partly a merit of RTAI but it seems you have chosen 
a good piece of hardware mostly.

> Somewhat interesting is the fact, that these results were achieved with
> ACPI enabled and using the nVidia AGP framebuffer driver.

ACPI has given mixed feeling to me. For instance on some old PIII it 
made no difference while on some recent machines it created latencies. 
Being blind about it I prefer to set it off. No idea about NVidia as I 
try to get rid of advanced video cards when wanting real time. So, once 
more, it seems, you buyed soemthing good.

> 
> 
> For reference, these are the system idle values:
> 
> RTH|     lat min|     lat avg|     lat max|    jit fast|    jit slow
> RTD|        -607|        -489|        3201|        3531|        3247
> 

Good hardware, once more.

> 
> Does this make sense or is it way off? It's clear that the viability
> depends on the requirements of the particular application but, still it
> would be good to get a rough thumbs up or down... ;)
> 

To me it make sense. Can you check with CPU reservation? It might 
require to use the same test in showroom, to correct cpu affinity in 
rt_task_init_schmod more easily. Moreover it will help me in knowing if 
Linux really reserves any CPU combination. Somebody reported that it 
does not so on more than 2 cpus.

> I already did some calibration with the interactive suite from showroom
> but as I'm running 2.6.24.7 some of the calib steps refuse to work
> (assuming that the > 2.6.22 limitation still exists). Is there a way to
> circumvent the problems with these tests and tickle the results out of
> the system?

With > 2.6.21 it is no more easy to divert hardware timers, without 
annoying Linus, the way it worked before. I must admit that that I've 
found little time to think of it. On you monster machine you can quickly 
play with the APIC latency anticipation in RTAI config and see what 
happens. For instance set it to 1000, do not go below, something likely 
more appropriate for you 4c. It should put the mins/avrgs on the 
positive side.
One thing that should be up to me instead is to exploit the exploit the 
APIC frequency afforded by the latest patches. That will help giving a 
bit more timing precision, not one changing the "state of affairs" though.

Were the ping with "-f"? Another good stress could come from going into 
kernel dir and: while "true"; do make -j4; make clean; done

Paolo.

> 
> Any feedback appreciated!
> 
> Cheers::Bernhard
> 
> 
> Stress setup:
> -----------------------
> dd'ing a 1GB file
> while true; do dd if=TestFileBig of=TestFileBigBig bs=512; done
> 
> cat /dev/zero > /dev/null &
> cat /dev/zero > /dev/null &
> cat /dev/zero > /dev/null &
> cat /dev/zero > /dev/null &
> 
> while true; do ls -IR / > list; done &
> 
> ping another host from the RTAI machine
> ping the RTAI machine from a third machine
> _______________________________________________
> Rtai mailing list
> Rtai at rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> 




More information about the Rtai mailing list