It's Maxwell House the best coffee in the whole world. Well, your father says so, and your father knows best. Yes, it's Father Knows Best transcribed in Hollywood starring Robert Young as father. A half hour visit with your neighbors, the Anderson. Brought to you by Maxwell House, the coffee that's bought and enjoyed by more people than any other brand of coffee at any price. Maxwell House, always good to the last drop. June. It's a wonderful month, isn't it? Full of warm sunshine and clear blue skies and orange blossoms. We mustn't forget the orange blossoms. June is the month of brides, which brings us to Springfield and a white frame house on Maple Street. It was the Anderson, you may remember, who got a poor chap named Tom Goodwin to propose to Margaret's cousin Louise. As a result, the Anderson's are blessed with a wedding this coming Sunday. Ah, but it's a happy time, isn't it? Like this. $40 for chicken salad? Jim. There isn't that much chicken salad in the world. Jim, the children will hear you. Well, let them hear me. Let them hear me. Dear, I've told you a dozen times. I agreed to pay for Louise's wedding. I know that. But good grief, Margaret, $40 for chicken salad. Jim, we have to feed almost 80 people. 80 people? You mailed the invitations. You knew in the very beginning how many people were coming. I don't know. I agreed to pay for a simple little home wedding. No fuss, no bother, no... Betty! Betty! Will you please stop that horrible racket? Chop and cleaver. Got it so a man can't even think around here. People running in and out, telephones ringing, bills piling up. The bills don't make any sound. They don't, huh? Listen to this one. $12.36 for the rental of chairs. Why did we have to rent 75 chairs? Jim, they have to sit somewhere. We've got chairs. We've got all kinds of chairs. Father! We've got dining room chairs, living room chairs. Why do we have to pay $12.36 for chairs? Father, may I speak to you for a second about... Just a minute, dear. Jim, Mr. Abbey said I was very lucky to get 75 chairs. Oh, sure. He even gave me a special price. I noticed that. What's the 36 cents for? That's for tax. Good. I hope he puts one in the center of each chair. Jim, really? $40 for chicken salad. Now, Mother? Dear, this is a very bad time. But it's the last day if I don't ask him now. All right, dear, but don't stand too close. Margaret, the way you talk, you think I bit people. Don't you? I haven't bitten anyone in months. What is it, Betty? Father! No. Jim, you might at least let her ask. All right. What is it? May I buy a new pair of gold shoes? No. I let her ask. Now is everyone happy? But, Father... Your feet will be under the piano during the whole ceremony, and no one will see whether your shoes are new or old. But I'll get up later. No one will see them later, either. They'll be too busy eating chicken salad. We're in the din, bud. Flowers and candelabra. Look at this one. Bake goods. $27. That's for the wedding cake, dear, and 12 dozen rolls. 12 dozen? Hey, Mom, I found out before I can rent one for only $7.50. Why do we need 12 dozen rolls? Oh, Jim, when you have 80 people... That's 144 rolls. What are they gonna do with the rest of them? Throw them at the bride and groom? Oh, dear, I forgot to order rice. Father! That's pretty good. Isn't it, Mom, only $7.50? I can get silver shoes for 10 if that'll help any. Wait a minute, Betty. Bud. Yes, Dad? What can you get for only $7.50? A tuxedo. Joe Phillips knows the place. A tuxedo? Jim... Why does he need a tuxedo? He doesn't really, dear, but holy cow, Mom, you said I was gonna be the head usher. You can be a usher without a tuxedo. All you're going to do is hang up hats and coats. I have to show the people to their seats. Show them they'll be tripping over them. Haven't you heard? We're getting 75 extra chairs. Jim, really? We'll have so many seats, there won't be any room to stand up. I can wear them with practically anything, so it's really a good investment. Daddy! Honey, this is getting ridiculous. If I'd known you didn't want my cousin Louise to have a pleasant wedding... I want it to be pleasant for everybody, including me. Daddy! Kathy, will you stop shouting? What is it? Angel. There are 842 white ones and 738 blue ones. What is she talking about? The flower petals. How can I be a flower girl with only 412? Wait a minute. You counted the flower petals? Well, but that I had to! But! I didn't say she had to, Mom. I just said, well... Well, she was getting everybody's way, and I thought... Yes? I'm sorry, Kathy. For what? For making you count the flower petals. Oh, I didn't mind. People get married every day. Thousands and thousands of people. But if I don't get some pink flowers...  Oh, fine. Thank you, Daddy. All she has to do is open her mouth and she gets anything she wants. There he is. But if I want a pair of shoes... You don't need a pair of shoes. What are you beefing about?  But... But how would you feel if you had to go to a wedding and a pair of old shoes? I go everywhere in old shoes. I don't have anything but old shoes. But how would you like to be a head usher without a tuxedo? But the front door... But I have to tell Daddy... I'll get it, Margaret. I'll be glad to get as far away from these head ushers and flower girls as possible. Jim, if it's the florist, tell him to put the stands in the garage. Yes, dear. And I can use... Blue ones. Pink ones. Shoes. Tuxedos. The silliest thing I've ever heard in my life. Oh, hello.  Hello, Jim. Jim, we got the ring.  Isn't it, Tom? Oh, I wouldn't say that. I'm looking at the most beautiful thing I've ever seen. Tom. And just 24 hours from now, she'll be my wife. Forever and ever. Would you mind closing the door? You're letting the flies in. I'm sorry. Margaret, Louise and Tom are back. I'll be right in. Hi, Louise. Hello, dear. Everything sure is exciting, isn't it, Jim? Yes, very. Margaret, we got the ring. You didn't. You just said she did. Beautiful pebbles you've ever seen. Where is it, old Louise? You've got to let me see it. You say something around here, you get an argument. Show them the ring, dear. I'm trying to find it. Tom, you're not supposed to lose it until tomorrow. Oh, here it is. Let me see it. I want to see it, too. Louise, it's beautiful. Why don't you wait until you see it? Oh, it is, Louise. It's the most beautiful thing I've ever seen. Do you really think so? Oh, it's just a ring. Bud, come look at cousin Louise's ring. What for? Why, Bud? What difference does it make what I think about it? I'm only the head usher. What's the matter with him? He'll be all right. Everybody else can get what they need, but not me. I don't come. Oh, Bud, it can't be that bad. Oh, no. What kind of a head usher am I going to be without even a tuxedo? If he needs a tuxedo, what hasn't he got one? Now, wait a minute, Tom. You can rent one for only $7.50. You see? Tom, don't you think I ought to get a pair of gold shoes? Betty, you're not going to get gold shoes, so stop talking about it. But Tom said... I don't care what Tom said. Margaret, I told you we should have had just a small, quiet wedding. I know, dear, but... Wait a minute. You know, this is my wedding, too, and I don't like small weddings. Tom... After all, how many times do you think I'm going to get married? Tom, a small wedding is every bit as legal. I know that, but... I think Jim is absolutely right. Now, wait a minute, Louise. We've been all through this, and you agreed... I agreed to marry you, but I didn't agree to become part of a Roman circus. Louise, if you'll only listen... All this fuss and bothering for absolutely no reason. What do you mean, absolutely no reason? Tom, there's no sense arguing about it. After all... I think it's ridiculous to go to all this expanse. Louise, it isn't anything. Really, it isn't. You mean I can get a tuxedo? I always said that if I got married... If you got married... He means when he got married. Don't you, Tom? I want to know I've been married. I want music and flowers and excitement and everything. Otherwise, what's the sense of getting married? Tom... I think you and I had better have a little talk. Louise... About what? About a lot of things. Look, kids, there isn't any sense to this. There really isn't. You're both excited and upset. Well, Tom... Go ahead. Talk. I'm listening. Margaret, will you excuse us for a moment? Of course, dear. Why don't you and Tom go into the den? Well, we'll only be a minute. Are you coming, Tom? I'm sorry, folks. She gets all upset like this, but it blows over in two seconds. We'll be right back. Gosh! I'm not going to get a tuxedo, huh? Not a look, bud. Jim, I hope you're very happy. I've told you a hundred times. What? This whole thing is your fault. My fault? Margaret...  Honey... It's bad luck for the groom to see the bride before the wedding and you know it. I know he's saving $6 a day by sleeping with bud, and if that's bad luck... It's not a question of money. Of course not. What's the money to this family? If we run out, we just go down to the basement and print a new batch. We do? Kathy, be quiet. But Daddy said they're coming back. Oh. The florist suggested smile acts, but I thought a white background would be so much better. Don't you, Jim? Hmm? Oh, yes, definitely. Well, dear, is everything settled? Yes. Quite settled. Well, what kind of a wedding are you going to have, large or small? We're not going to be married at all! Well, women in their ways can be pretty much of a mystery to any man, especially when it comes to weddings and fathers, no exception. But there are many things the head of the house just naturally knows most about. And truly good coffee is one of them. Fact is, your husband is the world's greatest coffee expert. Now, we're often called experts too since more families buy our Maxwell House coffee than any other brand. But when you make coffee for your family's pleasure and enjoyment, the judge you want to please is your husband. And tomorrow, if you'll fill his cup with the rich, completely satisfying goodness of our Maxwell House coffee, we promise he'll beam with delight and say, gee, that's grand coffee. We're sure he'll say that. In fact, we'll return your money if he doesn't.  In all the world, there's only one recipe for that famous good to the last drop flavor, a recipe demanding choice, extra flavor coffees, blended and roasted just so. And only Maxwell House has this recipe. So take home a pound of our coffee. Serve your husband Maxwell House. If he doesn't say best coffee ever, why just send us the can and unused portion and we'll gladly refund your money. Our address is right on every familiar blue tin. Yes, tomorrow please the world's greatest coffee expert, your husband, with the truly fine flavor of Maxwell House coffee. Always good to the last drop. A few unhappy hours have passed and the great romance of the century is still colder than an umpire's heart. Tom is in Bud's room packing. Louise is in Betty's room packing. But the Andersons haven't given up. With $40 worth of chicken salad and the ice box, they'll bite it out if it takes all summer. Like this. Louise. Margaret, there isn't any point in discussing it. I just won't marry him.  I'll get it. Darling, you and Tom have been friends for so many years.   What difference does it make whether it's a large wedding or a small one? It doesn't make any difference. Then why is everybody all upset? Mother! What is it, Betty? Just a minute here. Louise. I won't marry you, Margaret, and that's final. Oh, dear. Louise, I mailed invitations to almost 80 people. I'm sorry, Jim, but I won't do it. Well, I've done everything I could. Tell Mr. Abbey we're sure, Betty. Knead them, dear. Look, Lou. Jim, if Tom and I disagree this violently in the very beginning, what's going to happen next year and the year after? Louise, you don't fall into a successful marriage. You make a successful marriage. He's right, dear.  You've got your own ideas, your own way of doing things. You've got to compromise, learn to adjust your lives to suit one another. It won't work any other way. Well, how about love? Doesn't that enter into it? Of course it does. Love is the only thing that makes it possible. Mom, we're in here, bud. What did the florist say? He said he's going to have to keep the deposit because he already ordered all the flowers. Oh, I'm sorry, Margaret. That's all right, dear. I just hate to see the whole thing. You want me for anything else? You'd better hang around, bud. Something might come up. Okay. I'll be downstairs if you need me. Louise, maybe if I talk to Tom again... I'd rob you wouldn't, Jim, really. Well, it's your funeral. I mean wedding, I suppose. Darling, there's no sense in you being so gloomy. I'll go back to Middletown and we'll forget the whole thing, won't we? Will we?  He's only teasing, dear. Have you seen that chicken salad? We'll be eating it for three years. Mommy! Dr. Swain. Oh, dear, I forgot to cancel the minister. Tell him we'll be right down, kitten. Okay. Louise, Dr. Swain's here for the rehearsal. I know what to do. What am I going to do? Just tell him that it's all off. This won't be the first time. Louise, you understand my position, don't you? What position? They're not going to be married, so why have a rehearsal? Jim, please. Darling, would you and Tom go through the rehearsal for my sake? Honey. Just the rehearsal. Then I can explain to Dr. Swain later. Margaret, why don't you just tell him... Will you, dear? It saved me a great deal of embarrassment. Well, if you put it that way...  Jim and I'll go in and speak to Tom. Margaret. Come along, dear. But what's the use of... Come along, dear. I don't know. I'll be down in two minutes. That'll be fine. Jim, I could strangle you. Me? What did I do now?  Dr. Swain is our last chance. For what? There isn't going to be a wedding. There might be a wedding, believe me. I'll go downstairs and get everything ready for the rehearsal. I thought we were going to speak to Tom. I'll speak to Tom. Now, would you please do as I ask? You wouldn't like to explain anything to me, would you? I'll explain the whole thing later. Jim, please go downstairs. Okay. I don't know why, but I'll do it. That's the trouble with women. They always explain everything later. Perfectly simple solution to the whole thing. Tell Dr. Swain there isn't going to be any wedding and stop wasting his time. But not my wife. She has to be fancy about it. Hello, Dr. Swain. Mr. Anderson, this is a happy occasion, isn't it? Oh, yes. It's practically hysterical. I beg your pardon?  Well, you've got the children all set, haven't you? Oh, yes, indeed. We're on an old hand at this sort of thing, you know. Father? Just play the piano, Betty. Your mother will explain the whole thing to us later. Jumping creepers. Daddy, is it all right if I throw the flowers? Sure.  Are you sure everything is all right? Oh, don't mind Daddy, Dr. Swain. He makes jokes like that all the time. I'm a very funny fellow. I see. What does an usher do at a rehearsal? He ushers. Good evening, doctor. Mrs. Anderson, my how happy you must be. And this, I presume, is the unfortunate young man? Yes, this is Tom Goodwin. Hello, Dr. Swain. He lives in the YMCA. Kathy. Doesn't he? Not for long, I'll wager. Hey, Mr. Goodwin. Well, you can never be too sure. Yes, I have. What was that? He said to be sure, Dr. Swain. It sounded like a... Oh, well, no matter. Ah, here we are. Louis. I'm sorry if I held everything up. Dr. Swain, this is my cousin, Louise Baker. Charming. Perfectly charming.  Well, I wouldn't make book on it if I were... Sorry, doctor. Yes, well, shall we begin? I think that's a very good idea. I think... Not now, dear. How shall we start, Dr. Swain? Well, now it's very simple, really. Mr. Goodwin, you will stand here. All right, doctor. Now, girl, here. All right, doctor. Now, she will play the wedding march. All right, doctor. The meet from Nirvana here. All right, doctor. And the best man here. I've got a lady in the balcony, doctor. Jim! Now, the bride. My... that is a problem, isn't it? What do you mean? Well, now, someone has to stand in for the bride. It's very bad luck if she does it herself. I know, doctor, but there's no one left. Well, I see someone we can use. Oh, no. Come along, bud. Mom, I can't be the bride, please. Dear, no one will ever know. I don't want to be the bride. I just want to be a nusher. But stop arguing and be the bride. Louise, please. But will you stop acting like an infant? I didn't want to... I told him I was... Holy cow. Well, now we're ready. I wish I was dead. All right, bud, stand in the archway. Mom, how can you do this to me? Anytime you're ready, bet him. Okay, I mean, yes, doctor. Splendid. Now, the flower girl and the bride come along, children.  I have to use them again tomorrow. Kathy, so help me if you tell one person.  My own family. There we are, that's fine. All right, Betty. Now, the bride stand here, the groom here and I here. Are you watching, Miss Baker? Yes, I'm watching. Splendid. Dearly beloved, we are gathered together. Well, we'll skip down to... If any man can show just cause why they may not lawfully be joined together, let him now speak, or else he'll, after forever, hold his peace. I presume no one will speak. That's a little joke of mine. Very good, too. Now, I said, Thomas could win. Will thou have this woman to thy wedded wife? Dad, please. But will you be quiet? Get honest, I can. But really? I don't want to get married, I'm too young. Oh, but you poor angel. Louise. Never mind, dear. I'll take your place. Go ahead, doctor. Well, if you aren't worried. No, we'll be all right. I certainly hope so. Very well. All right, Betty. Thomas Goodwin, will you come to thy wedded wife? To live together after God's ordinance in the holiest state of matrimony? Will thou love her, comfort her, honour her and keep her in sickness and in health? And forsaking all others? Keep thee only unto her so long as he both shall live? Louise. Oh, Tom. Mr. Goodwin, you say, I will. I'm more certainly well. Louise Baker, will thou have this man to thy wedded husband who live together after God's ordinance in the holiest state of matrimony? I finally got it. Congratulations. I, uh, got a new job for you. Oh. How would you like to replace General Eisenhower? Make me an offer. I will. When it comes to coffee, your best value is always the brand with the most in flavour for your money.  And it's flavour that has made Maxwell House Coffee America's favourite brand and today's best coffee buy. So take home a pound of Maxwell House and serve that wonderfully full-bodied flavour to the world's greatest coffee expert, your husband. When he smiles at you and says, best coffee ever, you'll know Maxwell House has the flavour. Then just count all the really good cups you get from each pound. You'll be convinced it's Maxwell House for value too. This weekend then look for the sign of good coffee, the big white cup and drop on the familiar blue tin. That's Maxwell House Coffee always good to the last drop. It's Sunday now and the word can describe conditions in the Anderson household. The Anderson's are in a tizzy like this. But you've got to give me the chairs, Mr. Abbey. We ordered them. I'll get it. I know we cancelled the order, but I'll give you three times. But Mr. Abbey, okay, stubborn old character. What did he say, Jim? They don't have any chairs. I'll give you two dozen rolls if that'll help any. Daddy! What does Betty mean she can't find Louise? I don't know, that's what she says. Betty! For us, who's it from? Wait until I get it open, Margaret, and we'll all know. Do you want Mrs. Davis to bait the roll? In just a moment, bud. No! Jim, what is it? It's from Tom. They've eloped. Oh, they can't, but they did. Holy cow. No rolls. No bride and groom. That's the worst part. Father, who will all... Margaret, if I ever get into a mess like this again, so help me. Hello. Oh, hello, Miss Thomas. We're going through a... You what? In the file. Oh, Miss Thomas, you're... Thank you very much. Goodbye, Miss Thomas. Oh, honey. Oh, Jim, what is it? I forgot to mail the invitations. Folks, Gainsey, the famous talking dog always says... Gain's meal. What about Gain's meal, Gainsey? Nourish is every inch of a dog. It sure does. Penel and laboratory tests prove Gain's meal supplies balanced nourishment your dog needs for good health. Yet gains cost less to feed than a type of dog food. So folks, get Gain's meal. America's largest selling dog food. Join us again next week when we'll be back with Father Knows Best, starring Robert Young as Jim Anderson with Roy Bargy in the Maxwell House Orchestra. In our cast, where Ted Donaldson is bud, June Whitley, Rhoda Williams, Norma Jean Dillson, Isabelle Joule, Olin Suley, Jack Carroll, and yours truly, Bill Foreman. So until next Thursday, good night and good luck from the makers of Maxwell House, America's favorite brand of coffee. Always good to the last drop. Father Knows Best was transcribed in Hollywood and written by Ed James. Now stay tuned in for Dragnet which follows immediately over most of these stations. Dragnet, the story of your police force, is next on NBC.


My name is Malton Rasmussen. I work for ARM. I suggested this powerware scheduling boss session hoping to meet some people that are interested in this topic and have some useful discussions. I hope this will be very interactive so and because it's all recorded please use the microphone when you ask questions. Actually it would be better if you set closer up here so we could have some some interaction. So please move forward if if you want to participate in the discussion. I'm not sure what what the audience here today is really. I have some slides I can talk about what we are what we have been working on why we're trying to push this powerware scheduling idea give you an overview of what we've been working on what have been discussed at a workshop at Colonel Summit on Wednesday. But really I want to hear what your interest is in this topic as well and and how you deal with power management on your systems. If any of you are developers working on specific applications on specific systems what what challenges are you facing. How do you figure out when is my system tuned well enough or what's important for you. Is it tuning CPU Frank is a tuning CPU idle because we we are discussing various ways of actually changing these things. So it would be very useful to have your feedback for for these changes. So powerware scheduling is not just about the schedule. It's about the schedule and all the power management frameworks that we have in the Colonel today. Most permanently we have CPU Frank and CPU idle. These two frameworks both have drivers and governors that sort of try to implement some some power management policy pick the best C state pick the base best P state. But as it is right now they're actually completely uncoordinated and they don't get any information or they don't give any information back to the scheduler. So we sort of have the scheduler doing something places task running on one CPU on other CPU. And then depending on what the scheduler did CPU idle tries to do the best thing with whatever the scheduler decided just before. This is not ideal. We could do much better if the scheduler actually knew about what are what are our idle states what's actually the cost of waking up this CPU compared to this CPU. Because if you have on our systems we have typically various couple piece that is sorry C states and it might be very expensive to pick one CPU over the other even mean powering up an extra set of CPUs. So there is a good potential there for actually improving things by by making the CPU idle CPU Frank and the frameworks talk to the scheduler. So this is really what what power scheduling is all about. I tried to depict here roughly how the the the different power management policies are playing together today. We have the the scheduler it decides the load balancing it decides decides which CPU to wake up if we need another one. But it doesn't really know anything about C state or P states. That's something that happened sort of by the side and we can actually have some some really bad side effects by not having this coordinated. For example if your CPU Frank governor is too slow to react to the load of the CPU the scheduler might actually see that a CPU is becoming overloaded and start moving tasks away. But the reason why it's being overloaded is because it's running at a too low frequency and CPU Frank just haven't ramped up yet. So this is a clearly a problem. So we need to fix that this we need to coordinate things. And this is what this work is all about. So yeah some of the issues that we're seeing right now is this scheduler CPU Frank scheduler feedback loop which is not there at the moment. Which means that if CPU Frank is too slow the scheduler might do some suboptimal choices. Other things that we need to save power is another thing called task packing. At the moment what we're seeing is if you have sort of a lighter load scenario where you have we see it on Android for example where we have things waking up in the background if you're just doing nothing real just look at your home screen or something. As it is right now the scheduler doesn't really care where things are waking up. So you might wake up different to be used at different times which is clearly not ideal from from an idol perspective because it keeps CPUs in more shallow sea states than are really necessary. So what we're working on is actually trying to figure out when can we pack all these tasks to actually run on just one CPU and that will be the one waking up all the time and then leaving the rest of them in deeper sea states and therefore save power. These are just some of the things we need to just add topology awareness into the scheduler so it makes better choices and that was really what was discussed on Wednesday in the workshop at Kernel Summit. Another thing which is really important for ARM is we need some support in there for our big little architecture which adds another dimension of complexity to this problem. But it's all a part of the same solution. We can't really take out one problem and just work on that. We need to consider the whole thing. So there are some things that we wish would be there in the scheduler. I don't know if you're familiar with all how things have been developing in the scheduler recently but in 311 there was added a different way of estimating how tasks, the weight of tasks inside the scheduler. In the past they were just assigned a static weight. So no matter how much or how little a task was running it had sort of the same weight in the load balance calculations. That was changed. So now the load of a task is actually based on the history of execution of that task. That is good but that history is affected by CPU frag because the way the history is constructed is that it's based on the time that the task was actually running in the past. And if you lower your frequency it means that your task is running more and it will appear to be bigger. So here you have this feedback thing again that needs to be sorted out. So clearly there needs to be some integration between the scheduler and CPU frag. Yeah. And in general we need to apology awareness and there are other things we want to address as well. There are lots of things we want to integrate into the solution. That's the thermal and power budget awareness. On some systems we see that we have a fixed power budget and we can't just run everything at the same time. And that's not just CPUs we're talking about here. It can also be GPUs or the subsystems. Things that I'm not taking care of at all at the moment. But things we want to address going forward. So yeah I've tried to illustrate here what we have in the scheduler at the moment and some blue boxes showing what we would like to have in there. So we want to extend the SPOF to be more aware of theほしずつ witch. And when we get to that point, we need to do it. And we need extra features and load packing algorithms. We need scale-in variants. We don't have the have a patch set yet that does all of this. There's been proposed a number of different solutions over the last year or so, packing, integrating different things, but they don't really fit together as it is right now. So we need to work together and figure out how is this all going to work to create the solution. So the outcome of the Kernel Summit workshop that we had on Wednesday is that there was a broad agreement that we need to move the power awareness into the scheduler. We can't let it sit outside because it will be very hard to define. If we were to let CBU Frank and CBU Alexist as they are today, we would need to define interfaces between the CBU Frank governor and the scheduler and it will be very hard to define the proper interface there. So the proposal is move that functionality into the scheduler. And actually one of the first steps that we might look at is actually moving CBU idle into the scheduler and maybe completely get rid of the governor concept because if we're in the scheduler, we'll have much better information about what's going to happen and that may completely eliminate reason for having governors. If the scheduler is just the best place to have it, then just let that drive idle state selection. So that's one of the things that will be worked on. Pretty much everyone agreed that CBU Frank is not fit for its purpose if we want to drive it from the scheduler. One of the problems we have with the CBU Frank framework as it is today is that drivers are actually allowed to sleep.  So it doesn't work as it is. We need something else. And on some platforms, changing frequency is actually not that complicated. If you take Intel, for example, it's just writing a register and that's it. That's easy to do from a scheduler context. And if we do it from the scheduler, we can change the frequency based on what we know is being scheduled. We don't have to wait until the load goes up and the CBU Frank driver recognizes that, oh, there's something running now. I should ramp up the frequency. If we do it from the scheduler, we can ask for frequency change at the same moment as we're scheduling a task, which we know based on its load history is a big task that will need the frequency to go up. To make energy aware decisions, we need to put more information into the scheduler about how does this platform actually work? What sort of energy can I save if I wake up this CPU compared to this CPU? So that was also one of the outcomes of the workshop that was we need some way of telling this scheduler what is the energy trade-off of ramping up the frequency on this CPU compared to waking up another one and putting tasks on that. Because, for example, the task packing I was talking about before is not so much about just packing tasks until the CPU is full because does that mean you should pack it until it reaches its maximum frequency and then when you have sort of overloaded the CPU at that frequency, then you should spell on to the next one. That might not be the most power efficient way of doing things. It might be going maybe 50% or 80% up because then the last frequencies you ramp up your voltage so much that's getting too expensive in terms of energy. So if you have a number of tasks running at the same deep CPU, you might be better off by just splashing them on to the next one so you can run two CPUs but at a lower frequency. Those things, the scheduler doesn't know anything about today and we need some weight or some information in there to let the scheduler make better decisions. Another thing that was discussed a lot was benchmarks, power benchmarks. How do we actually evaluate whether the changes we're proposing are actually doing anything good? The patches that have been proposed so far, some of them have come with a few numbers and a few simple workloads on one specific platform and some improvement but really we need to figure out how to actually measure that the patches we're proposing are actually doing something good in sort of the broader sense. We don't have as it is today a benchmark suite of power benchmarks where we can say okay we can run all of these and we see improvements across most of them and therefore we should have these patches in. That is completely missing right now. It's not an easy task because what is the power benchmark? How do we measure if we actually get what we want? It's fairly easy for performance. You just run it and you measure the execution time, your throughput, whatever but for power it's not just about using the least possible power because it's fairly easy to save a lot of power on your phone for example. You can just turn it off then you save a lot of power. It's really a trade-off. We need to find the right spot between performance and power. Maybe you're fine with giving away 10% of your performance if you can save 25% of your power but clearly you're not willing to give away 90% of your performance to save a lot of power. It's not even that. For some workloads we don't really care about performance. Well, we do. For example, video playback. As long as we get every frame, no frames that drop, we're actually fine. So maybe the metric for a power benchmark is actually user experience in some cases but that's really, really hard to measure and it's really hard to come up with a user experience score that will apply to all use cases that you can think of. That's actually one of the things where I think it would be nice to get some feedback from you. How do you actually tune your systems? If you have an application, when do you decide that now I have saved enough power and when do I get enough performance? Are you just monitoring your frame rate for video playback or how does it actually work for you? Is there anyone? Okay, so you're saying that your way of doing is that you have a power budget and you just do whatever it takes to meet that power budget but how did you come up with the power budget to start with? Okay, maybe we should pause around. This is working? Yes. Maybe we should pause around the microphone. Yes, so my point was that when I used to work for TI, the methodology was to define power targets or power budget and thermal budget as well in the early phase of the chip development and then with this model that would produce a power target and a power budget and then once we got the software running, we would compare the measurements with those budgets and try to reach the budgets and iterate or eventually reassess the model because usually that was based on assumptions so some of the assumptions was not fully agreed and so this iteration was used to converge towards some supposed optimized power consumption for a given use case. Okay. And so the other part of the answer was that we had no specific methodology to say that, to tell us that yes, you didn't degrade the user experience. That was the next issue, not issue but unresolved completely issue like what can we monitor to say that those power optimization, usually when you do power optimization, you somehow degrade the performance by entering more low power states, running CPU lower, et cetera, et cetera, introducing more latencies in the system. And so we wanted to make sure that the user, the final user, so we were working on mobile phones, so we wanted to make sure that the experience wasn't degraded. So in the case of video playback, we were making sure the framework was fine. We were making sure that there was no buffer on the floor, for instance. So we were monitoring the video buffers and making sure there was no underflow. Without any underflow, we could say, okay, there is no degradation. The jitter also, we would measure it, make sure there is no jittering on the screen, things like this. For audio playback, for instance, we were making sure there were no glitches. You couldn't hear any glitch. But there is no formal yet. I agree with you. There is no formal methodology to a power benchmark. It's very nice to say it this way. There was no power benchmark saying, yes, this one, you're good. No, okay. You said, okay, we will give you a discount on our technology for one sensor, a mobile phone.  And then we know that your scheduling is doing something better. So it's very nice. So using the mobile phone on the market to measure the, because it's at the end, I know the problematic area. But then the user experience of the data collected by the real devices, because they use, they can play video, sometimes they can listen to the music, they can do everything. So I think that user experience, so coordination between manufacture and user mobile phone and arm or Intel company will be the best to prove to give a proof of concept or your scheduling algorithm for power aware, because, and this is very fast, because you can collect every information you want from video sub system to audio sub system to everything. And you know exactly what the task do, what the standard use case on the end user, because yeah, right now you don't know. So basically silicon vendor or end user vendor, like mobile phone vendor, can you give you an idea what is the use case, the typical use case. And in this use case, you can balance your, you can have an idea what is the good benchmark to test your algorithmics. So there are some of what you had the script like balancing is nothing to prove in that one. If the frequency scaling change the balance of the task, these need to be fixed because this is a problem scene. So it's not related to power aware, it's related that it's wrong, the calculation is wrong. So you need to account the right, you need to give the right way to the task. But for me, because I work a lot on this and what I think is, and only the end user can give a proof of concept of what you are doing. And now the only way for me it's let the end user to test the algorithmics. And if you are in the position to say, okay, we can give you the possibility to experiment our algorithmics in some way. So mobile phone is a good way to do that.  I see a point, but if we need to give away our code or distribute it on device before we can actually get feedback about how it works, it's sort of a bit latest that you okay, but you will never know exactly how it's running. So this is a good way to balance in real time your algorithm and have more and more informations. So if there is one million dot alpha activation a day of Android and a potentially 800 million than the user, you know, it's better than do they write your algorithmics without having any feedback. So you need at least collected information about the use case by by the end user. So not give not only put the algorithm in the mobile phone, but at least have an idea of what is the power consumption, how they use the mobile phone to simulate know the algorithm using a real use case. Yes. Well, one of the things that came up at the current summit discussions was that they basically wanted a set of benchmarks that we can run when we have the patch to see if it actually does good or bad things. And waiting until it's in the product and then getting the feedback is this maybe well, it's definitely useful to have, but we need a filter before that to pick which patches are the best ones. I believe. Yeah, there's question behind you. I think it's simpler than that. And in the case of say 3D video, there's really two targets, which I think have any real worth. One is if you're playing something like video or just a user interface that's drawing things on the screen. You want it to hit a certain frame rate so it looks smooth. And that's all that really matters. So just the minimum number of cycles to hit that frame rate is all you need to account for. The other target would be latency. So if you're playing a game, latency is king. And all you need to do is drive for lowest latency, which is going to use probably more power. As long as the benchmark is taking to account both cases, and you have a figure of both, it's really up to the user to decide which particular, you know, option they want to choose to play a game. They probably want to switch into low latency mode. But of course, right now, video is not done a lot by the CPU. So I understand that the video could be a good, but 10 years ago now, if you do a video, the 70% of the encoding of the video is done by other parts of the COC system. So even in the video, the problem is that in the real case, I show you an example, very simple. Suppose that you optimize the power consumption of the system by phone, and the user is very happy. Then suddenly arrive a mobile phone call, then the CPU needs to wake up in some way, but you need very fast feedback to the end user because for the end user, it's very important that the ring come and not the weight or delay by the running video. So this is the reason that I said that the use case, user experience is very different for everything that you think in your lab or in your room. So this is the typical example where collecting data from the device on the field is very important to understand what the real use scenario. So I think that the power we're scheduling need to be very simple. So you can collect every data, very nice things, and do the better calculation inside the scheduler. But this is a very basic calculation because you end up to spend power to understand how to not spend power. So if you need to take the decision in a slack of 10 milliseconds and you spend 80 milliseconds to take this decision, you lose the slack. So my approach is very more do it simple, like what you described like calculate the right balance of the task. This can be done in a simple way. So do a lot of things simple and let the high level frameworks to decide some power, high level power scheduling decision, and not let all to the kernel. So this is my idea on what would be power aware. So doing the decision but quick, even not optimal but quick, as quick as possible, to not spend time in the decision. Yes. There's a question behind you. I think I agree in that point that it needs to do simple and quick decisions. And maybe just very primitive support for power benchmark is needed in the kernel. Because if you look at power consumption, for example, for a smartphone and CPU, it takes very tiny part of it. And you need to look at the screen, Bluetooth, and so many other peripherals as well. In order to make that kind of decision, I don't know if it's suitable to do that in the kernel, actually. So to start with, like the last bullet there, to define use cases, that's very good to start with and to have some primitive support first. Yes, I fully agree. I think only the kernel really has the knowledge of what power domains are where. I don't think anywhere else really has the information needed to do scheduling on that sort of basis. It would be really nice if the kernel could sort of wake up three or four tasks in a row that all want to access the same peripheral so that it can wake up, do three or four tasks, and then just go to sleep again rather than be woken up constantly. There's another question. I just have an idea very personally, because as we mentioned, the power consumptions. But first I think the user case is very important for this scheduling. Suppose if somebody just uses a mobile phone, it could just recognize such like if they have some scenarios to check the new email periodically. If that case is very, very surely, that means it would use some very lower consumption cores in design phase, it's OK. And if someone is just to do in the very high-experienced games, so it's just a user very high performance cores. So I think if we want to just do the dynamic power wearing scheduling, the application should have the characteristic like that. Some part is just a very heavy load, and some part is maybe some light load. So that is very dynamically. So that means if we want to do these things, maybe I could provide some tracing, or as you mentioned, some payload detecting mechanism. That part could be unique, provided to some open source developer peoples, such like cross sourcing. Like cross sourcing, that means everybody just running the same benchmark or same trace tools on their own device. And they could feedback to you, what about their consumptions and use about their applications. It's intensive computing, or maybe less intensive computing. So I think if you gather all of these feedbacks, maybe you could just calculate the real scenario is exist or not. And then from hardware side, you could calculate the energy and the power consumption. It's suitable for a little core, or maybe it's just suitable for dynamic change between big core and little core. Because currently, Huawei's high sitcoms is also manufactured with arms, big little cores. But currently, it's just these problems, challenges. No sure how about the scenarios should be placed by that. Because currently, from the software side, we do not aware about consumption. Because if I program the applications, I do not know how about the frequency about the cores and how about the CPU is I do or not. Because in my program, I do not invoke any system call or any interface to determine the core is busy or not. I do not know. So that means if we want to do the power awareness scheduling, that should give some hint from the hardware side. My program has a characteristic like this or not. Suppose like somebody inside a room, if I always inside a room, you should not power off the light. And sometimes, many hours, I just inside the room. And sometimes, outside the room, you could turn off the light when I outside. But this should be very, very, very cooperatively tightly. That means when I just go inside the room, the light should be power on. So that is very, very dynamically inside the operation. So my suggestion is first, we focused on the use case and maybe I'll provide some tools to find these characters. If it's truly in the scenarios used, we could just to find out and to summarize these characters to provide some power awareness scheduler. That's all. OK, thank you. That's interesting. The problem we have right now when we talk about power scheduling is that inside the kernel, we don't really know about anything that happens in user spaces as it is at the moment. What we can see is just we'll have some tasks, some run a lot, some don't run a lot. But we have no idea which task is actually an important task that actually directly affects your user experience and we don't know what is actually. Yeah, that's very challenging, I think, in the background. And that information can only come from user space because we simply don't know inside the kernel. Because from user space, so many applications is run very dynamically. So I think maybe we could not know how about to recognize it's suitable or not suitable. So my suggestion is maybe we could just do this like crowd sourcing. That means provide some basic tools, such like we provide some basic method. Maybe it's based on Perf or maybe based on Ftrace or maybe LTTNG, yeah, to let the different user to identify how about their application it's have this character or not via the open source community. Yeah, maybe very personally, very personally. So just share. I'm not 100% sure what the tool would do. That tool should, that means suppose I am software development developer, I could just find maybe my application have this character or not because I know my application. Take the microphone, please. I maybe understand, so it's possible to characterize the application, understand which section of the code are CPU intensive, which section are not CPU intensive, which section are important for application point of view. Having this information, what this suggests I think is I have some application interface that is able to give this information to the DT kernel. So the kernel can make some decision or they, I prefer that the CPU made some decision. So suppose that you can inject instruction that he said from now end up to this section of the code it will be a CPU intensive, it's important task. So the CPU knows the prefetch instructions, the CPU prefetch knows that from this, this distraction to the end, it not go down in power or not switch offs unit like I don't know, FPU or because you know that you need. So the idea is to give information to the CPU when the application needs more power. In that case, it's not the kernel that she knows, the kernel just send the task and the CPU has the knowledge about what is going to execute in this CPU or in this core or in this unit. So if we have, for example, for a HALU unit and five FPU unit and the task said, okay, I not an important application, I can use just one adder and just one FPU unit and not multiply instruction so not pipeline a lot and prefer to switch off this unit and let the good application a little bit slow but reduce the power consumption because you have characterized your application. Okay, yeah. This is bypass the problem so understand from the kernel what the application, if the application is power or not because it's the application parameters that inform that he needs more power or he needs more better services and that's it. This is the same if you do, for example, encoding algorithmic, suppose that you have a section that you want to reduce dynamically the algorithm because you would like to consume less power so you can inject instruction and you can say, okay, I need less power basically or I need less services. So it's a way to dynamically inform the CPU what is going on at the user lab because the kernel doesn't know exactly what the application, what are the application requirements? I think you could actually get away with just telling the kernel about it because the kernel will do the scheduling and if it knows it can trigger some Ufriq or something. But it's not fast decision, you need to raise instant with a section of the code, correct? Yeah. If a programming user space needs to run then it will be runnable and the kernel will schedule it at some point and if it continues to be runnable repeatedly then it will get scheduled more. I don't see this as a problem. Well, because it's runnable more doesn't mean that it's something really important. Yeah, but something that's really important will probably try to run more often on average. I don't know, you can have. Yeah, I'll have it written as well. The important that does not mean that it matters a lot. No, you can also have some setups where you have a multi-thread scenario where you have a lot of shorter tasks that sort of depend on each other. So they actually add up to become quite a lot of work. So if you don't run all of them fast then you will hurt your user experience. So it's, but just looking at the size of the tasks it actually doesn't tell you that much about how important it is. Well, you can use it as the first choice. Well, if it is a big task then it might be important but you're not guaranteed that it's important. Yeah. And the same thing the other way around. I have a question down at the back. Well, I think a lot of the things I was thinking of was already talked about. So let me just literally summarize it from my point of view. Well, for me the problem is some kind of three-layered. It's one that the application layer which actually shouldn't know about how the kernel is achieving any goals. And the kernel has certain means how to achieve some goals. I think the key would be to find parameters, how you define really from an application point of view what this application has and demands. That might be an interface which the application when it comes up tells the kernel or some layer beneath it what it wants to do. Or it might even be an interface which is periodically somehow triggered so that something can be derived from that. That would be for video playback on these things. I would think about maybe these periodical stuff. And then I would think there should be kind of a layer in between which does kind of a translation to the actual capabilities of the kernel so that the application really can define that in application words. So the application program I shouldn't know about how the kernel does it at the moment or on that machine or whatever. Our goal should be to have kind of generic applications. And on one machine it's done like that and the other machine is done like that. We should try to find terms which an application programmer can really, in these terms, tell about his needs. Then we would have some kind of a translation layer and beneath what the kernel can do. Of course, these things are not independent from each other. Yes, I fully agree that if we are to introduce extra syscalls or extra C groups or something to identify which tasks are important or not. It needs to be very, very high level because there's no way that the application program should deal with the complexity of what's happening inside the kernel. And I think we can actually get quite far by just having the application programmer tell the kernel if this task is an important one or not, which is a very high level thing and I think it should be possible for the application programmer to identify that. And even the application should not tell one application how the kernel should behave all in all. Because usually there's something more going on than one application. Of course, maybe one application has the focus and because of that has certain demands, of course, but there's something going on in the background and other applications. So these layers somehow would have to sum it up and optimize it all in... Well, try to meet all the requirements. Yes. So it cannot be just one application controlling the kernel, that's not the thing. Yes? Yeah, yeah, I fully agree with my colleague. I don't think the application should drive anything because that's part of the definition we have user space, we have kernel space and when we write the application we are not supposed to write it for a given platform except a dedicated tool. So a tool, sorry, an application is written and it may run on a mobile phone, on a tablet, on a PC, whatever. We have written a programming language that completely abstracted and that's the purpose of writing application and developing frameworks is that the application doesn't know the platform it's running on. So we cannot trust the application also because, well, I don't know a developer that would like to write an application that would voluntarily degrade its maximum performance just to save power. I mean, if we would provide the capability to an application to tell the kernel, well, give me the lowest priority. I mean, if we say that, the application would by default say give him max performance because today when you download an application or a 3D application or whatever, you wanna make sure you have the highest frame rate possible that you don't want to have any lags so no one would like to do that to say, okay, I want to minimize the power consumption because you know that you may degrade your performance and your experience. So I would rather state that we would need some sort of system policy or something that understands what's happening on the platform at the moment, not only on the CPU but also on the GPU, on the hardware accelerators, on the peripheral buses, some things that understand actually what's the use case running on the platform and that would provide hints to the scheduler to whatever other processing units because we talked about a lot of CPU, CPU centric and the CPU kernel but actually there is also some sort of kernel running on a GPU, running on a DSPU and anything else. So there has to be some, I would say, system power management framework that would gather information from all different parts and would feedback this information in the right format to each specific unit. The Linux kernel should have some APIs provided so that we could drive the decision. We could have just a small cursor, for instance, that you would say, well, here at the moment I want to be more power oriented than performance oriented and so based on that hint, the scheduler would decide whether or not to pack to do any sort of decision. I mean, we have to understand what's happening on the platform if you have a display that is turned on, if you have the GPU that is also running, it's not only about the CPU today. No, but how do we know from inside the kernel what's important with this load? You have many of them. Yes, but it's not the scheduler that has to know that. It is some sort of system policy that would understand the use case or the use cases that are currently running on the platform and given that knowledge and the thermal and power budget it knows about would give hints to the scheduler to be more or less aggressive in terms of power management. The scheduler would still do the scheduler thing and what you proposed before is very nice to provide some feedback to the scheduler from CPU idle and CPU fraud because you're right. They are corrupting each other and so today this is a big problem but then there is also something else on top of the scheduler to help him also take better decisions based on the other peripheral on the system. Yeah? About the feedback from the application developer... No, not from the application, from something else, some intermediate layer has been mentioned. Coming back to your point about the application developer would always ask for the highest possible performance. I have the same concern but at the same time I think if you do that and you use too much power you get pretty bad reviews on Google Play or whatever. So I think the application developer should actually start worrying about how they actually write their applications. You are right but at the same time look at Android application I would say because they are everywhere. You would say that you have to write a different application depending on the platform it would run on. No, it doesn't have to be platform independent. I think just a hint like saying that this threat I've created here that actually renders my user interface so that is important but I have this other threat that indexes my emails or something in the background. That is not important. It's simple things like that that can make it easier for the kernel to actually do the right decisions. Yes, but Android can know that. The application doesn't need to tell Android that it's using the display. Excuse me? Yes, but you may put some middleware that would drive and provide the information through the kernel based on... I mean today you know if your Wi-Fi is on, you know if your Bluetooth is running, you know if you are doing a lot of data sharing, if your display is on, you know how the external world is by the temperature sensor. So you have to make your system more smart, more aware of its environment and more system aware so that you can understand the use case. Today we have a lot of limitations because the only thing we know is what the scheduler is scheduling and we care very few about everything else. If you had this knowledge and you could concentrate this knowledge into something that knows the platform, that's exactly the point you actually raised about knowing the platform, then you can take the right decision. If you know that you are listening to MP3 and your screen is off, you may understand that well, you are in the train, in the plane, whatever, and you just listen to music, so then you can be very power-aggressive.  You can also know, for instance, you could monitor the battery level and starts getting more and more aggressive with regards to power. The, as long as, when the battery gets low, all things like this. I think it's up to us to more understand the system and the system has to know how it is being used and then take the right decision. And we shouldn't let that go to application because today the application developer, they don't care much and they don't want to. That's the point of developing application and developing kernel drivers. Okay, it's running too much. We'll reduce the importance of the applications and then rebalance again. I agree that there is, we need some middleware. We need not to do everything in the kernel. We need some middleware to decide the importance of the application. But in the end, if I want to watch a video and I like to consume a lot of power, I don't want that the scheduler takes some decision and then reduce my feeling of, for example, listen to the music. I listen to the music. I have better responsibility for my application from other applications that run in the system. I can decide by myself but to increase the importance of the application at user space level. So in that case, it's... I think that my voice is so loud that... I think we're actually running out of time. So I mean that it's end user decision if the application is running or not running so fast. So give the possibility to the developer to decide the importance of the applications or give the user to rise the importance of the application. Give some information at the kernel level in the end that you need to give more budget. Let me say this one. This is more share of the CPU to this application. Or just because they don't want... You want to consume more power but because you want to listen to the music or watch a video, I don't see any problems on this. So the scheduler need to do a quick decision based on the load but it's the end user that can decide to consume less power. So I want something simple in the kernel and give the infrastructure at the user level and the middleware to give some help to end user to have a better feeling on the application side. Oh, let's system DD side. Yeah. Okay, I think we need to stop here. We're already over time but I'll hang around so if you want to continue that I'm here. Okay, thank you everyone for coming.


Welcome to this video vlog on the institutional review board of Tyson. What do we do? Well, if you hear the institutional review board, you might think, well, is this the Spanish acquisition? So all my research will now be going through this IRB and people will critically look at it. Well, no, I want to warn you upfront. This is not the case. We are here to indeed review proposals involving human subjects. But we are not examining with the aspect that we go into the nutty details. We want to help researchers to help them with their research agenda and to go things as smooth as possible. So what do we do? Well, our idea of an IRB is actually to sustain and improve the quality of research as Tyson for participants. So first of all, we want to protect the privacy of participants and prevent physical, psychological or other harm to participate in research. So this is one thing we evaluate. We are not going to go into the details of the research questions. No, we just want to evaluate whether participants are treated or how they should be treated institution and society. We try to also support and facilitate in the in integrity and transparency of data collection and management and accessibility of research data and results to the extent that that doesn't conflict with a so next to this participant protection. We also have the goal in mind that research should be open if to the extent that it is possible. And important that's the last aspect. And here I also say we are smooth. We try to support, educate and add researchers to conform to this IRB aims and procedures. We also have a minimum possible workload with a minimum possible workload for research. Also, it should not conflict with a and B and this minimum possible workload, I will explain in another video blog. There you will be clear. There it will be clear that indeed the IRB is here, but IRB has a lot of possibilities where people can actually go into a fast track to evaluate the research quicker. Of course, some proposals require full review, but I will explain that in the next video floor, but the important to remember here is, we try to make things smooth. What to why this was established, like I already said, first of all, we want to somehow create some ethics in the data collection and avoid that strange things happen to participants. What do we typically look for while important is that if you do research you fully inform participants, and that they are also willing to participate by giving informed consent to the extent that it is possible. This will prevent as much as possible physical and psychological harm and important. Most of them, the data collection, if possible, should be anonymized to assess to what extent this goal has been achieved so we actually take these principles to heart and we check research proposals on these kind of principles. We sometimes remarks on the proposal which in a revision are often easy to resolve. So most proposals get one revision after one revision. Often most of the things are already in compliance with what we expect as an IRB and you can move on with your research. Another important aspect is of course data management. We want to avoid that some fragments of the data are stored somewhere and nobody knows exactly where storing is actually happened. We want to have transparency in data management, also because Tilburg University also stresses this protection of participants in this storage. So we try to store data anonymously, and we try to also emphasize that maybe it's also open if possible for researchers so that other research can replicate the research results. So there we have a sort of view that if possible with the protection of participants that data is as open as possible for society. So I already mentioned this, it's mainly research related to human persons or a group of human living persons that you are going to approach. It doesn't contain anonymized existing data or pseudo existing data, maybe past data that is available from people that were. Well, information available there. Well, that can be is not under the scope of the IRB the IRB most of the time focuses on human persons that you are going to approach via survey experiments interviews these kind of things. And then you need IRB approval. What is important, like I already said, we evaluate these proposals on certain dimensions, but we are not going to say well is this research relevant enough for society is the contribution large enough. For the journals, not for the IRB so we are not evaluating that important proposed research as of 2020 can only be conducted after having received IRB approval. And also we get sometimes request, can an IRB provide post rock approval after research has been started. The answer is no, we don't do that. As soon as you do human research, it's up to the researcher to then submit to IRB. We cannot give post hoc approval. That that's the principle and often a lot of principles that are followed by competing IRBs at other schools, the ideas. If you have human subjects or you want to approach people go to the IRB first and the process doesn't take long. I will explain that in the next video blog, but most of the time 10 to 15 days at maximum. Why do we want to have it. Well, first of all, there is a legacy argument. A lot of schools have it top journals asked for it institutions also wanted. And so that's why we also thought Tyson need to have an IRB. We cannot run behind all these solutions we have to be front runner on this aspect to the legal argument. But what I find more important is also, there is a good research environment and for my own experience. It's really helpful to get your proposal approved by IRB, because you have to think a little bit already early in the stage of your research on how I would be going to approach people and what am I going to do to make sure that they are approached in an appropriate manner. So it helps researchers to plan their research and I think the IRB should be seen as an advantage. And once you have that quality check you can go on with your research. That's one thing but on the other thing it helps you to think ahead already about these quality issues and you become a better researcher. And that's what I think is really an advantage of the IRB. You become more trained on these aspects and you are aware of things that should be done to protect participants in your research. So I find more important than the legacy argument. So if you want to have more information then visit us at this website. There is more information available. I will also make a next video vlog on how we actually approve proposals. So for now, thank you already. If you have questions, go to this website and I will be answered.


He's talking too much truth. Yeah, Elder God says it. He said it in the shorter form. He's talking too much truth, right? Talking too much truth. Speak truth, they come after you. Speak truth, they come after you. Elder God, popping in the who command. Awesome, awesome, awesome. You want to learn about the who pandemic treaty? Check out the links we're provided, the video interview and the links. Right? And then there's people on social media, if I can, sharing pics of...  He did... what is he doing now, right? What has he been doing for the last two years? Has he been your ally? He's been my ally, right? Has he fought tyranny side by side with you? He has.  Russell bad, like Putin bad.  Anyone that believes that bullshit, right? But we don't know yet, right? Mr. Brainfreeze, they always try to find dirt or frame when they want to silence someone. Yeah, my thing is they probably have that already. They already have all this. Why do you think, why do people think that they want to track everything you do?  Because if you dare to resist their tyranny, maybe choose bodily autonomy, all of a sudden they'll go, oh, let's check out Chicho, Chicho for the last 20 years. What has Chicho been up to for the last, what pictures did he share? What did he do? What did he buy? Where did he go? Who does he know?    That's one person blaspheming.  Anyone that knows the story of Jesus Christ, right? Really, if you know the story of Jesus Christ, it's about someone who is a truth seeker, truth speaker, right?  In the process, they demonized him before they crucified him, right? That is, that is, if you can get anything, eat the fucking, the essence, the essence of the Bible. I'm not fucking, people will say, Jesus Christ was the Son of God, crucified, he's the only savior. Oh, people say that's the core essence of what the Bible has to teach, right? I've read the Bible. Have I read it from page, from front to back? Pretty damn close, man. I was born in Christian for a number of years and I had a Bible that took notes, went to fucking, right? The core, you will seldom hear that this is the core one. To me, the number one message that the Bible is trying to get across is that truth tellers are crucified and this is how they do it, right? That's it. The rest of it, apologies to anyone that you can take it to heart, you can say no, you can do whatever you want with it, but everybody should agree. No matter how you take the Bible, all the different factions, all the different, maybe Catholic, Protestant, Russian, Orthodox, Greek, Orthodox, Armenian, Orthodox, Pentecostal, I don't care what you are, that is the one core essence that it has, right? That's it. Will we ever learn that lesson? I don't know. As Immortal Technique says in one of his tracks, Jesus Christ is the most courted prophet in the Quran, right? Some people say the Holy Quran, right? For Islam, so take Judaism, well Judaism is, it doesn't, you know, Jesus, the prophet hasn't come yet, right? But take Christianity, right?


Inclusive, vibrant, stimulating, diverse, loud, patriotic, multicultural, creative, community, warm, diverse, challenging, different, free, serviture, and green. Multicolour as well. Multicolour, and green multicoloured. Rangicangi, Farak and Eggdampagal. Soas has really taught me how to learn to listen and embrace diversity. Soas has made me a lot more open. You analyse events and things in a very different aspect. You're just absorbing this constant cultural hybridity of Soas. The advantage that Soas students get above all other universities is their global perspective. You come to Soas and you learn not just about Western culture, you learn about culture throughout the world and how from Western culture interacts with those other cultures. The thing about Soas is that you're getting so many people coming together and so many different views, backgrounds, ideologies, men, like, in one small institution. Probably the most formative experiences was speaking to people and learning stuff that you wouldn't learn anywhere else. The range of subjects that people work on and the kinds of ethical and political commitments that they study has been extraordinary. We get a far more diverse range of students all wanting to make a difference in the world, which is what's important. I've found a lot of like-minded individuals and been able to really like, kind of find my niche here. Soas ma aunu bandagadi, ma yatri manche matre tio, kati min seshintio, tada aile ma raje nitik manche pani jas to laksamu.  I think people take you seriously as a person. I didn't expect to learn so much about South Sudanese hip hop. Definitely not, and I'm glad I did because it's amazing. Soas has changed my life. I came here very skeptical and very cynical about the world around me and I think like, from the people I met, from the experience I had, now I really have more trust in the world and the thing that can be done in order to change the world. I definitely learned to look at things from a very sympathetic way after being in Soas. I see my mind becoming more receptive of new ideas. Well, it has definitely changed my view of the world in terms of not necessarily of like choosing a side but just engaging more with issues that I didn't think related to me. Like, my best memory at Soas would be maybe the closeness that I've had with all of my classmates. It's been like a family thing to me actually. It's very nice to feel like so supported. Just having this sense of belonging, sort of like a family environment where you can share your ideas and be comfortable knowing that you're with people who are like you. The good thing is in here that the majority of people is minorities. The best thing about being at Soas has been the students. Hands down, no questions asked. I am perpetually surprised and pleased by how amazing Soas students are, how incredibly committed, how incredibly intellectually curious their sense of originality and curiosity, their sense of enthusiasm about the world, their optimism about how they can transform things, their sense of ethical commitment to their colleagues, to the other people who are at Soas and teaching them has been an extraordinary privilege. It's like a celebration of different cultures. The colour, the vibrancy, the people, everything. It's just, it's unlike anywhere you've seen. Resultant. Happier now. Very tolerant. Exciting. Engaging. Colourful. Enlightening. Yes. And passion. Vivid. Scenting. Complex. That's my word for Soas. Complex. It's also a beautiful place. Soas is the greatest ever.


The t2tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday updates. It's been a month. Lots to talk about. Let's get into it. I'm going to try to go really fast. When we left off last time, Luke and Dennis had volunteered code to try to run on the grid. And both of their codes had revealed bugs in my code. And we had fixed the one that Luke's code revealed. But we were stuck at the time that we made the video on Jacob's Ladder. Sometimes it would work fine. It would send out these two red rods and then have these blue electric arcs going between them. And other times, bang, we had gotten it down. It was the place that always scares me the most, which is the intertile event stuff, the views that the tiles and the neighboring tiles think that the other one has gets inconsistent. And one guy thinks this thing is still in use. The other guy thinks it's free, or vice versa. And bang, and that's what we were facing. And after a month ago, I was able to run it down, and luckily it wasn't too bad. And so where it came from was in the Splat language, which is what Jacob's Ladder and the Sandray and all the ones that we've looked at from Luke and Dennis are written in. You have a sequence of rules. And the way the language is defined, if none of the rules match, if you get all the way, you know, you try the first one, you try the next one, and as soon as you find one that works, you do it, and then you're done. And then when you come around, next time you do it again. And if you get to the end of the rules and fall all the way off the bottom, and none of them matched, the Splat language declares that that guy is to be erased, that that is just another way to say, replace me with empty. And that's what was happening here. So in the Jacob's Ladder, he's looking for, the at sign is the Jacob's Ladder piece, looking for a empty spot. And if there isn't an empty spot, this unfortunately down here is the cursor. It's not another rule. There's nothing to match. So it fell off the bottom, which again, completely fine. But the way it's designed is the reason that that spot gets set to empty if you fall off the bottom is because the internal engine, the Splat engine throws an error and says no rule matched. And the response to getting an error is to erase the spot and move on. But the engine wasn't working that way. Instead, they had code that said try to execute the event. So all of the Splat code was happening down inside execute event. But if it returned true, then everything went on about it. But if it returned false, meaning that something had gone wrong, then it did a separate path and that path was wrong. In fact, what it should have done is just go ahead and execute the event either way, because everything was handled inside. So since I went through this whole just kill center and commit that, it caused the active side, the one that was doing the event to finish up and clean up without telling the passive side, the one on the other side that this event was now done. As a result, the next time this guy tried to use that same event window number on the passive side, it blew up. So that was now fixed. And so Jacob's ladder and Dennis's other one, a lighted pyramid that we didn't even get to look at because it had the same kind of issue. They now both work fine. Here's a pyramid growing on my desktop. Here's a couple of them growing on the bigger grid.  It all works beautiful. Unfortunately, I don't have video of these things because the blue and red lights twinkle on the thing like a big old pyramid Christmas tree. So progress on that front. In the chat room, AJ has started exploring the possibility of making a low-level assembly language for doing event window programming. Luke is also helping out in that. It's very, very early, but also very exciting, very cool. And starting to build out possible documentation, instruction formats, and so on. So there's a number of times that one super wonderful outcome, if we could actually get to it, of the T2Tile project and this larger research project in general, is to come up with a new instruction set architecture where hardware could say, I'm just going to implement to this instruction set architecture. And software could say, I'm going to write code to this instruction set architecture. But instead of it being the traditional thing defined for CPU and RAM, it's an instruction set architecture that's designed, bent, optimized, robustified for best effort computing. So again, this is just an early, early step, but it warms my heart. The history video, yes. So this past month in February, I also had agreed to do this 15-minute history of computer science. Originally, I thought they had said in the spirit of a drunk history, which I had never seen. And I watched one or two of them, and it's like, no, I don't think I can do that. But later ones were talking more about John Oliver last week tonight, and that's the way I tried to go. And that happened a couple of weeks ago, Friday, February 19th. And so I had this 13-minute, well, 15-minute slot. I did 14 minutes, whatever, in a video. It's now up on the Dave Ackley channel, and doing okay by Dave Ackley standards. It was very scary because, you know, sort of trying to make actual, like, sort of official jokes, I don't feel all that comfortable doing it. I mean, I don't know if anybody really does, but, you know, it worked out however it is. Did any of y'all see it? You know, I'd say be gentle, but I'd rather you be honest. Okay, and so that was that. And I put up Hugh Jean, the ancient co-evolutionary simulation from 2003 originally, now transferred to the tile. And, you know, it really looked pretty good, and it was fun to see it going again.   But 8% click-through rate. Oh, that's great. You know, apparently you need to get 20%. And then that's when you actually hit the big time. We're in the small time. So that's cool. And I also released another one. Don't cross the streams. Just about a half an hour ago, as I shoot this because I'm so late. Just playing around with swap lines. And I feel like, you know, got a pretty good chunk of dynamics out of it, out of a fairly, fairly small idea that, you know, don't cross the streams. So what happens when you do cross the streams? You create a new guy that generates streams. And, you know, I put goofy music with it and so on and so forth. So, you know, now there's a new playlist, the T2 demos playlist, because it's got two whole videos on it.  All right. Yeah. And there it is. There's our lonely being shooting swap lines off into the wilderness.  It really is a tractor beam, which I always sort of wondered, how the heck could a tractor beam actually work in Star Trek? Well, here's one way it could work. All right. On another front, I've been evaluating, trying to figure out how we're going to shoot half-decent video of the grid, especially as the grid gets, you know, six times bigger than this is now. I tried. I got one of these cameras, this Mocos, Mocosi, who knows, like that. You know, here it is. And I've been experimenting with it.  And in fact, the Sand Rain time-lapse, I recorded on this thing. And, you know, I'm still trying to learn how to use it. You know, when I was looking at the, Don't Cross the Stream stuff, I was getting this crazy, like, you know, this looks sort of out of focus in general, and it is not focused very well. But the blue is like so much more out of focus than the red. How is that even possible with a single lens? Well, it turns out that setting, doing the white balance, which is something that I've never really knew a whole lot about, doing it manually and turning the blue way down, looks actually get sharper pictures and so forth.  Wouldn't, probably wouldn't be big enough to do the entire thing, but might be able to do a chunk of it in some sort of tiled configuration. So that's one path that I'm exploring. The other path is, you know, get an incredibly expensive multi-thousand-dollar camera which has, you know, a 50 megapixel sensor and can do 5,000 by 3,000 or whatever it is and just shoot the whole thing. We'll see. That's down the road, lots to do before we get, need to pull a trigger on that. So, yeah. And, all right, so that's it. And the one extra thing that I wanted to talk about in a little bit more detail is the common data manager because there's, as the physics, as I'm recompiling all these physics, coming in from other folks as well as my own, it's taking distribution over the CDM is more and more significant to my own workflow. And it had some problems. The existing system had some problems. Cdm slash common, that's the name of the directory, the folder where all the CDMs go. One, two, three, four, five, all those things, those code numbers, those two digit code numbers are the slots, the 516, 520, those are the timestamps. So a slot and a stamp tells us a specific moment in time for a particular piece of code. And O2 is the T212 infrastructure package. So it's almost two megabytes. O3 is MFM, which is, you know, much bigger, it's the biggest one by far. But it was O2 that was particularly bugging me because included in the O2 package is the very low level assembly code Linux kernel module stuff that whenever that low level stuff gets reinstalled, I have to reboot the tile. It's the only reliable way to get everything all in and get it set up properly. And that was, you know, cramping my style. And so finally I pulled the trigger and said, well, why don't I reorganize that whole directory and try to get rid of that O2 slot and make it unnecessary. And the way it works is, you know, each slot and the file name has the number in the file name. And then in a piece of the CDM code, it has a map that says what we're supposed to do. O2 is supposed to go into slash home slash T2 and so forth. And that's a robustness feature that the code that says what to do with the CDMS files is not in the CDMS file. We don't trust it to tell us what we're supposed to do. It's in the code that we have. Now that came by a CDMS file too, but it was a separate code. And there it is. So for O2, we have to reboot after we do the install.  The reason I had all these subdirectories, app stocks, and so forth. So I went back and I did a major refactoring, which is mostly done, but not quite completely, to break it down into smaller CDMS instead. So now we have base CDM low and MFM. And low is the one that has the Linux kernel module on the assembly code. So if we reinstall low, then we have to reboot the tile. But if we do the other ones, if we distribute CDM, all we have to do is restart CDM. If we distribute MFM, all we have to do is restart the engine and so forth. Now that causes four new packages O5 through O8 for each of those individual pieces. And in fact, we can distribute them individually. And it works pretty well. There's a slash low. That's the one that's going to have to have reboot if it happens, but we haven't done that yet. Now, as we've been doing this, so A0 through EF are the physics packages. The things that say I have an element of Swapline, an element of Dreg, an element of Res, a physics is a complete collection of types of atoms all put together that are meant to play together nicely. So A0 is a collection of atoms, A1 is a collection of element types, and so forth. And now that we've got so many of them, the way that CDM was doing distribution was really becoming painful because what it would do is it would just pick, it would look at all of the CDMs that it's got internally, pick one at random and announce it to the neighbor and say, hey, I've got this, here's the date, here's the length, do you want it? And when there was only a handful of CDMS files, it worked fine, but the more you get, it gets slower and slower and slower and there's more and more and more stuff saying, yeah, I got it, I got it, I got it, I got it. So I finally pulled the trigger on that and went back and redid that as well. And there it is in the configuration file. Again, everything from A0 to EF is a physics slot. And so there's a new package now within the CDM code called urgency whose whole job it is is to figure out what we've got, what we think they've got, and then say which thing would be smart for us to announce. And so it's got all these things like I just announced to, so we can record the fact that we told someone, in the original previous version of CDM, we never cared what we said to anybody, we just picked at random, which is really robust because there's no way that we will fail. We can't get messed up. We can't think we announced something if we didn't. If we just picked things completely at random. So this, by making it more efficient, is also making it more fragile, but we still have a backstop that all the way down at the bottom, if none of this other stuff comes through, it'll still pick at random, but now that'll be even slower. I just announced to, they just requested, when they ask for something, then we know something that at that moment, they would like to have as of this. Now, I now think they know what I know, what I think they know. It's one of these logical paradoxes of, I think he thinks that I think that he thinks and so forth. It all boils down to get urgency, which is the absolute bottom line key. And urgency is based on two factors, a time pressure and a size pressure. The time pressure is, how long has it been since I mentioned this particular slot stamp combination to this particular neighbor? And the longer it is, the more the time pressure goes up. It's not how old the package is, it's how long has it been since I mentioned it to them. And the size pressure is, how much more do I think I have of this file? Because this is all pipeline. I may not have the complete file that we're talking about. I may only have 30% of it that I've actually been able to check some and believe that the crypto is good, that I can go ahead and redistribute this before I even have the whole thing. So our lend is how much of the file, the thing that we've got, their lend is how much we think they've got. And the more that we've got compared to them, the more urgent it is. And so the urgency overall is the product of the size pressure times the time pressure. And it's still, so this is now distributed, this is now out there. So here it was when I had to put out, so when I had the whole T212 reorganization, I had to use slot two and there it is. Again, going out one more time, 163K, and it's only got 8% gone because that was the only slot that existed. The five through eight didn't exist until this update went out and updated MFM and so forth. But now it actually works really good. So here it is a chunk of action shot on the grid when we're distributing six different physics files all at once and they are moving. And so that took a bunch of time, but it was pretty satisfying. And here's another shot of it. So that's it on the CDM. And so going forward, now there's a lot of stuff going on still that's getting in the way of hacking on the engine and doing all this kind of stuff. It's just that kind of year. Well, that kind of season at least. And so number one, the artificial life conference, the 2021 artificial life conference deadline is coming up in a week or two. And so I'm not even sure if I'm going to submit. We shall see. I'm working on it. We'll see. I don't know. But once again, is this the third time I'm going behind the wall of science and I'm doing this stuff that I'm not telling you all about because it's supposed to come out in the conference for the first time if it comes out anywhere. We will see. So that's happening for the next couple of weeks. And also I promised the next Hyperspace Academy lecture in January over on the Day Back of the Channel. It's now very late in January. So but there's a lot of progress on that too. That's the we are coders. This is my rant about a way to look at humans and living systems in general and interpersonal relationships and so forth. I mean it's easy to get cosmic about this sort of thing but I think the we are coders approach actually has some pretty good stuff. I mean it's all stuff that's covered in other ways in other degrees. But this feels to me because I'm a coder fairly clean and fairly simple. So I'm going to be working on that. So I have no idea what I'm going to be able to talk about on March 16th. But I will be here. I hope you will be here. I hope things are going well for you. We'll talk again.