An interesting historical sidenote on this came from of our programmers,
who was deep in the BeOS. He told me that their timeslice was 3 msecs
once everyone had 500 MHz machines. It was down to 1 msec for the never
released R6 version... back in, what 1999? 2000?
the sad part is that the HRT
On Fri, Sep 19, 2003 at 07:23:47AM -0400, Paul Davis wrote:
Open source is a bit slower to move, but at least it sticks around!
So true. Anyway, at least there will be a patch; the most recent one
for 2.4.20 just came out.
You mean: http://sourceforge.net/projects/high-res-timers/ ?
I just
You mean: http://sourceforge.net/projects/high-res-timers/ ?
I just stumbled on this while searching for high resolution timers on
google: http://www.cs.wisc.edu/paradyn/libhrtime/
It seems old though (and probably unmaintained ?), latest patch was for
2.4.0, so I don't know if it is of more
Hi,
First I must admit right away, I only looked at the pretty pictures so far,
but they where sufficiently nice for me to post it here ;-P.
http://linuxdevices.com/articles/AT7751365763.html
/Robert
http://linuxdevices.com/articles/AT7751365763.html
Nice article.
I hope this is not true:
Embedded systems often need to poll hardware or do other tasks on a
fixed schedule. POSIX timers make it easy to arrange any task to get
scheduled periodically. The clock that the timer uses can be set to
Paul Davis wrote:
I hope this is not true:
Embedded systems often need to poll hardware or do other tasks on a
fixed schedule. POSIX timers make it easy to arrange any task to get
scheduled periodically. The clock that the timer uses can be set to
tick at a rate a fine as one kilohertz, so
An interesting historical sidenote on this came from of our programmers,
who was deep in the BeOS. He told me that their timeslice was 3 msecs
once everyone had 500 MHz machines. It was down to 1 msec for the never
released R6 version... back in, what 1999? 2000?
Open source is a bit slower to
