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? 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")? 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? 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?) ===================================================================== Other thing: File system support: 1. which filesystems are supported (reiserfs?)? 2. Is there a way to have RT access to disk and accessing files this way? If so, how? Thanks, Rene
Rene Wittmann wrote:
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...
You might want to read: http://os.inf.tu-dresden.de/papers_ps/steinberg-diplom.pdf <...>
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?
You could synchronize both threads using shared mem or you could ex_regs the worker thread from the preempter, whatever you like.
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?)
I think, the kernel does not prevent over-reservation, it will simply generate *overrun messages at runtime. Ressource admission should be done in userland. We currently have the package "cpu_reserve" in our local repository.
Other thing: File system support:
1. which filesystems are supported (reiserfs?)?
Common filessytems are only supported via l4linux, there is also an old ext2 package here in our local repository.
2. Is there a way to have RT access to disk and accessing files this way? If so, how?
You might want to read the paper http://os/drops/doc.html#rtss2003_das. We describe how realtime access to disks in general does work in DROPS, the work was focused on our real-time scsi disk driver. There is a simple real-time filesystem available in the package simplefs, which however is not yet in the remote cvs. Maybe Lars Reuther, the author of simplefs, can give more information. Please reply to l4-hackers, as I'm on vacation in the next two weeks. Regards, Martin
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...
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 :)
participants (3)
-
Martin Pohlack -
Rene Reusner -
Rene Wittmann