Periodic Timer for 1 millisecond timer in linux kernel mode

Hi all

I need to implement a periodic timer callback for 1 millisecond with a accuracy of +/- 100 ppm .

The OS is monta vista linux version 2.4 and the target is mpc 8260.

1) How can I achieve a periodic timer callback for 1 millisecond ?

2) How can I test the accuracy of the periodic timer callback function is within +/- 100 ppm?

Can anyone let me know how can I go about acheiving the above in MPC

8260?

Regards Abha

Reply to
Abha
Loading thread data ...

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

Reply to
Michael Schnell

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:

Reply to
Abha

Apparently the kernel has been compiled with HZ=100. 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

Reply to
Paul Keinanen

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 Ke>

Reply to
Abha

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.

Reply to
Geronimo W. Christ Esq

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

Reply to
Geronimo W. Christ Esq

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

Reply to
Michael Schnell

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 HZ=100 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

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.