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 move, but at least it sticks around! - mo On Thu, 2003-09-18 at 10:27, Benno Senoner wrote: > 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 that software engineers can > > control the scheduling of tasks with precision." > > > The promise of the high-res timer patch was usec resolution, not msec. > > This would be a great loss. Does anybody know any more? > > Yes unfortunately it is true what they say in the article. > The current timer resolution is 1msec (HZ = 1024, so to be precise > the resolution is (1/1024) sec). > > In short the story is as follows: Linus accepted the > POSIX 1003.1b Section 14 (Clocks and Timers) API in kernel 2.6 > but not yet it's implementation > (patches available here http://high-res-timers.sourceforge.net/ ). > > This means that applications using the POSIX 1003.1b timer API can > specify timing values nanosecond resolution but for now only > msec resolution is provided. > But when the Linus & co will let in the kernel the high-res > timer implementation, those apps will instantly be able to achieve > higher resolution without recompilation etc. > > Yes usec resolution would be handy for some audio apps but I for > now I am happy of being able to achieve msec resolution in MIDI playback > without resorting to the RTC device which cannot easily be shared. > > > PS: in the article they talk about 4500usec worst case scheduling > latency (= 4.5msec), seems a bit disappointing. > I'm curious what they mean with worst case, > which kind of test suites they used etc. > 2.4 + some LL patches let you reliably work with sub 3msec BTW. > > Benno > > > ------------------------------------------------- > This mail sent through http://www.gardena.net
