On 21 July 2010 13:05, Stephen Bryant <[email protected]> wrote:
> On 21 July 2010 12:06, Gilles Chanteperdrix < > [email protected]> wrote: > >> Stephen Bryant wrote: >> > Hi, >> > >> > I have some code (simplified example below) which uses >> > 'pthread_wait_np(&Overrun)' within a while loop, using a period of >> > 1,000,000ns (1ms) which has been set using 'pthread_make_periodic_np()'. >> > This wakes the thread up less than 2,000ns late in general, sometimes >> > 20,000ns late, and at most less than 45,000ns late. >> >> Since you do not tell us, I guess you are running on x86. Depending on >> the x86 you are running, 45 us may be high. >> >> > Yes, it is x86, sorry for the omission. What sort of latencies would you > expect me to see? > Sorry, I should have given more info. It is an Intel Core 2 Duo, running a kernel with SMP disabled. > >> To ensure that I perform >> > the tasks within the thread from a consistent 'millisecond tick' I set >> an >> > expected time value 45,000ns later than the earliest wake time each >> period, >> > and then use a busy loop until the current time equals this expected >> time. >> > This busy loop takes < 600ns per cycle, and so the latency from my >> expected >> > time should be a maximum of 600ns. >> >> This reasoning is flawed: you may be preempted by interrupts any time. >> Including just about at the time where you were going to exit the busy >> loop. Unless you spin irqs off, and only reenable irqs when the job the >> thread is supposed to be doing is done. And if you have an SMI issue, >> even turning off the interrupts will not help. >> >> > I was under the (apparently flawed) impression that Adeos was used to > prevent interrupts preempting a running high priority task in primary mode, > only forwarding the interrupts to Linux once the task was waiting / > finished. I guess that it only prevents a subset of all interrupts, and the > rest must be specifically disabled then re-enabled by the program, or maybe > it does not intercept any interrupts? > > >> >> The latencies I am actually seeing are as >> > high as 13,000ns, and these occur during this busy loop (I have timed >> it), >> > implying that this loop is being preempted. >> > >> > while(1) >> > { >> > pthread_wait_np(&Overrun); >> > >> > WakeTime = GetTime(); >> > while(WakeTime < ExpectedTime) >> > { WakeTime = GetTime(); } // Preempted here >> > >> > DoWork(); >> > >> > ExpectedTime += Period; >> > } >> > >> > This is a Xenomai POSIX thread with a priority of 99, and is the only >> thread >> > within my program with a priority of 99 or higher. There are no context >> > switches occuring within this thread (confirmed using >> pthread_set_mode_np(0, >> > PTHREAD_WARNSW)). >> > >> > I have had a brief experimentation with kernel settings, for example >> > applying the SMI workaround, but this produces no difference to the >> > preemption that I measure. >> >> The question is: is the SMI workaround working for your chipset? If that >> is the case, you should get messages in the kernel logs. >> >> > I've had a look at dmesg, but cannot find any references to SMI - what > should I be looking for? > > >> -- >> Gilles. >> > > Steve > Steve
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
