# POSIX timer functions

M

#### Mario de Sousa

Hi again,

To tell the truth, the period library is not quite correctly implemented. I need to use alarms/timers, but it seems that my linux box does not have the POSIX timer functions.

Does anybody know if linux supports the following POSIX functions:
int timer_create(clockid_t clockid,
struct sigevent *evp,
timer_t *timer_id)
int timer_delete(timer_t timer_id);
int timer_settime(timer_t timer_id,
int flags,
const struct itimerspec *value,
struct itimerspec *ovalue);
int timer_gettime(timer_t timerid,
struct itimerspec *value);
int timer_getoverrun(timer_t timerid);

I know linux supports the alarm()/setitimer()/getitimer() alternative
functions, but I would rather use POSIX functions if at all possible.

Cheers,

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

K

#### Ken E.

Hi Mario

I don't know off hand, but have you checked out the Posix Real time extensions such as implemented in RTLinux?? I am pretty sure there are posix timers with nanosecond and usecond kinds of resolutions but I don't have my linux box here at work ( (Its somethign I plan on rectifying soon).

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

> I don't know off hand, but have you checked out the Posix Real time extensions such as implemented in RTLinux?? I am pretty sure there are posix timers with nanosecond and usecond kinds of resolutions but I don't have my linux box here at work ( (Its somethign I plan on rectifying soon).
>

Yes, but it must also be able to run under plain old linux.

I think I am going to write a lib/misc/timer_util.c file with timer
functions. When the time comes to port to POSIX, we can simply replace this file without messing around in the rest of the code.

Does anybody have any ideas for the API of timer_util.c?

******************

Regarding RTlinux, I was thinking of using the Resource Kernel (RK) approach to RTLinux, rather than the the version also known as KURT. The RK approach lets normal user processes become RT processes. The KURT approach requires the RT processes be written as Linux Kernel modules.
This makes it much easier to port to the the RK version of RTLinux.

The last time I worked with the RK RTLinux (about a year ago), it was possible to have periodic processes down to 0,5 ms periods, but no
lower. I believe that KURT RTLinux would allow lower periods, but I don't know how small.

Do you think 0,5 ms periods are too large? Do you think smaller periods are desirable?

I used periods multiples of 1 ms because of the above constraint. Does this make sense to you?

I also used 32 bit unsigned int for the period, which allows periods up to almost 50 days. Using usec, would bring this down to 71 minutes.
Should we bring the period up to 64 bits? Should we break the u32 into blocks of different resolutions, e.g.
For x from 0 to 999999 means 0 to 999999 us
For x from 100000 to ... means (x - 100000) + 100 ms
Will we be able to enforce sub ms periods with KURT?

Any sugestions and answers to the above questions are welcome!!!

Cheers,

Mario.

RK RTLinux: http://www.aero.polimi.it/projects/rtai/
http://www.timesys.comKURT RTLinux: http://www.ittc.ukans.edu/kurt/
--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

K

#### Ken E.

Hi Mario,

Certainly having an abstracted timer library would be nice and also help the portability of this project. Is this library something that the interpreters and/or module code will access for basic timing operations on the machine for the application code? It sounds like this library will be primitives for higher level timer based functions??

****

As for RTLinux ....

For the sake of conversation, RTLinux is a product name and produced by FSM Labs and originated by Michael Barbanov. (www.rtlinux.com)

I have heard of KURT but I have not tried it out. It seems like RTlinux is becoming a very popular platform in the last few months for embedded and control applications that require hard real time. Everythign I have read says that you cannot have hard real time using the standard linux kernel alone, but this might have changed since I last examined the situation. What is the Resource Kernel (RK) you are referring to, and who wrote it? An interesting concept, but I am leary of a lot of these supposed "real time" kernel modifications. They often are *mostly* real time which is ridiculous! )

The RTlinux implementation allows periods of microseconds, which, of course is dependant on how fast your machine runs. Most folks will probably run at > 1ms but there is desire in the market to have sub millisecond scan rates (I think the next version of steeplechase VLC product goes down to 250 us or so) At my company 1ms is sufficuent, but we could make more money on a lot of machines if the scan time were less.

as for the scan value, 32 bit is fine I think. The most frequent need to increase the scan time is to get better average free CPU time, but when you get up into seconds and minutes, it doesn't really matter I think. I would be definitely happy with a scan of 1us to 71 minutes!

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Ken:
> Hi Mario,

> Certainly haivng an abstracted timer library would be nice and also help
> the portability of this project. Is this library something that the
> interpreters and/or module code will access for basic timing operations
> on the machine for the application code? It sounds like this library will
> be primitives for higher level timer based functions??

That's how I understood it...

Actually, there already *is* a timer library - see lib/logic/timer.h

> as for the scan value, 32 bit is fine I think. The most frequent need to
> increase the scan time is to get better average free CPU time, but when
> you get up into seconds and minutes, it doesn't really matter I think. I
> would be definitely happy with a scan of 1us to 71 minutes!

If it's a library of primitives for higher-level functions, then 71 minutes is definitely not enough. It's enough for scan times, but not really for user-level timers, which can run for hours (baking times, watering times).

The above-mentioned library uses "struct timeval" from &lt;sys/time.h> when precision is required and "double" when it isn't.

Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a --Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Mario:
> I think I am going to write a lib/misc/timer_util.c file with timer
> functions. When the time comes to port to POSIX, we can simply replace
> this file without messing around in the rest of the code.

> Does anybody have any ideas for the API of timer_util.c?

Check the API in lib/logic/timer.h - it may be possible to combine the two.

At the very least, they should be compatible (use similar logic &c.), but most likely you'll be able to do a wake me when timer T1 reaches t secs'' thing.

Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

Jiri Baum wrote:
>
> Ken:
> > Hi Mario,
>
> > Certainly haivng an abstracted timer library would be nice and also help
> > the portability of this project. Is this library something that the
> > interpreters and/or module code will access for basic timing operations
> > on the machine for the application code? It sounds like this library will
> > be primitives for higher level timer based functions??
>
> That's how I understood it...
>
> Actually, there already *is* a timer library - see lib/logic/timer.h

Actually, I was thinking of the timer_util.c functions as a layer to abstract our code from incompatibilities of different OS (POSIX,
Linux, the several variants of RTLinux, ...).

I would expect the lib/logic/timer.h functions to use the lib/misc/timer_util.c functions. In my mind, both libraries are necessary.

My question remains. What API should timer_util.c provide? Should it provide a POSIX interface, and then we can merely remove all the code with
#ifndef _POSIX_ /* Is this the correct symbol to use? */
...
#endif
for POSIX OSes.

Is it possible to build a POSIX interface with only the linux functions available? I haven't given this much thought myself. (See PS).

> If it's a library of primitives for higher-level functions, then 71 minutes
> is definitely not enough. It's enough for scan times, but not really for
> user-level timers, which can run for hours (baking times, watering times).

I agree with Jiri here. Maybe u64 is what we need. Or a timeval struct with it's two u32.

Cheers,

Mario.

PS. I have been a little busy lately. Our fileserver crashed, and we hadn't yet got around to configuring the hot backup to come online
automatically. It is now done, using high availability linux, it's actually a very neat
configuration! The main server is back up too. The OS disk died. We just had to dd the OS disk of the backup server to a new disk, and change the
name and IP of the machine.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Johan Bengtsson

71 minutes would still be useful as the basic timer this time can be expanded by the code calling it to as long times as wanted without any trouble at all

double might perhaps not really be a good type the time, not if it is to be increased by small amounts since it looses it's precision when the value gets bigger.

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

> My question remains. What API should timer_util.c provide? Should it
> provide a POSIX interface, and then we can merely remove all the code
> with
> #ifndef _POSIX_ /* Is this the correct symbol to use? */
> ...
> #endif
> for POSIX OSes.
>
> Is it possible to build a POSIX interface with only the linux functions
> available? I haven't given this much thought myself.

With some more 5 minutes thought... a new question came up

I am afraid that using the alarm() or equivalent function for the scan_period functionality may mean that the module code cannot call any sleep() functions. As the man page says:
sleep() may be implemented using SIGALRM; mixing calls to
alarm() and sleep() is a bad idea.

Is this too restrictive? what do we do then?

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

[email protected]:
> 71 minutes would still be useful as the basic timer
> this time can be expanded by the code calling it to
> as long times as wanted without any trouble at all

Seems a pity to make an API that will be inconvenient in this way...

> double might perhaps not really be a good type the time,
> not if it is to be increased by small amounts since it
> looses it's precision when the value gets bigger.

Definitely - that's why it uses the struct timeval internally, which is microsecond resolution integer. It just uses double in the interface with warnings never to add or subtract them.

Jiri

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

"Ken Emmons, Jr." wrote:
> As for RTLinux ....
>
> For the sake of conversation, RTLinux is a product name and produced by FSM Labs and originated by Michael Barbanov. (www.rtlinux.com)
>
> I have heard of KURT but I have not tried it out. It seems like RTlinux is becoming a very popular platform in the last few months for embedded and control applications that require hard real time. Everythign I have read says that you cannot have hard real time using the standard linux kernel alone, but this might have changed since I last examined the situation. What is the Resource Kernel (RK) you are referring to, and who wrote it? An interesting concept, but I am leary of a lot of these supposed "real time" kernel modifications. They often are *mostly* real time which is ridiculous! )

I have been skimming through the docs of the FSMlabs version of RTLinux. The concept is similar to the KURT RTLinux.

For anybody interested in RTLinux, I sugest they read the white paper at http://www.timesys.com/downloads/LinuxRealTime.pdf for an overview of all the different versions of RTLinux, and where they came from.

Regarding RK RTLinux, I fooled around with it a bit a few months ago, and I can say that the RT processes get interrupted by the top half of
the device drivers handling the interrupts (timer, network, disk, etc...). This means that the top half of the device drivers have to be properly written in order to be deterministic. Note that the fact that they interrupt a RT process is not necessarily a bad thing. With hard RT what you are after is not necessarily short execution times, but deterministic worst case execution times (WCET).
One advantage is that your RT processes can use normal device drivers to interface to the hardware. The drawback is that you either trust the code of the device drivers, or you go through it with a _very_ fine comb.
For e.g., I skimmed through the cif device driver for the cif interface cards, and I can say that you cannot use it for RT applications. It is
not deterministic simply because it calls kmalloc() for every invocation.
Your own code has to be carefully written so as not to call non-deterministic functions in time-critical blocks of code. You also have to lock your code into RAM, and keep it out of disk swapping.
I would say that you can trust timesys to a certain extent taking into account that they employ Dr. Rajkumar (_VERY_, _VERY_, big name in RT research circles, he co-auther the Priority Inheritance Protocol, and it's distributed version - you can read about it in his book "Synchronization in Real-Time Systems - a priority inheritance approach", Kluwer academic
publishers), and Doug Locke, former chief scientist of Lockeed Martin.

With the FSMlabs RTLinux version all the processes are run as linux kernel modules, which means a single bad pointer will bring down the whole OS! I don't know to what extent you can use normal device drivers to interface to the hardware either. It could be an intersting project to try to port the PuffinPLC to their version of RTLinux. Maybe we should do this at an early stage where it is still possible to adapt the PuffinPLC so as to fit some constraints of this architecture. The RK version of RTLinux would be much easier to work with, but would probably give a litle larger context switch times.

>
> The RTlinux implementation allows periods of microseconds, which, of course is dependant on how fast your machine runs. Most folks will probably run at > 1ms but there is desire in the market to have sub millisecond scan rates (I think the next version of steeplechase VLC product goes down to 250 us or so) At my company 1ms is sufficuent, but we could make more money on a lot of machines if the scan time were less.

I am not saying that we can't get smaller scan times. You can let the PLC go at full speed, and your scan times might well be less than 1 ms.

> as for the scan value, 32 bit is fine I think. The most frequent need to increase the scan time is to get better average free CPU time, but when you get up into seconds and minutes, it doesn't really matter I think. I would be definitely happy with a scan of 1us to 71 minutes!
>

Anyway, you have convinced me that 1 ms resolution is not enough! I'll change this as soon as I get the chance. But I still think 71 minutes is not enough!

Cheers,

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

How about usleep? I haven't delved into the implementation, but I have used it to resolve conflicts between sleep and alarm. I believe it's based on selectin Linux at least but it is at least portable to BSD.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

G

#### Gilles Allard

Hi Mario
> I used periods multiples of 1 ms because of the above
constraint. Does
>this
>make sense to you?
>
> I also used 32 bit unsigned int for the period, which allows periods
>up to almost 50 days. Using usec, would bring this down to 71
minutes.
>Should we bring the period up to 64 bits? Should we break the
u32
>into blocks of different resolutions, e.g.
>For x from 0 to 999999 means 0 to 999999 us
>For x from 100000 to ... means (x - 100000) + 100 ms
>Will we be able to enforce sub ms periods with KURT?
>

I think that 1ms would be sufficient for all our applications but I can understand some applications may require a finer resolution.
For sake of comparison, Siemens (in their S7 family) use a DINT with 1ms resolution while AllenBradley (in the ControlLogix family) use two DINT with 1 microsecond resolution (albeit their
scheduler use 1ms resolution). I found it is cumbersome to compute elapsed time whem time is in
2 DINT but that may be eased with an appropriate function in library.

Gilles

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

Curt Wuollet wrote:
>
> How about usleep? I haven't delved into the implementation, but I have used
> it to resolve conflicts between sleep and alarm. I believe it's based on select
> in Linux at least but it is at least portable to BSD.
>

I have been doing a litle testing, and no matter which way you cut it, standard Linux does not give you timer resolution under 10 ms, including the usleep() function!

I put 1000 usleep(100) consecutive functions (not in a loop!) and the program took 20 seconds to finish!

Oh well. I'll see what I can do, and then you can comment on the code.

Cheers,

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc