Re: Best Kernel Timers?

Re: Best Kernel Timers?

[Simon White]

> Have you taken a look at what is being done by Thomas Gleixner?
> 
> http://lwn.net/Articles/152363/

No didn't know of this, will take a look.

> 
> Also you may be interested in Ingo Molnar's RT kernel.
> 
> http://people.redhat.com/mingo/realtime-preempt/

Unless I'm mistaken this is a external patch i.e. not in mainline?
I do know of the work, but people willing to patch the kernel
should hopefully equally be able to cope with an rtai or rtlinux
patch.  If this is integrated into mainline I'll definately
check it out.

> 
> As well as the work being done by the HRT folks.
> 
> http://sourceforge.net/projects/high-res-timers
> 

I posted a similiar question there but received no response.  From
what I can tell it is a frame work for providing hardware specific
timer sources to the kernel and also exporting posix userspace
system calls from the kernel.  It may do more in kernel but haven't
found exactly what it does, relevent docs?  Also is this in mainline
(or soon to be) or just patches against it?

Thankyou for your response.

Simon


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: Best Kernel Timers?

[Steven Rostedt]

On Wed, 28 Sep 2005, Simon White wrote:

> >
> > Also you may be interested in Ingo Molnar's RT kernel.
> >
> > http://people.redhat.com/mingo/realtime-preempt/
>
> Unless I'm mistaken this is a external patch i.e. not in mainline?
> I do know of the work, but people willing to patch the kernel
> should hopefully equally be able to cope with an rtai or rtlinux
> patch.  If this is integrated into mainline I'll definately
> check it out.

You may have to wait a while.  The biggest difference between Ingo's patch
and rtai is that Ingo's patch doesn't require changing the programs to run
as realtime tasks.  It makes the Linux kernel an actual RTOS (as suppose
to running a micro kernel underneath) so if you can program on Linux,
there's no learning curve for Ingo's work.

>
> >
> > As well as the work being done by the HRT folks.
> >
> > http://sourceforge.net/projects/high-res-timers
> >
>
> I posted a similiar question there but received no response.  From
> what I can tell it is a frame work for providing hardware specific
> timer sources to the kernel and also exporting posix userspace
> system calls from the kernel.  It may do more in kernel but haven't
> found exactly what it does, relevent docs?  Also is this in mainline
> (or soon to be) or just patches against it?

I'm not really sure what you have against patches?  If you have to wait
for this to be in the mainline, you are going to be disappointed.

-- Steve

Re: Best Kernel Timers?

[Christoph Lameter]

On Wed, 28 Sep 2005, Simon White wrote:

> I posted a similiar question there but received no response.  From
> what I can tell it is a frame work for providing hardware specific
> timer sources to the kernel and also exporting posix userspace
> system calls from the kernel.  It may do more in kernel but haven't
> found exactly what it does, relevent docs?  Also is this in mainline
> (or soon to be) or just patches against it?

This is in mainline since 2.6.10. You can define additional clocks.

CLOCK_MYCLOCK

and then register a new posix clock.

Re: Best Kernel Timers?

[Christoph Lameter]

On Wed, 28 Sep 2005, Simon White wrote:

> Now as an alternative it is again desired that a version (although
> wont perfectly work) be available to a vanilla 2.6 kernel (possibly
> 2.4) with similiar limitations as before.  Its a shame the posix
> calls appear to not be supported in kernel for drivers so I have
> wrapped the calls for semaphores/mutexs/threads to kernel
> equivalents.

They are supported. See drivers/char/mmtimer.c for an example 
implementation.

> However I have no idea what to do for the timers.  Is there
> something suitable inkernel that would provide an async callback
> to pre-empt a realtime thread and provide better resolution than
> HZ a far amount of the time?  Or do I have to run a seperate lower
> priority busy waiting thread to wakeup the realtime one?

Yes. Provide an implementation for a posix clock like done in the mmtimer 
driver.

Re: Best Kernel Timers?

[Simon White]

> I'm not really sure what you have against patches?  If you have to wait
> for this to be in the mainline, you are going to be disappointed.

Me, personally nothing, but trying to get every user of a catweasel or
hardsid card to patch there kernel is the problem.

For those that do wish to patch there systems I have alternative
better realtime code.  For those that don't I wanted something that
would approximately work as I had before.

As a note I've found it bad enough to try and get users to build the
normal drivers for there prebuilt kernels... with various requests
as to please put this in mainline (although not ready for that) so
it comes pre-built and installed for there system.

If there are no currently in mainline even approaching suitable clocks
(why I asked) then I'll resort to some custom busy waiting mechanism :(.

Thankyou for helping.
Simon


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: Best Kernel Timers?

[Steven Rostedt]

On Wed, 28 Sep 2005, Simon White wrote:

> Hi,
>
> Wondered if anyone could provide information about where to look for
> suitable kernel timers?

Have you taken a look at what is being done by Thomas Gleixner?

http://lwn.net/Articles/152363/

Also you may be interested in Ingo Molnar's RT kernel.

http://people.redhat.com/mingo/realtime-preempt/

As well as the work being done by the HRT folks.

http://sourceforge.net/projects/high-res-timers

-- Steve

>
> For a while I have been working on supporting the hardsid/catweasel
> cards on Linux (and Windows).  Although undesirable the original
> implementations required real usec delays in the OS
> (this requirement being fixed in the very latest hardware).  I know
> Linux is not realtime so the original drivers were designed to
> queue hardware writes to a realtime thread that busy waited and
> recovered as best it could from errors (on the whole this worked
> pretty well).  Also another version of the code was written to use
> rtlinux/rtai that was capable of non busy waiting.
>
> More recently with the release of the new buffering hardware the
> driver was redesigned from the realtime posix code.  Due to these
> changes the busy waiting (for the old cards) can nolonger occur
> and the delays have to happen asynchronusly notifing the realtime
> thread when the delay has expired.  The code uses the posix
> timer_set, etc calls with realtime clock with absolute delays and
> flags a semaphore when the signal occurs (works great under
> realtime systems).
>
> Now as an alternative it is again desired that a version (although
> wont perfectly work) be available to a vanilla 2.6 kernel (possibly
> 2.4) with similiar limitations as before.  Its a shame the posix
> calls appear to not be supported in kernel for drivers so I have
> wrapped the calls for semaphores/mutexs/threads to kernel
> equivalents.
>
> However I have no idea what to do for the timers.  Is there
> something suitable inkernel that would provide an async callback
> to pre-empt a realtime thread and provide better resolution than
> HZ a far amount of the time?  Or do I have to run a seperate lower
> priority busy waiting thread to wakeup the realtime one?
>
> Advice appreciated.
> Simon
>
> --
> ___________________________________________________________
> Sign-up for Ads Free at Mail.com
> http://promo.mail.com/adsfreejump.htm
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Best Kernel Timers?

[Simon White]

Hi,

Wondered if anyone could provide information about where to look for
suitable kernel timers?

For a while I have been working on supporting the hardsid/catweasel
cards on Linux (and Windows).  Although undesirable the original
implementations required real usec delays in the OS
(this requirement being fixed in the very latest hardware).  I know
Linux is not realtime so the original drivers were designed to
queue hardware writes to a realtime thread that busy waited and
recovered as best it could from errors (on the whole this worked
pretty well).  Also another version of the code was written to use
rtlinux/rtai that was capable of non busy waiting.

More recently with the release of the new buffering hardware the
driver was redesigned from the realtime posix code.  Due to these
changes the busy waiting (for the old cards) can nolonger occur
and the delays have to happen asynchronusly notifing the realtime
thread when the delay has expired.  The code uses the posix
timer_set, etc calls with realtime clock with absolute delays and
flags a semaphore when the signal occurs (works great under
realtime systems).

Now as an alternative it is again desired that a version (although
wont perfectly work) be available to a vanilla 2.6 kernel (possibly
2.4) with similiar limitations as before.  Its a shame the posix
calls appear to not be supported in kernel for drivers so I have
wrapped the calls for semaphores/mutexs/threads to kernel
equivalents.

However I have no idea what to do for the timers.  Is there
something suitable inkernel that would provide an async callback
to pre-empt a realtime thread and provide better resolution than
HZ a far amount of the time?  Or do I have to run a seperate lower
priority busy waiting thread to wakeup the realtime one?

Advice appreciated.
Simon

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm