Paul Davis writes:
> the kernel gives non-SCHED_FIFO/RR threads roughly 1/HZ
> resolution.
Seems to be 20 ms on my unpatched standard SuSE 2.4.19.
I imagine this can be lowered by modifying the kernel config ?
> SCHED_FIFO/RR threads can get better than that if the
> delay is very small, but
> > while (1) {
> > ...
> > usleep (usecs_till_next_event);
> > /* we're know its the right time,
> > instead of being rounded to
> > the default HZ
> > */
> > deliver_events ();
> > }
>
>Is this really new ? I was porting some C++ thread cl
Steve Harris writes:
> On Fri, Feb 28, 2003 at 03:49:59 +0100, Fons Adriaensen wrote:
> > Is this really new ? I was porting some C++ thread classes (originally
> > developed for Solaris) to 2.4.19 this week. The ITC mechanism uses
> > pthread_cond_timedwait(), which takes a struct timespec * r
On Fri, Feb 28, 2003 at 03:49:59 +0100, Fons Adriaensen wrote:
> Is this really new ? I was porting some C++ thread classes (originally
> developed for Solaris) to 2.4.19 this week. The ITC mechanism uses
> pthread_cond_timedwait(), which takes a struct timespec * referring to
> an absolute time, t
Paul Davis writes:
> >>From the 2.5.63 changelog:
> >
> > o POSIX clocks & timers
> >
> >Phat :)
>
> Super-Callifragilistic-Expealido-phat-cious!!
>
> finally, we can do real MIDI sequencing with Linux:
>
> while (1) {
> ...
> usleep (usecs_till_next_event);
>
On Thu, 2003-02-27 at 17:00, Paul Davis wrote:
> i just hope that this change reflects the whole enchilada
> (reprogramming the APIC) rather than just the POSIX clock API. is
> there any sign of this?
I believe so. From this thread in the high-res-timers archives:
http://sourceforge.net/mailarc
>>From the 2.5.63 changelog:
>
> o POSIX clocks & timers
>
>Phat :)
Super-Callifragilistic-Expealido-phat-cious!!
finally, we can do real MIDI sequencing with Linux:
while (1) {
...
usleep (usecs_till_next_event);
/* we're know its the right time,
in
>From the 2.5.63 changelog:
o POSIX clocks & timers
Phat :)
--
Bob Ham <[EMAIL PROTECTED]>
