1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Rate Monotonic Scheduling (RMS) vs. OS Scheduling

Discussion in 'Embedded' started by ran.levy1, Jun 18, 2007.

  1. ran.levy1

    ran.levy1 Guest

    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
    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
    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

    Alternative 1 - Rate Monotonic Scheduler (or other in-house
    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

    ran.levy1, Jun 18, 2007
    1. Advertisements

  2. 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?

    ratemonotonic, Jun 18, 2007
    1. Advertisements

  3. ran.levy1

    Ali Guest

    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

    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, Jun 18, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.