Okay, so, we've seen a number of interesting examples here in our core first course intro to rate monotonic timing analysis using worst case analysis methods over the longest period based on the that if we can demonstrate feasibility over the longest period. The system is in fact feasible knowing that in fact, if we look over the LCM, then we have the full story on the scheduling. And so, the one last really interesting example for the introduction to worst case analysis, which will go deeper on in course two, if you take that second course with us in the series, is that it is in fact possible to have 100% utility above the LUB with the rate monotonic policy and have feasibility. So, zero margin feasible. Probably not safe in my engineering judgement opinion, not safe to have zero margin, but it is feasible. So, let's look at this. This is just more reinforcement that in fact, the RM LUB is not exact. It is sufficient, it's inexact, and it won't steer you wrong. So, it won't say service said is feasible that in fact is not, but it will say that service says, as we've already seen are infeasible that in fact are feasible. They're just low to zero margin, in fact. So in this case, we have now, a set of services. And we have a utility that's essentially 100%, right? Which is what we see. And just service 1 uses 50%, service 2 and 3 uses 25%. And service 3 uses 25% by using 4 units of time over a period of 16. These are in fact harmonic. We always check that with frequency, never with period. Don't fall for that trap. We see that all the frequencies are multiple of the fundamental here, which is 0.0625. So, in other words, the fundamental is the smallest frequency, and all the others are multiples of that. And that means, they're harmonic. So that means we could have feasibility above the LUB as we've seen before. But, this is the first case we've looked at where it's also 100% utility. So, how does that work? Well, we just do worst case analysis, we fill in s1 across the top. All the way, 50% out to the longest period and we have half of the CPU available left over. So, we fill in S2 in once. Just one unit of time every 4. So every 4, where there's an open window, we just take it. All right, monotonic policy. And in fact, that's going to be the second one over from where it's requested each time. Remember, all the services are assumed to be requests at the same time at the critical instant as was covered in the Liu and Layland paper. And now, we just, for S3. Take whatever is left over. Well, we have window 4, 8, 12 and 16, exactly. And we just barely make it here. [LAUGH] But we do make it, right? So, we get exactly what we need for S3, and we have at 100% utility, zero margin, four harmonic services, by rate monotonic policy. So, it is possible. Is it safe? Well, that's an engineering judgment call. I would say no. No margin is a bad thing. So, the question of how much margin do you need? Well, that's an engineering judgment call. The LUB actually is saying basically, it's saying, 78%. So, it's saying that you need essentially 22% CPU margin, and yet we see this is feasible with no margin. So, the LUB would be fine. It would say, don't do this. You need more margin. And but maybe that's, maybe this is a little too pessimistic, right? So the question is, is that too conservative or too pessimistic? And this is probably too optimistic, right? And this is probably might be a little pessimistic, so we might want something like a 10% margin requirement or something like that. So, that's something for you to ponder. We will talk more about worst case analysis and look at alternative methods. What the dynamic method that Liu and Layland called deadline driven scheduling, which we now today call earliest deadline first, which is available in Linux by the way and is a method we'll learn to analyze in course two. So, I'll leave you to think about that and whether this is safe or not. But we can see that it is, in fact feasible through analysis. And we'll conclude this type of analysis by introducing the Cheddar tool, which can do this, which automates this process for you. But it's my belief that learning how to diagram by hand is important first before going to the tool so that you can cross check the tool to make sure it's right, that it's working and so that you know how it's working. All right, so we'll pick up there with Cheddar after this. And that will complete our introduction to timing analysis which will do much more of if you take course two in this series. Thank you.