RT issues

[Rene Reusner]

Rene Wittmann(Rene.B.Wittmann at informatik.stud.uni-erlangen.de)@2005.04.14 11:21:16 +0000:
> Hi,
> 
> As I'm trying to implement a real-time application in DROPS, I still
> have some questions on this topic. Maybe there's someone who can answer
> them because I didn't find it described it the documentation...
> 
> 
> 1. The timer granularity seems to be set to 976 microsec. Is there a
> special background for using this number or can I set it down (maybe
> even to 10 microsec, which what be a good time resolution for my task)?
> How can I set it? Or would it be stupid to set it to such a tiny value?

The granularity in fiasco depends on the used timer source.
You can configure the timer source via make menuconfig
in the fiasco build directory.

3 timers are available.

RTC: 976us, "real time clock" because you cant get excat 1ms with RTC.

PIT:   1ms, the ancient, ordinary pc timer.

APIC:  Depends if you use one shot timer or not

        one shot: 1us granularity.
                  timeouts & co have an theoretically 1us resolution.
                  In my experience, i would suggest around 20-30us
                  worst case, limited through fiascos "preemptibility".
                  The default time slice, maybe you want call this the
                  default granularity, is 1ms.

        periodic: 1ms

Values can be changed for example in
fiasco/src/kern/ia32/config-ia32.cpp

> 
> 
> 2. When looking at the rt_sched example in the hello-package: the
> main-thread has a preempter-thread for recognizing timeslice overrun and
> deadline misses. When does this preempter-thread recognize a TS overrun
> or a deadline miss? Right after this event (so within the next time
> resolution) or after the main-thread says that is has finished it's work
> (meaning after a call to "l4_rt_next_reservation")?

Right after the "event", but remember the preempter needs adequate
priority, if you want that the preempter thread is running right after
this event.

> 
> 3. How can the preempter-thread tell the main-thread to stop it's work
> in case of a timeslice overrun or even a deadline miss?

Same here, preempter thread maybe needs an priority higher than the main
thread. Then the preempter can, as Martin said, ex-reg the main thread.

> 
> 4. Does the system allow a thread's scheduling like this: 
> period-length  =  976 microsec, 
> timeslice_mand = 9760 microsec, 
> timeslice_opt  = 9760 microsec
> (which would mean that the system had to reserve timeslices that don't
> fit into one period...)
> 
> OR 
> 
> period-length  = 9760 microsec,
> timeslice_mand = 4380 microsec,
> timeslice_opt  = 4380 microsec
> (which would mean that the system had to reserve all resources for this
> thread..) 
> (what would happen if another thread comes with a period_length of also
> 9760 microsec and a timeslice_mand = 6000 microsec? What would be the
> system's behaviour?)

If i remember the fiasco src code right: Constantly time slice overrun IPCs.
> 
> Thanks, Rene
> 

rene too :)