Hi,
wow, what a fast reply!

> --- Ursprüngliche Nachricht ---
> Von: "Friedrich, Lars" <lars.friedrich@wago.com>
> An: "uClinux development list" <uclinux-dev@uclinux.org>
> Betreff: RE: [uClinux-dev] thread switching response time
> Datum: Thu, 17 Nov 2005 12:29:21 +0100
> 
> > problem:
> > poll_wait() returns 9 to 15 milliseconds too late
> > 
> > question:
> > What happens during that "long" time?
> 
> This is not really important.
> 
> Correct question:
> What is required to be woken up?
> A timer interrupt.
> 
> How often does a timer interrupt arrive?
> Every 10 milliseconds (+latency).
Aha. Understood.

> 
> > What can I do to have a response in time (say faster than 1ms)?
> 
> - Generate a IRQ
Good idea. poll_wait() is waiting for my IRQ anyway. So I'll going to
schedule such IRQ to happen after the timeout and store an additional info
that the IRQ is because of the timeout.
The µBlaze-CPU runs in the FPGA; to schedule such timed IRQ means to
implement a tailored "time-event"-IRQ-handler in the FPGA in parallel to the
µBlaze-CPU. Well, it's not a big problem.

But what if your 10ms-time-period was more dynamic, I mean if e.g. a given
timeout to poll_wait() temporarily changes the timer-frequency in the last
of n 10ms-periods to a smaller time to more coincide with the timeout time?
Of course, this would only make sense if time-stuff functions are only
"rarely" called.

> - Use a different operating system
hehe :)

> 
> Best regards,
> Lars Friedrich

Thanks very much,
F@lk

-- 
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat*  http://www.gmx.net/de/go/dsl
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org