Fwd: RTEMS pthreads performance (was RTEMS vs other realtimeOperating Systems ..)

[Till Straumann]

Joel Sherrill wrote:
> 
> Till Straumann wrote:
> 
>>Joel Sherrill wrote:
>>
>>
>>>Till Straumann wrote:
>>>
>>>
>>>
>>>>Kamen Penev wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi!
>>>>>
>>>>>Looking at your work comparing RTEMS, RTLinux and vxWorks, I am wondering
>>>>>about the unusually poor RTEMS+pthreads result for context switching on a
>>>>>loaded system. Has this been explained (better yet fixed)by the RTEMS
>>>>>development team?
>>>>>
>>>>>
>>>>
>>>Which RTEMS version/target CPU/configuration?
>>>
>>
>>I believe it was ss-20011025 (I can re-run the test later today on a
>>later version).
> 
> 
> That is pretty old and I am 100% positive it predates the work
> I did to improve results on your benchmark.  The ChangeLog entry
> for that is 2002-07-01.
> 
> 
>>The target was a 604 series PowerPC on a Motorola MVME23xx board.
> 
> 
> Do you know what the test is doing? 

Sure - that's described in my paper. It uses a hardware timer to 
generate periodical interrupts. The ISR releases a posix semaphore
on which a pthread blocks.
The interrupt latency (timer rolling through zero until user ISR is
executed) and the thread dispatching latency (ISR releases sema
until the [high priority] thread obtains it and is scheduled)
are recorded.

I compared combinations of using posix semaphores vs. native RTEMS
semaphores or RTEMS events and pthreads vs. RTEMS native threads.

The results were comparable except for the [worst case] thread 
dispatching latency which was much worse when using pthreads than when 
using native threads. (I remember a phone conversation with you and you 
suspecting that it could be caused by the posix signal delivery code [no 
signals were used in the test, though]).

NOTE: I run this test for a while under heavy load (networking, console 
traffic etc.). The average numbers are usually pretty good. It's the
worst case (i.e. the longest latency recorded during the test) who
is critical.

But as I said: I'll try to run the test on ss-20021007 ASAP.

-- Till

> Is it the same as yours?  Saying
> something is slow doesn't help me much.  RTEMS usually performs
> comparable to VxWorks on benchmarks.  But each time we hit a new
> benchmark comparison, there is new data to optimize against.  
> 
> 
>>-- Till
>>
>>
>>>
>>>
>>>>>Thanks.
>>>>>
>>>>>Kamen Penev
>>>>>Adept Technology
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>Good question. I am not using pthreads and the honest answer is "I dont
>>>>know".
>>>>I remember, however having brought this to Joel Sherrill's attention
>>>>(back in 2001
>>>>when I did the tests) and I believe he had some ideas about the cause...
>>>>
>>>>-- Till
>>>>
>>>>
>>>
>>>
>>>
>