Re: Vulcano Test

Period=20000  ->  KernelLatency 4551, UserLatency 5104
Period=50000  ->  KernelLatency 4443, UserLatency 4760
Period=100000 ->  KernelLatency 4522, UserLatency 5042
Period=200000 ->  KernelLatency 20973, UserLatency 23225
Period=1000000 -> KernelLatency 35829, UserLatency 48231
Period=2000000 -> KernelLatency 87183, UserLatency 110500

The results above are OK. They just confirm the following statement of the config helper:
"...  Use a period that is closer to your range of interest. Because of
        cache warming, lower periods will tend to anticipate the scheduling
        when higher ones are used and viceversa. ..."
I find it interesting to see that your machine is much more sensitive to caching issues than mine, despite a  roughly
equivalent hardware, in terms of CPU and lapic freq at least.
In fact what happened to you before was that your calibrated with the default period, 200000, then tested with 
half of it, i.e. 100000. From your data above an anticipation of (23225 - 5042) had to be expected. It is not exactly so, because
the calibrating and latency test are somewhat different, but the order of magnitude is that.

What is important for me is that you are confirming that there is no need of a long calibration, something that matches my experience.
Maybe the figures above could be mended somewhat, by a longer warming up of the cache, but is a fact that  low frequency 
tasks may have a (significantly) higher latency.

So there is little that RTAI can do to substitute a user's judgment. While waiting for further checks I'll decrease the  default calibration period 
the one used for the installed latency examples. 

On the other hand, since the calibration is based on assuring a null average, the negative infimum extremes are somewhat expected.

In any case I think that the added possibility of setting more valuable available values either  in the latencies file or through modules parameters, 
without the need of reconfiguring and remaking, should make things easier. 

Many thanks for your useful help and checks, Paolo.

________________________________________
From: Rtai [[email protected]] on behalf of Felix Frey [[email protected]]
Sent: Thursday, March 31, 2016 4:49 PM
To: [email protected]
Subject: Re: [Rtai] Vulcano Test

Updated CVS and test again.

So far, I get the same results.

When I put your calibration values (1715/2225) in my latencies file then
I get much more reasonable latency values:

RTAI Testsuite - USER latency (all data in nanoseconds)
2016/03/31 15:10:22
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| 1110| 1110| 3643| 7019| 7019| 0
RTD| 2500| 1110| 3671| 5681| 7019| 0
RTD| 1749| 1110| 3664| 6475| 7019| 0
RTD| 1906| 1110| 3657| 6631| 7019| 0


Now I played with the period and time values. The latter one has no
influence, however, the effect of the period value is interesting
and not expected, I think:

Period=20000  ->  KernelLatency 4551, UserLatency 5104
Period=50000  ->  KernelLatency 4443, UserLatency 4760
Period=100000 ->  KernelLatency 4522, UserLatency 5042
Period=200000 ->  KernelLatency 20973, UserLatency 23225
Period=1000000 -> KernelLatency 35829, UserLatency 48231
Period=2000000 -> KernelLatency 87183, UserLatency 110500

Putting the values of the 1st line (4551/5104) into the latencies file
still produces negative latencies:

RTAI Testsuite - USER latency (all data in nanoseconds)
2016/03/31 15:42:22
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| -1468| -1468| 781| 3692| 3692| 0
RTD| -1362| -1468| 769| 2432| 3692| 0
RTD| -1529| -1529| 777| 3602| 3692| 0
RTD| -1398| -1529| 765| 3000| 3692| 0


By the way, when I changed the time value to 5s, the output remains like
this (TIME is wrong):

AFTER USER CALIBRATION (ns): KernelLatency 4568, UserLatency 5060
(CALIBRATION: PERIOD 100000 (ns), TIME 1015577174 (ns)).


attached my rtai_config.h

Felix


Am 31.03.2016 um 15:39 schrieb Paolo Mantegazza:
> That's (calibration) something really strange. Just wondering why on a
> machine like yours I get:
> SYSINFO - # CPUs: 2, TIMER NAME: 'lapic', TIMER IRQ: 2305, TIMER FREQ:
> 8308369,
> CLOCK NAME: 'tsc', CLOCK FREQ: 997204000, CPU FREQ: 997204000, LINUX
> TIMER IRQ:
> 2305.
> RTAI[malloc]: global heap size = 2097152 bytes, <TLSF>.
> , kstacks pool size = 524288 bytes.
> RTAI[sched]: hard timer type/freq = lapic/8308369(Hz); timing: oneshot;
> black/red timed lists.
> RTAI[sched]: Linux timer freq = 1000 (Hz), TimeBase freq = 997204000 hz.
> RTAI[sched]: timer setup = 120 ns, resched latency = 0 ns.
> RTAI[usi]: enabled.
> USERMODE CHECK: OK.
> USERMODE CHECK PROVIDED (ns): KernelLatency -1, UserLatency -1.
> AFTER KERNEL CALIBRATION (WITH RTAI TASK, ns): KernelLatency 1715,
> UserLatency -1 (CALIBRATION: PERIOD 100000 (ns), TIME 1009367042 (ns)).
> USERMODE USER SPACE CALIBRATION: OK.
> AFTER USER CALIBRATION (ns): KernelLatency 1715, UserLatency 2225
> (CALIBRATION:
> vi list    PERIOD 100000 (ns), TIME 1014464466 (ns)).
> FINAL CALIBRATION SUMMARY (ns): KernelLatency 1715, UserLatency 2225.
>
> with
>
> RTAI Testsuite - USER latency (all data in nanoseconds)
> 2016/03/31 15:32:32
> RTH|    lat min|    ovl min|    lat avg|    lat max|    ovl max| overruns
> RTD|        121|        121|        609|       6424| 6424|          0
> RTD|        434|        121|        548|       3984| 6424|          0
> ^CRTD|        434|        121|        548|       3984| 6424|          0
>
>>>> S = 98.696, EXECTIME = 0.0325566
>
> Since I've consistent results on two other machines, up to 3.3 GHz, I'm
> let asking you to help me in seeing what goes wrong.
> In such a view edits "latencies" file, found in subdir calibrate of your
> installation directory, putting my figures above in it and checking what
> you get with the test.
> Then you can play configuring with the period and calibration duration
> to see if they provide a change, and report the outcomes.
> BTW, send me the rtai_config.h that produced those results.
>
> Paolo
>
> On 03/31/2016 03:15 PM, Felix Frey wrote:
>> Just tested vulcano CVS with kernel 4.1.18
>> (on AMD GX-210, x86_64, 2 cores)
>>
>> Running userspace latency test gives:
>>
>> RTAI Testsuite - USER latency (all data in nanoseconds)
>> 2016/03/31 14:02:43
>> RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
>> RTD| -19935| -19935| -18063| -14615| -14615| 0
>> RTD| -19723| -19935| -18050| -15267| -14615| 0
>> RTD| -19514| -19935| -18060| -15083| -14615| 0
>> RTD| -20177| -20177| -18063| -15137| -14615| 0
>> RTD| -19828| -20177| -18060| -15116| -14615| 0
>>
>> These are the kernel messages:
>>
>> [ 1319.188664] RTAI[hal]: mounted. ISOL_CPUS_MASK: 0, LINUX CPU ISOLATED
>> MAP: ffffffff81e61c20).
>> [ 1319.197214] SYSINFO - # CPUs: 2, TIMER NAME: 'lapic', TIMER IRQ:
>> 4353, TIMER FREQ: 6238209, CLOCK NAME: 'tsc', CLOCK FREQ: 998088000, CP
>> U FREQ: 998088000, LINUX TIMER IRQ: 4353.
>> [ 1319.248508] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
>> [ 1319.254814] , kstacks pool size = 524288 bytes.
>> [ 1319.259457] RTAI[sched]: hard timer type/freq = lapic/6238209(Hz);
>> timing: oneshot; linear timed lists.
>> [ 1319.268913] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq =
>> 998088000 hz.
>> [ 1319.276593] RTAI[sched]: timer setup = 160 ns, resched latency = 0 ns.
>> [ 1319.284973] USERMODE CHECK: OK.
>> [ 1319.288155] USERMODE CHECK PROVIDED (ns): KernelLatency -1,
>> UserLatency -1.
>> [ 1320.331572] AFTER KERNEL CALIBRATION (WITH RTAI TASK, ns):
>> KernelLatency 21009, UserLatency -1 (CALIBRATION: PERIOD 200000 (ns),
>> TIME 10
>> 36380956 (ns)).
>> [ 1321.362282] USERMODE USER SPACE CALIBRATION: OK.
>> [ 1321.366937] AFTER USER CALIBRATION (ns): KernelLatency 21009,
>> UserLatency 23941 (CALIBRATION: PERIOD 200000 (ns), TIME 1021744803
>> (ns)).
>> [ 1321.379211] FINAL CALIBRATION SUMMARY (ns): KernelLatency 21009,
>> UserLatency 23941.
>> [ 1334.500839] RTAI[malloc]: unloaded.
>> [ 1334.600674] RTAI[sched]: unloaded (forced hard/soft/hard transitions:
>> traps 0, syscalls 0).
>> [ 1334.623217] I-pipe: head domain RTAI unregistered.
>> [ 1334.628084] RTAI[hal]: unmounted.
>>
>>
>> The latency values are probably not what they are expected to.
>> In my opinion the calibration delivers much too high values
>> (21009/23941).
>> Any ideas??
>>
>> Felix
>>
>> _______________________________________________
>> Rtai mailing list
>> [email protected]
>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
> _______________________________________________
> Rtai mailing list
> [email protected]
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai