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?
> 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
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
