---------- Forwarded message ---------- From: Gregory CLEMENT <[EMAIL PROTECTED]> Date: 9 oct. 2007 21:07 Subject: Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK To: Jan Kiszka <[EMAIL PROTECTED]>
2007/10/9, Jan Kiszka <[EMAIL PROTECTED]>: > Gregory CLEMENT wrote: > > Here, they are the last latency we get on AT91SAM9261-EK. As just now > > I haven't the board at home, I send the last result we stored. The > > prority of dbgu should be set to 6 instead of 7, but I can't assure > > it, for Xenomai. > > Hmm, hardware interrupt priorities must not impact the worst-case > latency if I-pipe acks and mask them appropriately (the worst case is > when multiple interrupts happen in a row, not at the same time). But > this statement is not based on knowledge about potential pitfalls of > this arch. Are there specialities that require this tweaking? Indeed there was little impact on Xenomai, but a big impact in RTAI. I believe that in RTAI (or at least in our RTAI port), there is longer critical section than in Xenomai. We observe big latency when calibrator was writing a lot of "\r" on serial line, that was causing a lot of interrupts. I think that during a critical section (IT disabled), we get an timer interrupt and a serial interrupt. As serial interrupt has bigger priority it is treated first and as during an interrupt serial driver can send or receive 256 character, it can add a big delay. > > > first Xenomai: > > > > #insmod > > /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko > > #cd /usr/xenomai/bin/ > > Which versions were you using for both tests? Do you still have the > involved .configs? Both version are 2.6.20.13 I join the config files. > > > #./latency -t 2 -p 150 -h -H 500 > ... > > ---|------------|------------|------------|--------|------------------------- > > RTS| 3.480| 11.779| 99.163| 0| 14:23:01/14:23:01 > > > > It was run under calibrator load during more than 14 hours. > > > > Now RTAI: > > > > Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500 > > duration : 17h > > > > 1970/01/1 22:34:51 > > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns > > RTD| 3221| 2577| 4997| 26095| 53801| 0 > > RTD| 3221| 2577| 5163| 25451| 53801| 0 > > RTD| 3221| 2577| 5159| 25128| 53801| 0 > > RTD| 3221| 2577| 4799| 23518| 53801| 0 > > RTD| 3221| 2577| 4828| 25128| 53801| 0 > > RTD| 3221| 2577| 5089| 23518| 53801| 0 > > RTD| 3221| 2577| 4580| 23840| 53801| 0 > > RTD| 3221| 2577| 4924| 25128| 53801| 0 > > RTD| 3221| 2577| 4740| 24806| 53801| 0 > > RTD| 3221| 2577| 4251| 25128| 53801| 0 > > Again, what would simplify the discussion enormously is a function > back-trace of the measured maximum latencies, just like "latency -f" > generates. The numbers will become worse, for sure, but we would gain a > very good overview about what is executed and what delayed which kernel. > If you see a chance to perform such a test and you need some hints on > the tracer setup (or did you use it before?), please let us know! OK for try it, at least for Xenomai as the function exists, but I can't do it tonight and not this week in fact. > Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux > -- Gregory CLEMENT Adeneo Adetel Group 2, chemin du Ruisseau 69134 ECULLY - FRANCE France Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41 www.adetelgroup.com -- Gregory CLEMENT Adeneo Adetel Group 2, chemin du Ruisseau 69134 ECULLY - FRANCE France Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41 www.adetelgroup.com
config-RTAI
Description: Binary data
config-Xenomai
Description: Binary data
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
