Messages in this thread | | | Date | Tue, 01 Jun 1999 17:05:58 -0400 | From | Sam Roberts <> | Subject | timers, linux, &POSIX.4/1b |
| |
1) Changing HZ
100ms timer resolution isn't great for applications that are interacting with the real world. 1ms starts to be more useful for process control.
Changing HZ to 1000 and recompiling seems to work fine. I assume that any pre-compiled binaries using HZ will be wrong, but how bad can it be?
I don't know if Rubini's book reflects the views of this list, but he suggests that udelay() is good for dealing with hardware and that a 100ms jiffie is good enough for dealing with wetware (people), and what else could you want? In our case, access to time delays at the resolution supported by the hardware clock.
I understand that this may have negative impacts on performance, but the user is the person to decide what performance vs. functionality they need, the kernels will/would continue to ship with defaults appropriate for most users.
2) Is a timeslice == a timer tick?
3) There doesn't seem any way to include the right header so that struct itimerspec is defined for applications. Since I've implemented a version of the POSIX.4 timer_* calls, this is a pain.
POSIX.4 wants struct timespec, itimerspec, clockid_t, and timer_t all to be defined by including <time.h>. Any suggestions/chance at getting them there?
4) Where has all the POSIX.4 gone?
It appears that the alpha port has POSIX.4 timers and there is at least kernel support for queued/real-time signals. I haven't been able to see from the man pages whether this support extends into the application libraries, or test the queuing mechanisms yet.
I found patches for the posix.4 timer functions for intel platforms.
http://hegel.ittc.ukans.edu/projects/
Is anybody else interested in having the posix.4 timer functions integrated into the mainstream kernel? They are useful for non-realtime programs as well, they provide ways of getting the current timer resolution in a way not depending on the HZ define (clock_getres()), creating multiple timers, each of which runs seperately, and can be set absolutely or relatively, each timeout can be delivered to *any* signal (not just sigalrm).
Is there anybody actively working on implementing posix.4 timers in the kernel?
Sam
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |