1. Home
  2. Embedded Programming
  3. Rate Monotonic Scheduling (RMS) vs. OS Scheduling

Rate Monotonic Scheduling (RMS) vs. OS Scheduling

Background: ========== The company I work for develop Carrier Ethernet Switch (both HW and SW). I am facing a major decision I have to take about using RMS (or anothe in house scheduler algorithm) or using the OS scheduling.

Requirements (the most relevant functional and non-functional requirements): =========================================================

  1. Support various networking protocols (IGMP, STP, PBB-TE, ....)
  2. High availability - achieved also by redundant HW.
  3. Predictability - I would like to have performance predictability prior to actual development.
  4. Performance - achieving high performance and low system resources usage.
  5. Usability - allowing distributed development around the world.
  6. Integration with 3rd party - allowing "buy" and easy integration with them.
  7. Portability - loose coupling with OS/HW.

Solution Alternatives: ================ The layered based with asynchronous messages between them. The "dynamic control" layer is responsible for handling protocols' control packets.

Alternative 1 - Rate Monotonic Scheduler (or other in-house scheduler): In the RMS concept there is a single task that schedules all protocols. Each protocol must not exceed limited time quota and must not perform any CPU blocking operation. Blocking operations should be performed by services tasks that serve all protocols.

Alternative 2 - OS Scheduling In this approach every protocol has task (or more than one - for example to support Pipes & Filtering). The scheduling between the protocols is done by the OS (with or without time slicing).

I would be happy to have comments/observations or some other alternatives.

Thanks, Ran

Reply to
ran.levy1
Loading thread data ...

Hi Ran ,

I would suggest an event driven scheduler driving a statemachine based psuedo task ( reactive tasks in the same context) By reactive I mean the tasks reacts to events ( messages , guard condition , fucntion calls) by transitioning to other states. This should provide for the requirement "Performance - achieving high performance and low system resources usage". Predictability can be tweak or improved by priorityed message queues for the scheduler.

A state chart based frame work should be easy to integrate with third part stuff and also can be run as a task in a RTOS.

What do you think?

Rate

Reply to
ratemonotonic

Cann't see your target OS specifications. Anyhow, i would prefer the first option as the layered approach is indeed a good development methodology. Not to mention that its easy to debug and maintain if project size grows over the time. Single process can handle all the protocol forwarding to its worker threads, and another worker thread acting like a scheduler can do the housekeeping for all the worker threads.

And just to contradict myself, second approach should be more mature but it depends what OS you will target. If you plan to use preemptive OS then you can't guarantee the behavior of scheduler anyway;)

ali

Reply to
Ali

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.