Re: [ANNOUNCE] high-res-timers patches for 2.6.6

[George Anzinger <george@mvista.com>]

Karim Yaghmour wrote:
> 
> Geoff Levand wrote:
> 
>> For those interested, the set of three patches provide POSIX high-res 
>> timer support for linux-2.6.6.  The core and i386 patches are updates 
>> of George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
>> <http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
>> not available on SourceForge yet.
> 
> 
> I've got to ask:
> 
> Just reading from the Posix 1003.1b section 14 spec referenced by the HRT
> main project page, I see the following:
> ------------------------------------------------------------------------------ 
> 
> Realtime applications must be able to operate on data within strict timing
> constraints in order to schedule application or system events. Timing
> requirements can be in response to the need for either high system 
> throughput
> or fast response time. Applications requiring high throughput may process
> large amounts of data and use a continuous stream of data points equally
> spaced in time. For example, electrocardiogram research uses a continuous
> stream of data for qualitative and quantitative analysis.
> ------------------------------------------------------------------------------ 
> 
> 
> If this is really the goal here, then why not just integrate Adeos into
> the kernel and make some form of HRT as a loadable module that uses 
> Adeos to
> provide its services?
> 
> Currently Adeos runs on x86, ARM (MMU-full and MMU-less), PPC, so 
> portability
> is not an issue. Plus, the interface provided can either be directly used
> by drivers to get hard-rt interrupts or it can be used by another layer to
> provide more elaborate services (like RTAI or, potentially, HRT.) Using the
> virtual interrupts that can be dynamically allocated at runtime, it's 
> rather
> easy to send signals between domains.
> 
> Sure, you may not have the exact Posix 1003.1b API, but I don't remember 
> there
> being any persistent goal of having the kernel conform to any standard.

I don't see how this delivers any added value to the user.  I suppose code 
running at the kernel level might gain something, but at the user level we still 
have to deal with preemption latencies, which are the biggest problem (and, 
aside from messing up the accuracy of the timers, are NOT timer issues at all).

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml