[ag-automation] some stresstest results with Xenomai and Preempt-RT

[Luotao Fu]

Hi Jan,

On Wed, Apr 19, 2006 at 06:50:12PM +0200, Jan Kiszka wrote:
> Hi Fu,
> 
> Luotao Fu wrote:
.........
> > Testcandidate:
> > A: Preempt-RT 2.6.16-rt16
> > B: Xenomai (svn Rev. #949)
> 
> Just for the records: ipipe-1.2-04?
> 

Jepp, still get some issues here with the Kernel though. (as mentioned 
in xenomai mailinglist) I'm still searching for the reason of the problem.

> > 
> 
> I banged my head against several walls yesterday and today before I
> found a problematic property of cyclictest and also a bug of my own:
> 

Yeah, one more head banging heavy metal fan!! ;-)

>  o The threads are starting in an unsynchronised fashion, which is ok
>    for comparison as long as the start offsets are comparable as well.
>    They weren't in the original implementation. I therefore pinned all
>    threads to the same start time in latest Xenomai trunk. [I'm now
>    considering to add adjustable start offsets as parameter.]
> 
>  o I placed an ioctl into the measurement path of the highest prio
>    thread in order to freeze backtraces on the highest latencies.
>    Unfortunately, this call disturbed the measurement even without any
>    tracing support installed. Bug fixed in trunk.
> 
> To sum up: when time permits, please recheck both systems with
> cyclictest from revision #955. I don't expect major differences on your
> test machine (too much MHz...), but I faced significant effects on
> Pentium 266 and 133 MHz boxes. What will change is the worst-case
> latency "ladder"; it will become priority-sorted.
> 

Thanx for the advice, will redo the test asap. 

> 
> BTW, the effects that happened to be observable with the unsynchronised
> threads demonstrate how carefully one has to design a complex system:
> Timer events were arranged in a cascading order, causing a IRQ storm
> once in a while which influenced the system latency on low-end
> significantly. The point is that the number of timer events one has to
> consider for the system design varies between both approaches due to the
> fact that Preempt-rt provides high resolution timing for everyone (RT
> and non-RT) automatically.
> 
> > Results:
> > * irLat:
> >   |  Min(usec)  |  Max(usec)  
> > A |  3.1985     |  105.33 
> > B |  3.2130     |  92.52
> > **********************************
> 
> Just for clarification:
> 
> event -> irq handler -> user space task -> reply
> or
> event -> irq handler -> reply?
> 

Just Kernel-space testmode. We are experencing some issues with
rtmutexes in the userspace testmode under high frequent tasks. Till we
locate the reason for this we'll only do tests in kernelspace mode.

> On Preempt-rt: handler is SA_NODELAY, i.e. non-threaded, right?
> 

excatly.
the flags set are  SA_NODELAY | SA_INTERRUPT

> > 
> 
> Minor note on Xenomai: CONFIG_XENO_OPT_TIMING_PERIODIC is not required
> when running highres timing (one-shot mode). But it will save you only a
> few nanoseconds and bytes on mid-range platforms.
> 

applied for further tests, thanx.

> > 
> 
> Jan
> 
> ag-automation at lists.osadl.org
> https://lists.osadl.org/cgi-bin/mailman/listinfo/ag-automation

cheers
Fu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.osadl.org/pipermail/ag-automation/attachments/20060420/447b6439/attachment.pgp