[Rtai] Some benchmarking...

[Bernhard Pfund]

Paolo Mantegazza wrote:
> 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.
> 
OK, thanks! Good to hear that :)

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

I agree on the video card issue. In that case the card is onboard, so I
got video 'for free'. Besides I made some good experiences with the
nVidia Quatro card in my core 2 duo laptop.

What bugs me a bit is the fact that the SATA/PATA drivers seem to rely
on ACPI to shutdown the disks properly. So, even if I was lucky with the
ACPI stuff for now, this could lead to problems in the future?!?

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

When I run the user/preempt test in showroom I get this output (idle
system):

* latency: min: -639042, max: -639039, average: 907; fastjit: 0,
slowjit: 0 * (all us) *

How can this be interpreted? Looks a bit strange ;)

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

OK, I'll try that...

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

No, the pings were floods but, I can try that too. Make would be a good
'stress factor' indeed! The problem is that the target machine is a
minimal linux installation, so I have to install gcc amd make first.


Thanx a lot and I'll be back with more findings...

Bernhard