• AVR Freaks

Questions Regarding Multi-Tasking Implementation

Author
aboehler
New Member
  • Total Posts : 13
  • Reward points : 0
  • Joined: 2014/07/23 19:17:15
  • Location: Tempe, AZ
  • Status: offline
2014/07/23 19:28:25 (permalink)
0

Questions Regarding Multi-Tasking Implementation

Dear Lubin,
 
The model I’m working on used to run with your previous blockset in both, single tasking and multi-tasking modes. After updating to the new blockset the model runs normally in single tasking mode. However, when using multi-tasking at least my two slowest tasks seem to be getting delayed.
 
When looking at the generated C code and comparing with the code produced by the previous blockset I noticed the following (please correct me if I’m wrong): In the new blockset, if there is an overrun of a sub-rate it is skipped but if there is an overrun of the main rate MissedSteps is incremented and the missed step will be delayed and executed later. This is different from your previous blockset where in any case of an overrun the corresponding step execution was skipped. I’m assuming that delaying the main rate (and with it all the sub-rates) in the new blockset is causing the behavior I’m seeing.
 
Is it ok for me to keep using Single Tasking for now (because it appears to work) or do you think this points towards a bigger issue with my code? Could it be I’m completely overloading the CPU?
 
What I don’t understand is this: It appears the only way how the main task gets delayed is if the timer 1 interrupt is entered again while I’m already executing the main task. This would mean though that my main task is so big that I can’t even finish the main task within the allowed time, let alone work on the sub-rates. However, the total amount of work to be done when in Single Tasking mode, should be similar as in Multi-Tasking, so how come in Single Tasking everything works? Moreover, when I’m logging data in Single Tasking mode, the CPU load is 38% max – note that it is recorded only @100Hz not @1000Hz rate. Still I would expect it to be much higher, given that I cannot even finish the main task, which runs during every step.
 
Sorry for the long post and all the questions. Any insight you could give me would be very much appreciated!
 
Also if other people have run into similar situations or have any ideas/suggestions please feel free to reply!
 
Thank you very much for your help!
 
Alex
#1

4 Replies Related Threads

    Lubin
    Moderator
    • Total Posts : 370
    • Reward points : 5
    • Joined: 2007/03/31 07:38:15
    • Location: Bayonne, France
    • Status: offline
    Re: Questions Regarding Multi-Tasking Implementation 2014/08/20 07:56:14 (permalink)
    0
    Hello Alex,
     
    My apologize for such delay.
     I will only provide the first inputs and I hope to complete later with graphs.
     
    The blockset implement a rate-monotonic scheduler (Higher rate have higher priority) that cope with MathWorks description. You might Mathworks description here.
      
    User should take care that no mcu overload occurs. For completeness only, the behavior of the blockset in case of overload is mentioned below (It’s same behavior described by Alex)
     
    For a Multirate (mixed-rate) model, the blockset will implement a MultiTasking scheduler except if user explicitly defines in the Solver pane of the Configuration Parameters dialog to “SingleTasking” instead of “Auto” (default).
     
    Only Multirate model are considered here.

    SingleTasking Scheduler:

    In a multirate model implemented with a SingleTasking Scheduler (Not the default), subrate tasks MUST run in between the higher rate tasks. Let’s define a model with:
    • Task A @1000kHz (0.001s) ; Task A executes in 0.0006s +- epsilon.
    • Task B @ 200Hz (0.005s) ; Task B executes in 0.0007s +- epsilon.
    This model violates real-time constraint: Task A executes 5 times, then Task B execute once just after the Fifth execution of Task A. Time to execute Task A + Task B is 0.0006 + 0.0007 = 0.0013s. The next Task A will be delayed by 0.0003s.
    The task B should be split into 2 or more subtasks, executed in less than 0.0004s.
     
    Tip: The block sample time input can be a vector with two element where the 2nd element is the sample time offset: Setting
    • for blocks “B1” a sample time of [0.005 0] and
    • for blocks “B2” a sample time of [0.005 .001]
    will create two tasks B1 and B2 running at 200Hz but that will execute on two consecutive timeslot (not on the same one).

    MCU load measurement:

    The new MCU Load block added with the v3.35 measure mcu run time from the previous start time of the group task executed with the block to the next one. Adding this block with a time step B2: [0.005 0.001] will cumulate mcu load for tasks: [{A + B2}  +  A + A + A + {A + B1} ]  and return result when next task B2 is executed.
    Warning: measuring the busy time pin set in the master block (using a Input Capture peripheral) will return the mcu load time for the previous step. Alex, this if for you 

    Overload:

    With SingleTasking scheduler, the execution (order) of tasks is deterministic, even in case of overload.
    When overload occurs, the idle time is suppressed until the mcu manage to run all steps not yet executed. When the number of missed steps for the main task (with faster rate) reach 65535, it wrap to 0.

    MultiTasking Scheduler:

    In a multirate model implemented with a MultiTasking Scheduler (default), subrate will execute in the idle time of hither rate tasks. i.e. Higher rate (tasks) preempt lower rate (task).
    If we take the same example with two sample rate (tasks) :
    Task A @1000kHz (0.001s) ; Task A executes in 0.0006s +- epsilon.
    Task B @ 200Hz (0.005s) ; Task B executes in 0.0007s +- epsilon.
    This model does not violate the real-time constraint: Task B start execution after 5 execution of task A. Next task A will preempt task B once provided its execution is not finished. 
     
    MultiTasking is the default mode for Multirate (mixed rate) model. It removes the constraint that lower task must execute between two higher tasks execution. It is thus possible to execute a complex calculation in a lower rate without jeopardizing the execution of higher rate tasks. (Updating your Kalman covariance matrix is thus possible at a lower rate while keeping the filtering running at a high rate)

    MCU load measurement:

    The MCU Load block (with v3.35) measure mcu run time from the previous start time of the task executed with the block to the next one. If we reuse the example with task A, B1 and B2: Adding this block with a time step B2: [0.005 0.001] will cumulate mcu load for tasks: [B2  +  A + A + A + {A + B1} + A ]  and return result when next task B2 is executed.

    Overload:

    With MultiTasking scheduler, the execution of tasks is not deterministic in case of overload:
    If an overload occurs while executing the higher rate (with our example: task A must execute while previous task A is not finished), the number of missed steps is stored (as with SingleTasking) and the MCU run until it reduced missed steps to 0.
    If an overload occurs in a subrate (lower priority task) : for example task B1 is not finished when next task B1 should start, then the second task B1 is simply dropped and will not be executed. Lower task will thus still be executed. However as stated first, USER is responsible that such overload never occurs.
     
    Alex, I tend to think that this might explain the slow down you mentioned when you run with a MultiTasking scheduler. Tip: It might be interesting to use the Time step offset to obtain a different behavior…
     
    #2
    aboehler
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2014/07/23 19:17:15
    • Location: Tempe, AZ
    • Status: offline
    Re: Questions Regarding Multi-Tasking Implementation 2014/09/08 19:10:54 (permalink)
    0
    Dear Lubin,
     
    Thank you for your detailed response. I have upgraded to the new blockset and used the MCU load block to look at the execution times of some of my tasks, it's very helpfull!
     
    I was also able to change the behavior of one of my models using the time step offset as you described, and that model does not appear to have any overloads anymore.
     
    Here is one concept I don't completely understand yet though:
     
    Assume I have the scenario you outlined above, i.e. a main rate task A @1kHz and a subrate task B @200Hz with the same execution times as above. I thought that in a multi-tasking system the task scheduler would split up my more complicated task B automatically. For example:
     
    Task Scheduling In Single Tasking:
     
    A&B - A - A - A - A - A&B - etc.
     
    In this case, like you said, the real-time execution is violated because it is required that task B finishes between two calls of task A.
     
    Task Scheduling In Multi-Tasking:
     
    A&(part of B) - A&(rest of B) - A - A - A - A&(part of B) - etc.
     
    In this case, I thought that the scheduler would automatically take care of re-allocating my large task B to several time slots. While B is running in the first step, the next execution of A would preempt B, i.e. B is stopped, all its data gets saved and A is executed again (context switch). However, in the second step, after A has finished and there is still something left to be done on B, B's data gets restored and B would resume automatically. It appears to me now that I'm essentially doing the scheduling by manually entering the offsets in MATLAB to create sub-tasks. Then, why would I not just stay with Single Tasking? Am I just understanding this wrong?
     
    Thanks very much,
     
    Alex
    #3
    Lubin
    Moderator
    • Total Posts : 370
    • Reward points : 5
    • Joined: 2007/03/31 07:38:15
    • Location: Bayonne, France
    • Status: offline
    Re: Questions Regarding Multi-Tasking Implementation 2014/09/10 15:14:10 (permalink)
    0
    Dear Alex,
     
    Thanks for your feedback. Still no illustration ;-(
    However as your post is all Ok, It seems less urgent to add illustrations…
     
    aboehler
     It appears to me now that I'm essentially doing the scheduling by manually entering the offsets in MATLAB to create sub-tasks. Then, why would I not just stay with Single Tasking? Am I just understanding this wrong?

     
    As you mentioned, it is possible to mimic Multi-Tasking with Single-Tasking scheduler by splitting and dispatching the task B so as it executes within several task A slots. If any piece of a sub task B takes more time than expected, then there is a high risk to delay the following task A and violate the real time execution of task A (because there is no preemption).
     
    "A&(part of B) - A&(rest of B) - A - A - A - A&(part of B) - etc."
     
    Here is some input re Multi-Tasking vs Single-Tasking:
     
    From a practical point of view, depending on your task B, it might be difficult (or impossible) to split it into several subtasks with the appropriate execution time. Thus, the Multi-Tasking scheduler is usually more convenient to use, as you do not have to do anything. Note that Multi-Rate is the default (for multi-rate model) thus most user might use it successfully without paying attention to these details.
     
    From an efficiency point of view, the multi-tasking implies context switching and data integrity mechanism for data transfer between rates. That would cost few mcu instruction and memory; however, this mode should also allow making a better use of the mcu bandwidth because you do not need to keep an idle « safe time » between each task…
     
    Single tasking has the advantage of execution determinism. This can be seen when a high rate task input is a result from a lower task rate. Determinism is possible with multi-tasking at the cost of a higher.
     
     
    You could stay with Single tasking, but I tend to think that it is easier to set and maintain a system with multi-tasking. The added cost (mcu load, and memory) for multi-tasking should be low enough to make it first choice.
     
    In your first post, you mentioned that the system behavior was not ok when you set a multi-tasking scheduler. This was probably due to real-time constraint violation and the consequence is that some tasks were dropped. If the same algorithm is being implemented with single tasking, I would bet that you will also have real-time violation, but as tasks will be not dropped but only delayed, the behavior might look more acceptable.
     
    Keep in mind however that Real-time constraints violation is theoretically prohibited ; Even if we protect the chip from crashing ;-) ...
     
    If any advanced option is required to add a different behavior when such violation occurs, please let us know.
     
    Lubin
    #4
    aboehler
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2014/07/23 19:17:15
    • Location: Tempe, AZ
    • Status: offline
    Re: Questions Regarding Multi-Tasking Implementation 2014/09/11 11:08:57 (permalink)
    0
    Dear Lubin,
     
    I completely agree with your above statements :) - In my case, Single Tasking simply produced seemingly more acceptable behavior.
     
    I guess what I don't understand yet is why your comment below does not appear to be true for my situation:
     
    Lubin
    From a practical point of view, depending on your task B, it might be difficult (or impossible) to split it into several subtasks with the appropriate execution time. Thus, the Multi-Tasking scheduler is usually more convenient to use, as you do not have to do anything. Note that Multi-Rate is the default (for multi-rate model) thus most user might use it successfully without paying attention to these details.

     
    Like you are saying, I would expect to have to use the Sample Time Offset feature in Single Tasking but I would expect to have to do nothing in Multi-Tasking. Obviously, my task B can be executed between two calls of B during the idle times of task A without leading to an overload. But why did I have to use the sample time offset to obtain this behavior and why is it not automatically happening in Multi-Tasking mode?
     
    Does what I'm asking make sense or am I just completely off here?
    #5
    Jump to:
    © 2019 APG vNext Commercial Version 4.5