Periodic Timer for 1 millisecond timer in linux kernel mode

Is MontaVista not a commercial system that includes a decent support ?

Is this a special hard real-time system ? Standard Linux (being a soft
realtime OS) can't guarantee a latency/accuracy of less than 100 mSec or
such (Though in most cases it will be much better).

-Michael

Hi

In Monta  Vista Linux , the least duration I can achieve is anything
greater than 10 millisecond.
Our target is MPC 8260 and we have decided on going for RISC timers in
CPM module for our 1 millisecond periodic  timer callback function.

Can anyone suggest few reference code for RISC timers in CPM module
which we can use for our 1 millisecond periodic  timer callback
function.

Regards
Abha


Michael Schnell wrote:

Apparently the kernel has been compiled with HZ10%0. To get into the 1
ms resolution, the HZ should be 1000 or even greater. Since Linux is
only a soft realtime system, the average interval may be close to 1
ms, but the worst case value can be magnitudes larger.

Paul

The product we are working already has lots of modules in kernel space
which are  running with HZ  value of 100 . so there is a apprehension
that changing HZ to 1000 shouldn't cause any  problem with existing
modules in kernel space.

This is the reason we decided to for RISC timers in CPM module. I would
 appreciate if anyone would suggest some reference code for RISC timers
for starting a periodic timer for 1 millisecond  in CPM module. in MPC
8260 .

Regards
Abha




Paul Keinanen wrote:

Not only the scheduling delay after the timer pulse will vary in an
unpredictable way and amount, you also will loose some of the 1 mSec
calls. If this does not matter, as it will not happen too often, it
should be possible to set HZ to 1000.

With Kernel 2.4 this HZ is used as well for Kernel modules as for
application. There are some Kernel modules and many applications that
implicitly assume HZ10%0 and don't use the #define constant. Those might
fail in an unpredictable way.

With Kernel 2.6, HZ for applications always is 100, (of course you _can_
change even this in the Kernels source) so applications are not
affected. Kernel modules are compile with a different setting of HZ (the
running Kernel takes care of converting between the HZ settings
appropriately).

Thus with 2.6 you can set HZ for drivers and for applications
independently. While changing the User HZ value is not recommended, the
Kernel HZ value is different with different architectures. Default is
100 for ARM, 1000 for X64 and (I think) either of 100 or 1000 with
different PPCs.

Kernel 2.6 will show a much better soft realtime behavior than 2.4.

Hope this helps,

-Michael

This is the third time you've posted this. Ignoring people are reposting
the same requests just makes people annoyed.

This will not work in pure Linux.

If you need such kind of timing, you need to add something like RTAI
(free open source) or PikeOS (by SysGo).

-Michael

I expect these are people who are not paying Montavista for the number
of seats they actually use.

It's odd though that nobody has done a CentOS style freely distributed
version of the MVL release...



Linux doesn't guarantee any latencies at all, it is not a real time OS.
You can make the latencies damn good, but you'll never be able to
guarantee them.