Rene Wittmann(Rene.B.Wittmann@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...
- 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
- 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.
- 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.
- 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 :)