Another interesting case to consider when doing worst-case analysis, now that you know how to create your own timing diagrams using the method of worst-case analysis, as we said at least over the longest period, but ideally over the LCM of all the periods, you can compute the LCM fairly readily. Actually, Excel just has a method to do it where you can just say LCM and give the range of the periods. Obviously the least common multiple of all the periods, and we see that here it's equal to 15. I went ahead and used the Excel feature to do that. Normally it's pretty easy to do, unless you have a lot of different periods in their odd numbers and so forth. In this particular scenario, over the LCM of 15, I've got three services with periods 3, 5 and 15. At first, it turns out that they are harmonic and one pitfall you have to watch out for is don't assume their harmonic just because 15 is a multiple of 3 and 5, that is true here. But you should do is compute the frequencies as we have done over here and find the fundamental frequency, which here is basically 0.0667 and the S2 is three times at, and S1 is five times at fundamental frequency always check the frequencies. That's a little trap. A well-known real-time researcher, Bataso pointed that out that a lot of people assume it's harmonic because of the periods are multiples of each other. In this case true but not always true. I just want to point that out, could come up on a future quiz or exam and anyway, here there are harmonic and when we have harmonic services, we can successfully exceed the RM Beast Upper Bound. This is part of the inexactness of the rate monotonic least upper bound. Let's see how that occurs. We do worst-case analysis. In this case, we just fill in S1 right across the top and every major period of S1 here, which is three in this case. We filled out every three, we just take S1 right away because it's the highest priority and then S2 is going to use whatever's leftover. Remember we're just playing the role of the scheduler. S2 wants two units of time we see over here and it needs it every five. It's basically another 40 percent of the CPU on top and the 50 percent. We're already at 90 percent well above the lub and we see that in fact, because S1 is every three units of time, we can fulfill S2 completely on its first requests. Then the second request we can fulfill part of its need, and then it gets preempted by S7. There's a preempt here. I always like to point those out and then it completes on the other side of S1s use and it's fine and in fact, the next time we can completely fill it in there and everything is good with S1 and S2. Pour S3 has to take whatever's left over in that case and try to complete its need for CPU of three over a period of 15 and we can take a unit of time there. We can take it unit of time here at Window 9 and we can take our final Window time here out at 14, leaving one final window of slack, so 1 out of 15 and 1 over 15 better equal our slack of 6.67 and in fact it does. We won't get out the calculator this time, trust me, but verify and we see that in fact, this schedule works as determined by worst-case analysis, by essentially by inspection, by playing the role of the scheduler worst-case analysis is exact. The main theorem we lean upon is the hachi sounding, which says if we go over the longest period, that is sufficient to determine whether this schedule will be feasible for all time and I'll add in that. It also has the LCM, as is the case here. Then we understand that this will just the schedule just repeat indefinitely now and this is an example above the lub. Harmonic services is one of the cases where a success be feasible above the lub. Remember the lub didn't really do us any harm here it just said you can't do this when in fact we can. But we don't have very much margin here, that's something to keep in mind. When the lub says no, it's always basically taking the position of safety, very often when we're above the lub and feasible, we are also low margin. You have to do worst-case analysis to determine exactly what margin you actually have and whether this is safe or not is an engineering judgment call. If you're judgment was I want 10 percent margin or more than we might declare this unsafe, but it is feasible, it can execute and it does have some slack. I'll leave you to ponder that. Here's another example, interesting because it's above the least upper bound. It is feasible. But whether it's safe or not is in engineering judgment call that you need to make. Thank you very much.
