> > No, it doesn't accomplish this, but it can. The kernel will have to > > support it, so Linux will have to gain accurate scheduling. In the > > meantime I think getting the clock resolution on Intel from 10ms > > down to 1ms will be sufficient in most cases. > > How likely is it that this will happen in mainstream Linux kernels? > *heh* > > Then again, as it seems like the goal is to have properly working > kernel preemption (required for real time, as well as high end SMP > scalability), things like that actually start to become *useful* for > real applications...
preemtible kernel patch is already in 2.5... > After all, if games, audio applications and other multimedia > applications are going to fight for the RTC, and then hog the > scheduler with 1024+ Hz "wakeup rates", we have a problem. > > At that point, it would be a lot more efficient if those applications > could just use high resolution software timers (driven by the > programmable system timer, something like in KURT, AFAIK), programmed > to wake threads up *only when required*, as opposed to "at an > arbitrary rate, just high enough to do the job". I think IBM had a patch that did this because the overhead of getting interrupted by the system timer every 10ms was too large running a lot of linux kernel images on their servers. > Is this relevant to other applications than "professional MIDI > applications"? I think so. > > I really don't think that's necessary. A <<ms accurate time should > > be sufficient. > > Well, it all depends on your definition of "correct MIDI timing"... <<ms --martijn
