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>