Good morning. Good morning everyone. Hey, I don't know. Hey, let's get everyone a few more minutes.  Hey, hi. How are you? Not too bad. What happened? I'm double-duding watching a baby right now. Just trying to attack the cat. We speak in Finland. There's also a school holiday, so I'm like, at the same time working from home and supervising my kid. Well, that's not fun. It's okay. How many kids do you have? Sasha, how many kids do you have? Just one. Just one? Yeah, it's ten years old, so it's already not a big problem, but just from time to time. Let me ping Renault and Mike Brown just to see if they plan on joining, and once I'm done, we can probably start. Hey Renault, how you doing? Hey, how are you doing, Mike? Crazy. This Docker thing is killing me. They're stressing the entire industry. Well, the container image industry anyway. What's going on now? Just the retention stuff with the image? Yeah, just the retention stuff. Are you getting any of these? Well, there's two parts. One is the deleting the images that haven't been touched. The more important one is the new limits, restrictions on how many poles you can do an hour. They're not really going to go nuclear on November 1st, at least not according to Mr. Cormack, but that's what it currently says. It says on that date, if you pull 100 images in six hours, you're out. No more images until after the six hour, if you're doing it anonymously. If you log in on a free account, you get 200 poles. For a developer, that's fine, but for people who do installs at customer sites, whoops, that's not going to work. Yeah, kind of the way they do it, they charge it back to the user instead of the image owner. There should be an option for the image owner for like. There is, Mike, but they're not making it public. Yeah. They've got two waitlisting programs. One, I don't have the details on on the client side, and the other is on the source side. If you have an organization with a bunch of repos, you can pay them for the resource storage and downloads. They'll do some estimate on the amount you've got and give you a number. We're still working that out. I've got a call with them on Wednesday to figure out if we're going to try to protect IBM.com. That's the other thing. They're just not being, they're not very public about all the different programs they have just yet. I think probably because they're still trying to figure it out. Of course, that will protect IBM.com polls for anonymous users. It won't help anything on the other side. IBMers who still need to pull public images will be out of luck. They'll have to get a team seat, I guess. I know what our guys already hit some limits in the testing clusters. Yeah, they have throttling limits for the people who pull hundreds of the same image hundreds of times per second on the same IP. Yeah, they're trying to throttle those guys pretty hard. My P2P service won't work anymore. Yeah, that's definitely the solution. There are certain scenarios where they've gotten used to using latest tags and Docker only counts the, they don't care how much, how big the image is on the client side. They're just counting the number of manifests and saying, okay, that's one poll for one image, no matter how many manifests you want. And then of course, we're just using that for verification validation of the hash blobs that we have stored on our cache. But they don't care. So if you do latest or default or pull always, just to check the authentication verification, then yeah, that's a pull. You can use mirrors, but then how often do you go back to the source to make sure the original root public is still the current version? I guess you can configure that on mirror. All right. I think we're still waiting for Manon, but we can probably start. So thanks for joining everyone today. This is recorded, by the way. It'll be uploaded on the SegRuntimes YouTube channel. So on the agenda, we have really two items, and the third one is just a reminder to go and review the resource management improvements PRs. The two items are the next concrete steps for ACDI and NRI, and the second item is just some discussions around the panel for the COD Cod workgroup at QCon, namely questions we'd like to ask and answers we'd like to talk about. So we can probably start with the next concrete steps for CDI and NRI, because we wanted to have that discussion with Michael Crosby in the room. So I think maybe Sasha mentioned that he had talked to you, Michael Crosby. Could you maybe get us up to speed on what is the plan or what are the ideas that you have for the NRI? And I think there were some mentions about ACHA libraries between multiple projects. Is that a good introduction, or could you maybe help us just get us up to speed it? Yeah, I think the other thing that's been asked a couple of times is to what level of degree we'll be extending the NRI to support additional cases that the Intel guys, for example, had a need for at NRI. For example, hooks in different stages for pods and things like that. Michael, do you want to start first or start from my side? I can. So far the initial design of NRI was around resource management, specifically a need that I had for CPU and NUMA, and then expanding out to things like huge paid support, L3 cache, things like that. Kind of over the past month or so, we've been working on a few different plugins to support that. And so far, the lifecycle hooks of where we have now for the create, start, delete, and update calls all have worked out well. I can see some missing areas around maybe a pre-create where NRI plugins would have a chance to maybe modify the spec or do some transformations before a container gets created. But so far, from my point of view, I think it's flexible enough in terms of supporting this. But we've also discussed about some ways where we can share some underlying code for the plugins. I think the API is pretty generic and straightforward. It's collaborating a lot on the plugins and how those are built. So that's, I guess, what I have before the current state is. So maybe at least one of the things we wanted to do with CDI is this part that you're mentioning where we have a pre-create and we change the spec. One of these ideas here, at least one of the thoughts or the reasoning behind changing the spec is that, for example, when you're adding a device and you're informing container D or pod man about the fact that there is a device, then when, for example, a user calls D or makes a call to the update path, we don't need to have a hook in the update path because of, so the way that it currently works is that when you're updating the resources, if you've added a device and in the create path without informing your runtime, you also need to have a hook in the update path to read that device. But even there, you'd be in this position where if your process was reading from that device node and the update path removes the device from the C groups and you read it as part of your hook, your process is going to lose the read access to or read write or whatever permission access has to the device during that brief amount of time. So for update path devices handling at the moment is not possible at all. Of course, if you do modification for us, I'm saying what update path in OCI spec right now is not able to modify with devices. So you can do like it does, it does modify the devices. I mean, we have a long standing bug where because of how we do, because of the fact that we add devices in a container, for example, with the CPU manager, CPU manager goes in updates the, but just calls the updates on the CPUs and the container loses all the C groups permissions to read from the dev invader nodes. So at least, I mean, that's one of the reasoning where we had behind with changing the spec is that once the spec has, or once the changes have been sent to the container runtime, the hook is no longer, or at least the plugin is no longer around the hook to get in there and intercept every update call. The other one is that there's in a way a simplifying factor to just having a JSON file that says you just mount these device nodes and that's it rather than have a shell script that goes in MK nodes of devices. If that makes sense. Yeah, I think the API of how we interact is it's very flexible. So it would allow you to do a lot of that. It's just making sure we have the correct hooks in the in the CRIs. But yeah, I think I think it's totally doable when I started looking into a pre pre create hook where like, it would be more of the contract between NRI and the CRI because we'd have to like accept the current spec on standard in, do your transformations, modifications, send it back on standard out for these plugins and then CRI would have to commit that and say, okay, this is the final spec. Okay. So maybe I think one of the question that at least I had was if we feel like the NRI is the right way forward. The first question is, is the NRI something that we think we'll be able to see in not just container D but other runtimes. And the second question is, if it is the case, how do we how do we take advantage of that? How do we concretely, what are the expectations that like where where we start making pull requests? What's what's the step that we can actually start acting on and help build this this idea on top of the NRI? Yeah, I think Renault would be the best to to talk about if CRI would be interested in supporting this. The way I'm building it, like I'm hoping the goal is for it to be generic just like CNI is and a lot of the domain specific implementation happens in the plugins where we're just providing hooks within our CRI implementation. So yeah, I think it does make sense, but I think I need to understand the bigger picture like with in case of CDI we understand that we'll look at something of that sent over the CRI and decide that okay we need to make these modifications to the spec. So how are we integrating with the other items in the spec? Like when are we deciding that they're calling into the NRI? Are we mapping from the CRI or do we expect changes to the cubelet that call into the NRI? Yeah, maybe sometime I can give you a demo on it with what I have so far, but also talking with Alex, like I think a lot of us feel like some of these low level things shouldn't be in the cubelet, like cubelets already pretty big and it hinders some of the low level details that we want to do and so that's why it's geared just at the CRI level where we have a better understanding of the underlying system. Okay, so from our side in our project with CRI Resource Manager what we are doing is we practically we define the messages from CRI what is interested to potential policies. So it's all about metrics of containers of CRI and when all we create, update, delete messages. So we can react on reports, we can react on individual containers, we can for example for the statistics we can use CPU cycles what is reported by runtime to actually trigger some of the update of resources like CPU cores or something else. Okay, yeah I think that makes sense. If it's over the CRI it's easily integrable. Yeah, but I think with CRI is what at least on our side what we expect is what the hooks well whatever like in our case it's called policies we're able to modify intercepted messages. So for example we can case of create container, we can modify the resource fields. And the only real difference between CDI and NRI is you just taking it down one level so that we can support more than just a device specific API we want to support devices and resources and whatever we can think of in the future. From my side also to add what Michael said is where the mechanisms which like blueprinted from we see in our plugins when we execute it as a hook it potentially might be okay but on a high-loaded system it's quite expensive operations. So ideally what we're expecting to have is potentially some gRPC mechanism or some other mechanism where we can integrate closely to our runtimes both CRI and then continually with high efficiency passing this data back and forward. Yeah I totally agree like the CNI exact invocation is expensive like if we have a lot of calls Yeah I think Michael's NRI sort of solves all that right we just have to make some decisions you know Alex you're modifying the the spec before the container runtime receives it in the CRI space yes we like to store what we receive from Kubelet right in our own little storage so we'd like I think to store it first before you make your modifications if we need to store it again after you make the modifications that's that's fine that's fair well we don't have any specific problems of how it's structured and actually maybe even having well some level of debug which saying like this is what we received from CRI socket and this is what internals plugins modified it it might be a good solution no problem is that our task and our design is what we need to be able to have get from runtime the whole state of system like all the ports all the containers and just because of how our algorithm works we need to keep in my memory to rebalance with real resources if needed okay yeah that was one gap that that we noticed is we want at least one change in the Kubelet to provide us the entire pod spec instead of feeding us containers one by one because like the information's there just doesn't give the CRI the whole pod spec where we can make better more efficient uh decisions when we know the entire workload michael you probably missed it auntie started to draft a cap about what it's linked in the meeting units below so we will and now it's partially linked to our discussion what we had in this CRI going to GE or better discussion about we're generalizing how we communicate with our sources down from the Kubelet okay michael the when you say the whole pod specification there's a lot of good stuff there and it's not just the pod spec it's also the other objects that are related to the pod spec that Kubelet uses um you have to make decisions and set up the pod information that's passed on the pod run request um there's also a bunch of other stuff that happens before they do a pod run um you know and so far as doing image caching and loading um you know querying the state of the node that sort of stuff right Kubelet keeps that information you know pretty pretty tight to the vest um but I think we they have a um a thing in Kubelet um called a you know a container runtime manager and I think there was an original intent in Kubelet for that to be the CRI and right now it's it's just got a lot of stuff that we need access to so we probably need to extend the pod specification and other objects that Kubelet uses to be distributed through the CRI v2 or something to that effect yeah but as Derek mentioned it sounds like a boiling revolution so we need to specify how we can take a bucket of water out of this ocean boil it and then proceed to the next bucket right yeah yeah and hopefully under the under the common process we're moving the information we're moving the information the container run times need to manage these containers for the pods downstream yeah this can also come up uh I don't know who attended the whole uh sidecar discussion where there was a proposal to instead uh how explicit dependencies like on the startup order and shutdown order like like system d so if we end up going down that route then it will make more sense to give the entire pods back to the runtime and then runtime is responsible to manage the lifecycle of the containers within the pod but it's it's still early days in that discussion but it looks like it's headed that direction yeah that looks pretty interesting I especially like when they they started talking about the you know a graph order um you know with priorities for the sequence so one of the problems with web think uh Derek mentioned in the CRI discussion is what like uh it blows for responsibility or for example like priority of fabrication or killing of offending workloads so he doesn't want to remove it from a kubelet so we need to redefine what actually what kubelet will be responsible for and what runtime kubelet says what uh and runtime says how but Sasha uh so that so this OM adjustment yes that's fine that the kubelet is deciding that but the problem is that the kubelet is currently hiding from the runtime and everybody who is behind the CIRA interface that how much it has promised uh the containers that it can use memory so basically the memory yes that that is impossible to calculate reverse so that we should get yeah that is part of what what both my client uh anti-broad and we get proposal yeah it's about how to get full well full put spec or at least like full resource information what container are required but what i meant by with like what to run it's more about like the logical eviction uh of report so when when some condition on the node trigger it and kubelet needs to start evicting it will evict first start killing well containers for like normal workloads and system workloads will be like in in the last priority so that part stays in the kubelet but how it's run how it's killed in the runtime in my opinion all right so recentering a bit on i think cdi and nri um concretely um if we wanted to try to integrate cdi with the nri that would probably look like an nri plugin and if there are things that'd be missing it seems like we would probably need to make some poor request to the nri or some of the container decode is that something that makes sense so let me say something about that so ronal you're correct what uh where current cdi can be implemented in nri approach so like in in case if we uh hook into his pre-create state so we can get where uh container from uh cri inject whatever we need and when passive to run time to execute uh let's do well but when it covers only the case for uh for kubernetes and cri but our initial idea was what it's also applicable for docker command line and for uh for podman command line how do you see where so let me let me ask this is something that might have not completely understood the nri is integrated in container d um cri shim or is it integrated in container d directly uh it's currently in the cri right now but like you would just hook into whatever client code is calling like ctr or whatever and continue so so one of the thing at least um this is what alex has mentioned one of the thing we're really hoping is um cei is something that eventually pops up to the docker ci um maybe the container dci um at the end of the day what we're really looking for is first and foremost being able to do um docker or podman um run dash dash device uh my super device and then something like kubuntu and then uh my vendor tool if that makes sense um and then that's that's what we're looking to do because at the end of the day what we're hoping is at least the the mental model that we have for something like kubernetes is that instead of what kubernetes is doing today which is docker slash podman run dash v my volume um or my binary dash dash device dash e etc we really want kubernetes to be doing something like this that's that's the mental model that we're going for rather than the current mental model which is this and so for us the the first objectives here is really to surface this through the cei um and then with this surface this back to kubernetes yeah that makes sense but like looking at it from the cei standpoint we still have to put the hooks in for for those various places because of the way you get information in like you have to have hooks in the cei and like docker docker demon part you can't i don't think there's a way to get the best of both worlds where you get all of the pod spec for cube specific runs and be able to do advance like resource placement and topology with just a generic kind of the way docker and stuff is today container by container uh running okay so so what you're saying is that i'm still so if i were to rephrase and what you're saying is that there's going to be any or we are going to need to have to change a bit the um how the nri is called in the container d um projects and then the container d shim project sorry cri shim where am i or did i completely misunderstand what you said uh so and so the cri shim stays the same because we provided additional pod information in the inner i invokes for adding this to docker or another client you'd have to add the inner i hooks to that specifically because there's not a generic way to shove this inside container d core and to know a pod run versus a specific container invoke from docker i see what you're saying okay that starts to make sense um what about one cryo and pod one how do you feel about it i think i'll probably need to uh look at a deeper demo or something uh to figure out how we can integrate it but it looks like if the cri level it should be fine uh but i think that the thing then is like cri works for cryo but it doesn't work for podman so we'll be able to figure out how it'll uh work in podman yeah it should be exactly the same as docker versus cri kubernetes you just have to add the hooks in because they're kind of two different payloads okay isn't i think the podman case is probably a little special right where it's trying to run a container um for for a pod but it's more it's more just running one container right it's not integrated with kubernetes or anything like that no it's not yeah it can run just like docker like a container at a time so so we wanted to support that api at the ctr level i think we could actually just call to um the cri code with the you know generate a pod a generic pod spec in a similar way that podman team does well i already had it integrated in in ctr the first time you add the one line in our i folks cool all right gotcha just to make sure um i mean do these notes make sense am i writing things that uh yeah makes sense from the container d perspective and docker right um yeah i guess al alexander the question would be to you right on your side or you know others like you if you if you require additional pod spec details on the containers that are run at that layer so can you operate just on a single pod i'm sorry a single a single container as opposed to you know requiring the additional pod spec info well right now we are able to survive whatever the currency right message just have so some of the information we are just deducting from pieces right is available uh it's not ideal but it's doable and we want to get full resource specification so we will be like using real data not just heuristics to to detect it back however for us it doesn't really matter like what granularity what what matter is what we are able to get like needed messages like all create update delete uh and if needed to modify when i start applying okay so it's just a little thing you you've probably got some detail around when when we're using shared namespaces like in a pod across multiple containers but yeah so for far yeah for us the pod is also needed uh to get with information because we are supporting feature or container affinity and anti-affinity so for example like if you have like database and consumer within one pod needs to be located close together we need to have information what this container actually part of one pod right and we actually have that at the container level so you could pass over the NRI in the cases where it's applicable right um yeah that says yeah CRI messages have all of that information so what we expect from NRI is to have same ability what we can intercept on the CRI things and nothing more okay but of course like longer term to also evolve the CRI to to have enough usable information inside it that should be an interesting implementation Michael well you can already see the implementation of our projects here IRM is public so you can look what we are doing but in reality it's it's quite a really simple code like take GRPC server request analyze modify and pass it to a GRPC client got you got you so i'm just thinking like how to make your your code work via a plugin our quote will be quite simple to to do like well the whole policy engine is uh can be detached into separate library the only thing well only will be different is what instead of this proxy object we will be getting calls from some other GRPC service or whatever else we will come out with but nothing much changes yeah i think the only big difference in terms of API design is between CDI and NRI where we're wanting the entire topology for the resource use case while CDI focuses on single container devices but i think both can coexist fairly simply well Michael generally uh CDI in long terms supposed to support also the pod-level devices what applicable especially for like RDMA kind of devices where like you have a shared memory between multiple containers within one port uh so the current CDI it will just inject the same device twice and to multiple containers as many containers as many devices so it hides a lot complexity um i do want to time box this a bit so that we have maybe 15 minutes to just prepare a bit um some questions for the keep calm panel um was there anything else we wanted to talk about uh for NRI CDI whether or were there any topics uh well Rana if you can move this kept proposal to level up because it's related to all these discussions some uh which one one the one where you which you had this i'm just so okay but i do i do want to time box it since we have to the keep calm panel discussion is no no i don't want to discuss it i'm saying it's part of this NRI discussion so the only thing what is required is just what people start looking and say like guys you're doing stupid thing or yeah we have some comments how to do it definitely um do you want to talk about it or do you want to also present it in the next um um in the next meeting so that we have some kind of formal review and people will actually yeah we can look good for for for that meeting so that um after at the end of that next meeting we actually say yes no that makes sense it does not exist okay all right formal review next meeting all right um um michael thanks for joining us today i think like we definitely have uh but we'll probably have at least um we at least i have a better idea of what needs to be done and um i think where we're going with this okay sounds good all right and i think that's it um keep calm panel discussion um so at at least what so i mean some of the discussion we were having is that the format is more of a q and a um for since it's a panel and we might present some slides but it really should be reduced to maybe a small charter slide a small road map side and um if if there's a need for an architecture diagram that might be a good place but um it should be at most three four slides uh not that much the the real format is at least from what we have seen from other panels um online is um a moderator or a speaker or maybe speakers take turn and asking each other's questions and um other speakers just answer them so i don't know my my general idea here is just let's list some of the questions that we think actually makes sense in a q and a um let's list some of the answers that we we would like to see to the these questions um and that's it also keep in mind that we do have um 45 minutes but we should keep 10 15 minutes at the end for um online questions does that make sense all right um let me write down some of the questions that um the people here want to see um so before we go to the questions so let's let's decide first uh we're a moderator like around are you are you willing to be a moderator or we need to have uh i'm happy to be a moderator i'll also be presented by the way obviously i'm i'm also presenting this segment time with i would car game um which i'll be presenting cdi uh there um i'm happy to be a moderator but if if we think that it might make more sense to just like have a moderator or a design person for each questions that also makes sense i think we we need to have like at least minimal role of moderator just because like the first the first two three minutes of a panel is what we we need to introduce what topics we need to introduce what people just like saying like now you introduce yourself now you introduce yourself and and so on and when probably like short uh saying from each one like i am from x-ray like and afterwards maybe again like first first two questions like chapter and architecture is is first things which needs to be asked and afterwards we can shuffle to to already talk uh like more discussion between all participants but at least like what first few minutes to set up for tone for discussion we need it okay um who wants to be a moderator let's start with this one i think we have uh both actually uh mike and alex mirales are already left who who wants to vote for a moderator i vote for you let's go with that knows the mother uh and let's go uh is there anyone in the meeting that wishes to or that thinks he or she has a list of questions so i think for most of uh well at least one of the first questions i would ask everybody uh in in this forum is what like we are representatives from the different companies and from different areas so like right now you are device manufacturer we are hardware manufacturer together like both device and uh like resource management things uh mike and now is from runtimes world so uh our first question would be what is this cdi for you for your area what do you expect and what problems you are trying to solve with it what's what's the title of the panel introduction of working group is that you mean that should be a question well i mean we what do you expect from cdi and the but it's the cod working group so at some at some level we need to talk about the you know what what are what are the various projects that are that are involved that you know the cod working group is trying to encompass right and what is this right yeah well that's what should be part of the first introduction yeah i just say right right away on the first one we we dove into cdi right yeah i would great see almost needed yeah i think were you talking about reall were you talking about doing an intro maybe a five minute with a couple of charts um that's definitely a possibility i can like as a moderate i can spin up like one or two slides i mean we already have at least one right at least one so that the audience can ask questions from the picture right um i i think i shared that let me give me a quick second um i've got the slides actually actually uh ronal what i'm thinking uh if you if it will be easier for you we can like share our role of moderator especially for this introduction sides so i can i can i can ask you questions like okay well we form a group can you talk more about like what it is about and why and when you show a couple of slides and when i'm turned back all right something like that here's the slide deck that i have because i i had um i created a few slides um as part of um seg run times t o b chart or presentation um like um then there's a technical management meeting for what is the group there you go yeah there you go uh and and then you got a roadmap on the next one yeah those are good those are two good charts one of the key questions we need to ask in the beginning so why it's was formed on the seagrown uh seagrown time and on the cncf not on the recuper motors so what we'll open the area to to explain what we are trying to cover on the recuper motors but also our uh usages inside invite and by seagrown time a cncf seagrown time and on the not kubernetes it's probably and not kubernetes signode well i wouldn't outline specifically signal well who uh they own kubelet yeah i i know i know all the stuff i know all the run times why not sig instrumentation yeah i mean not not not just to pinpoint any of the existing sig groups in the kubernetes just saying like our use case is more wide than kubernetes like regardless what whatever area inside kubernetes it touches i do think it's lit it's useful to list the the sags that are related say a free instrumentation is important here like list them that's all well the instrumentation at some point things scheduling will be forward now i don't know security might be i mean that could be a question if you'd like what are the what are the kubernetes related kubernetes sags but yeah we can what might be more appropriate uh how about um the silent voices in the room uh what do they think the what voices the silent voices oh the silent example you you're you're vashy is am i pronouncing that right yeah hello hey what do you think what question should we be asking each other should i be asking you um i agree with the question so far i'm also thinking of what do we want to talk about nri at all are we just going to do a cdi for the panel that's that's really a great question i think uh we we just talked about it for an hour and we we can we can mention what we have for our discussions on going uh related to the devices because like devices not existing in the work room we have a bunch of our resources needs or well resources on the devices which needs to be also handled somehow so we we might mention but we are also looking at the scope which potentially can improve voice your eyes and improve what plugin mechanism here i would say nri hooks and cdi intercept right for runtime hooks no nri comma yeah oh yeah right runtime hooks right yeah runtime hooks um we might actually now that i'm thinking about it um because i i did a presentation um a month ago in um this work group that's called the hbc advisory council and i talked to a few runtime maintainers singularity saris um these um um i want to say smaller with big quotes um probably specialized run times for hbc um so maybe there's a question here around the fact that what about other runtimes so i i i i definitely think that to me um specialized runtime is is is i think it's it's important that we talked about and talk about the fact that we're not really just focused on these two kubernetes um runtimes but also um the the the more specialized runtimes and that there is conversation with them so like you're talking about um kata containers i mean kata containers is definitely another um runtime we'll we'll have to talk to actors that kind of stuff yep yeah by the way speaking of the vm-based runtime so we soon or later we will need to figure out uh how to inject in the devices where because if we are injecting only on the container start time it might be already too late because vm was already created and you can't hot block the device so it's again back to the discussion of uh getting the full pot stack and getting the full information about the container and i and i believe the sooner or later should probably be in the next okay yeah a lot of it a lot of that nri code is gonna have to live in the shames alex um eventually we'll get to that detail later but so if um if this is 45 minutes then we have let's say 15 minutes for external questions that leaves us with 30 minutes which is maybe six what are we trying to get out of the the panel right are we trying to get involvement from the from the you know from the audience so i would say at least two things as you're as you're saying um we want to have more involvement from from from runtimes and so that's probably what about other runt specialized runtimes is is one of these questions the other one that i think is important is that we want to share some of the thoughts with some of these other six so other people from kubernetes um just um not just share the question then and then the answers could be the you know the six like you said the six and specialized runtimes and so i think and and to me we need to make sure that there's a bit of nuance in our um thoughts and answers in that we probably need to be on the side of here are some of the ideas that we have they might not fit always with the six or maybe we haven't talked with all the runtimes and it's possible that um i mean you you you see where i'm going is that oh yeah absolutely uh that way we're describing an idea and that we're just here's the result of our work and it's possible that um not everything is done not everything will interact nicely so rinal is it is it fair to say when you set the tone you're going to say why this is important then i think is important yes um if you're gonna if you're gonna answer the why this is important question right then then we we just have to start when when we're gonna ask for help to the audience right yeah kind of then we're gonna question hopefully then we go to questions right by the way regarding the questions i would suggest to add one question is what is your specific use case for the device that's what you are trying to solve i mean from the cut from the people in the audience or from from from people on the panel on the panel that'll be you yeah you and uh rinal i think yeah so maybe then taking a step back i in these first three slides that'll be presenting um i can talk about why this is important but it's it's i think it makes sense that the first question is then what are the use case or whether it's the actual real world problem you're trying to solve right then this is what i think alex was saying that's a part of the why it's important that's right yeah yeah so it's not just something that i say immediately as part of the presentation it's also something that both um alex and i right so that maybe maybe this should not should not be cei specific right it's what you expect from and then maybe one of the answer could be from cdi and then from the cod work group right yep by the way or wash i i i don't know exactly what you are working on are you part of runtime or devices yeah i'm part of runtimes i work with rinal and cryo okay yeah yeah so all right so we have three people with double with runtimes and two people from devices okay i was also thinking maybe one question can be what our roadmap looks like like what we hope to accomplish in like the near future like what the plan is basically like an overview yeah he's got that that that's like five i think it was or was it six yeah but it's only a slide for the cdi oh yeah it needs to be and what's funny what's funny about yeah but that's that's an actual very important point because that was actually also one of the question we were asking ourselves in not the previous meeting but the meeting a month ago which is there's a lot of initiatives here we're trying to close on cdi but at the same time there's a lot of ideas that we want to be talking about so maybe that's something that we can probably or we need a slide out of and maybe that's something you want you can present alex because you have all these problems yeah i'll try to answer a slide thank you very much by the way i think that was like that was that's that's really an important point is roadmap is real use keys and roadmaps are going to be the big um or at least the big two things that we should be spending time on yep we're at and we're at the beginning of the road so this is the time to jump on guys we need help yep um what are the areas this group is involved is is i think also important okay so maybe last one um are we just getting more involvement and sharing the ideas or are there things that we want to be getting out of this kind of panel more so we have a set of ideas we have some draft and implementations we have background use cases why it's needed what we don't have is we don't have any representatives from like our runtime so we we're covering only like the major ones we're crying and complaining we need people from hpc world we need people from our like small runtimes we need vm based runtimes to to provide information what kind of challenges with devices we have um there's also non kubernetes users of cri we have non kubernetes users we have people with uh very strange devices which potentially like roadwork lagging and somehow satisfied but maybe also not not not not really satisfied but silent uh maybe we need those people to speak up uh we need to have information about more complex configurations we need to have information about more complex devices when you say devices covering resources too right not just devices yeah for example like well on on our gpu so fpg we have local rounds so we need to cover it but i don't know like some i don't know like weird melanox network card might have like internal buffers what you can somehow manage or something like that i think it's really important that we present the mental model um at some point if that makes sense of cdi mental model this is what i was saying to um michael this idea of docker run dash dash device rather than docker run dash v i think to me it's it's really important that we talk about this because it it it makes sense in everyone's head this this idea of saying docker run dash dash device versus docker run dash v is is something that really should be hitting people and hey that seems like a really important idea truly when we let's move it to us once like one of the first set of questions when we were talking about architecture and in introduction part if you want i can ask you a question on your answer what introduction to cdi in a way it's it's something that needs to happen here because we're we're really talking about use case roadmap but at some point we really need some kind of introduction to cdi and then maybe that's when we start explaining why we're sig run time in autocuban a sig what are some of the related sigs um how does nri and cdi intersect things like that right that's that's at least some pretty good amount of work um we should definitely try to think um at least try to maybe um like expand on these offline and then uh from there we probably need to um fix the um recording session and then um hopefully we'll only need one take but we all know we'll probably need at least two or three you're on your mental model run out um when you talk about docker are you gonna follow that up with you know or if you're using coop ctl there needs to be a transition this is the kubernetes sig i mean a kubernetes group right it's cncf but it's also you know it's mostly coop on right yep well that makes sense it's mostly it's mostly coop on but on other hand it's also sig run time so i think it's a fair question which is how does it looks like from a kubernetes end user is a fair question um yeah just you mean if it's only one sentence that should be fun right that makes sense right but still you know because most of the audience isn't going to know what kubernetes is right um but they they should all know you know what coop control is or coop ctl right coop go yeah but one another question is uh well uh cube ctl is fine but uh you need to have device plugin which actually will be exposing or making up that device so we like even if we let's watch today we implemented cdi we are great we don't have for part and the kubernetes will pass with information down i i think it's okay to present a bit how does it look like from a end user perspective right right yeah if it's if it's if it's a single sentence um it's it's it's not that bad uh right it's it makes a lot of sense to just try to um relate it to the audience relate it to the audience in a way um all right um um so let me see i'll i'll try to set up the doodle um asap and then feel free to all come back to this document um rewrite some of the questions um we'll probably have to assign some of these questions um if we only have six questions to ask and we have five speakers that's going to be fun oh who are the five speakers i i thought i didn't remember i'm just curious are we are are we four or five i forgot uh so mic rinald alex you're rushy and myself that's five ah there you go um hello you're rushy like brown i don't i don't know you're rushy okay nice to meet you we should have done that at least three meetings ago i'm sorry i was phased out you know i'm taking all the blame for for for not for for for not having or at least for not presenting each other how long is the slot for i i just joined like so um 30 to 45 minutes i believe uh might be wrong let me check so we want the back 15 for custom you know audience questions okay so we need to fill 15 minutes minimum i guess well i would say 20 to 25 15 minutes minimum um yeah we're now basically we're now going to give a couple of charts at the beginning to set the stage and then we'll just run through this list of questions and and then try to get some audience feedback yeah sounds good this schedule and then let me find it in the schedule just to make sure uh cod is the keyword i'm looking for so it is the panel is at three so we only have 35 minutes for the panel actually which means that we really have 15 minutes to talk or to ask each other questions so on your question on the what about other specialized runtimes are you talking about runtime engines or are you talking about container runtimes uh we need a vocabulary slide this is going to be fun this is going to be tricky so actually since we're all here let's let's let's very quickly um so this is what this is the what question um who asked this or who answers this what question all right not everyone at the same time please everybody um alex do you want to start with this one where i'll ask you this one and then you'll you'll talk about your use case and um please present my use case uh no i think i think alex is probably a good person for this one um roadmap uh mike do you want to present the roadmap i i think that should be done by you or not as a follow-up on the uh on the setting the tone that makes sense and i have no idea how i'm writing my name um and you might want to i would do the roadmap a little bit further down it's probably just before we go to audience questions yeah that's the last one yeah yeah probably at the bottom otherwise they don't know the vocabulary yet right so yeah yeah so the first question is is what like what we are doing why why it's important second question is what it's like how much it's different from existing solution so let's practically this uh mental setup what uh ronal mentioned yeah right why yes so so i can i can ask what and ronal you will be answering i'm not no no i'm not answering type one i'm already moderator and i'm presenting the roadmap uh so introduction to cd i should either be mernal or mike or your vashy all right uh i i volunteer your vashy yeah sure i'll do that all right um now we need questions to be answered from mike so next next next thing is uh like what is actually covered by it so the center i cdi things all together so so why cncf it's a bit later so first we like what is what is in the scope so scope yeah all right so who wants to volunteer someone all right your vashy you would get to choose if it's mike or ronal uh i guess i'll go with mike should i help i think i think it would be it would move us to probably have more than one person answer these questions as long as we can we can we can talk about them together so i would say mike and ronal should answer this question yeah i think sounds good i can cover the runtime hooks how they work and kind of cdi and mike can cover nri yeah so the next question would be okay so we we are we are talking to the scope when how it's all connected to the whole ecosystem when goes with question about cncf and sick kubernetes six and so on so where are we involved on how it's connected to our orcs or groups and in my community all right and i think this one is also going to be mike and ronal so remember we only get 15 to 20 minutes and then 10 to 15 minutes for questions so we the roadmap seems to be to me like it makes sense to be the last question yeah i think when when we first talk we should probably say then we should probably say then you know where we're involved and uh yeah so we can just move that where are we involved into the scope question makes sense all right no no no it's in the scope part yeah so so i think to me these yeah they are kind of the same question we can make it one question yeah yeah all right and you guys can do the same thing when you when you guys are talking about your yeah when you're showing the initial charts you can say you know what is what is the scope for you right and how are you involved right and then alice can talk about that as well yeah he can introduce himself and then or did you want to introduce people no we're just straight into it no mention of who we are well i would say like the first introduction not more than two three sentences yeah um by the way do you want to each other introduce yourself or you want me to introduce you no i think each each of us will will be better all right because at least it will say it was set the stage of speaking short and sweet elegan we know you got a lot to say i'm kidding i'm just pulling you away all right um i have a problem with the Russian language we have a long and uh loaded sentences so for when i'm speaking in in english i'm trying to repeat the same thing sorry no you do you do great i'm just pulling your leg where are the answers to these questions um i think everyone should try to write two or three bullet points feel free to ask these questions in the slack chat or in the slack direct messages if you kind of wonder if there are points that we're missing or maybe you think maybe we should translate these into slides and start filling out the talking points over there have like bullets over there and then if we want more details we put speaker notes or whatever there for having each other review those notes so um quick thought on this um these slides are talking point for us we shouldn't be showing these slides if that makes sense uh sure yeah but we can show with this we can send you to your charts that he was gonna throw up so the audience knew you know what they were talking about you know still high-level pick okay and then a roadmap picture i guess yeah okay um i'll set up the doodle uh or finalize the doodle bug the people who did not answer uh i think it's you docs uh shame on you and yeah i think um i'll repost the link to this slide and our direct message and that's it thank you everyone for your time that last one you're gonna show that that what are we getting out of this or you're gonna show some kind of chart with those bullets maybe just before the question the qa yes that might be a conclusion slide where it's just we want you to be involved um ask not what the uh cod working group can do for you but ask what you can do for the uh we need you for the cod working group let's listen it's not for us it's for cncf right yes Kubernetes all right and yeah definitely this is a slide yeah yeah we won't have any time i think sorry i didn't hear you i would say we won't have any trouble filling the time i think i didn't hear your question my question was is one person going to be asking all the questions or should we field the question after we answer our question yep i'm uh i'm i'll be i'll be asking you the question you will have a card oh i'll be looking directly into the camera oh man i yeah i keep forgetting we're not we're not actually gonna be like sitting on chairs in front of the oh man that's weird by the way uh if if you're using was zoom to to record and if you feel what you want to add something to the answer of our we can use this rice hand uh thing so at least uh mother mother reader can give chance to answer also definitely uh actually i i i don't know like this rice hand is going to be visible and recorded or not but no unless we're unless i don't think so um but i okay i i do think that for the q and a section where it's not recorded so we it's and it's not on zoom so um that q and a section i think it's recorded by it's recorded by the platform the q and a with people i think so well it might be published somewhere differently but i think it wasn't available in the platform so while while while the platform is still able to log in you see it okay um i'll let's ask nancy um and then figure out uh i mean we we we need to ask her to figure out what are the technical details to to do that anyways all right all share the same background so it looks like we're sitting in the same room uh let me see if i can uh where is that i actually created my own custom image from the last from theirs for me i asked it our support team said like give us something like provided wet one oh no nvidia is going to make me have the nvidia logo behind me that's actually not bad oh my device does not support virtual background so that's not oh oh i see uh container d up there yeah this is probably not here all right there's got to be a cryo logo in here somewhere all right you're you're hiding it it's behind your head oh yeah there you go no that's the kubernetes all right thank you everyone losty kubernetes logo in it something all right have a great one see you guys


What's up everybody, Jason here for jaskiescasebrakes.com. We're giving away the last eight spots in 2017 contenders optic Break with this 18 optic football one box mega box break number five random teams The way this works guys is first we do the break around my customer names and teams to distribute the hits out of the mega box Then at the end of the break we'll take all 32 customer names randomize them in the top eight get a spot in This break here that'll be coming up next chase patty Mahomes So let's do the break first. Let's roll it randomize customer names and teams six times four to two One two three four five Six rally the David six times here one two three four five Six I stick to what you got guys. There you go guys. Good luck Tom Brady elite Tanner Lee Wow, we got a redemption Edo Smith came in Ratley and Mark Walton rookie threads Calvin Ridley ready rookie Devonte Booker Minka Fitzpatrick and a Mason Rudolph ready rookie silver with Saquon Barkley ready rookie And a Michael Gallup bronze ready rookie that's exclusive here to mega box Jester and All right, let's see who this redemption is. I'm very curious this big banker Mayfield Raider rookie autographs bronze car number 189 Hayden Hearst, I believe that should be Baltimore Ravens, right? Yes Baltimore Ravens First round pick as well There you go guys. Good luck Here's the dice roller Last eight spots me getting away top a get in. Let's roll it and it is five out of three eight times. Good luck one two three four five six Seven Five hundred three eight times Top eight get in Shawn Dylan JC Aaron David Aaron David and Bradley. There you go Top eight get in so coming up next is the break it off


Okay, hello everyone, welcome to the embedded open source submit. Today, I and my colleague, Hebo, we will introduce a new ZFIR sensing subsystem today. My name is Kehan. I'm from Intel. I'm a principal engineer working on the integrated sensor hub solution, focusing on firmware, software, and algorithm. Hebo, maybe you can also introduce yourself. Hi, my name is Hebo Hu. I also from Intel and I'm a senior software engineer and working on integrated sensing solutions and focusing on software for development. Okay, thank you. Thank you. Okay, so this is a agenda item for today. The ZFIR sensing subsystem is a new concept we introduced this year to the community. So we will go through the background on why do we need it. Also, we will disclose our motivation on what is our goal. We will introduce in detail on how does it work, what it is in detail, what are the features, and also we will show an application on what it can do. We will update the status on how far did we go, what did we implement it, what is not yet. We will also show the demo on how does it work. And in the last, we will show our next step plan and also our roadmap schedule on this sensing subsystem upstreaming to the ZFIR. Okay, so we are very excited to introduce this new ZFIR sensing subsystem to the community today. We are also welcome to you if you want to participate into this development together with us. Thank you. So here is a background. So ZFIR today, as we know, already has a sensor solution introduced. So this sensor solution is based on device tree config. It supports the developers who develop the sensor device drivers with a lot of full sensing features, like sensing fetching, triggering, attribute calibration processing. There are already 140 device drivers in the ZFIR repo and more than 900 comets. So the typical sensor usages today on ZFIR is that the ZFIR application directly calls the sensor device driver and streams the data, configs the sensor in different working mode or behaviors. So this typical usage is very suitable for the simple sensor usages like IoT usages in which the sensor number is limited, application number is also limited. However, we think this sensor solution today still has a lot to improve. So for example, one improvement area is the sensor application today on ZFIR. They are directly interacting with the sensor device drivers in kernel space for all the sensor operations. So it is not that friendly for application to directly use a kernel driver. So there is a lack of high-level abstraction, general function management, multiple client arbitration, and high-level sensor API in the ZFIR sensor solution today. So here is our motivation. In one short sentence, our motivation is to take the ZFIR sensor solution to next level. So what we plan to do is to introduce a new sensing subsystem and framework to support a bunch of new sensing features, which is, for example, the sensor high-level abstraction, general function management, multi-client arbitration, sensor topology, scheduling, fusion processing, timestamping, batching, and so on. So the new sensing subsystem or framework is on top of the sensor device driver. So it will manage all the sensor device drivers in below, provide support sensor common features, and provide a high-level sensor API to the sensor application. So multiple sensor application can use the sensor subsystem to access to the sensor data or configure the sensor. And the sensor subsystem will provide multi-client arbitration, which allow the sensor application to freely use in the future without worrying the confliction with another application. And with additional component, our motivation is that we want to introduce this new sensing subsystem as a sensor framework in the sensor hardware. It will be able to support multiple OS meet multiple OS sensing requirement. And also the CHIE, the Contest Hub Runtime Environment, which is from the Google Android project and is already upstream of module in the Zephyr today. Okay, so my colleague Hebo will start to introduce the detail of the sensing subsystem. So, Hebo, please go ahead. Okay, now let's have a look at the new sensing subsystem architecture overview. So at the bottom layer is the Zephyr's current space. So it's the board BST drivers includes the IO purpose like the IAPC, S2C, I3C, SPI, GPIOs and other things. Also, we have the sensor device drivers like the extra meter sensor and gyroscope, 19 sensors. All of these are the existing sensor stack in the Zephyr's, in the Zephyr. And at the middle layer, it's our new sensing subsystem. It's in the Zephyr's user space. And it supports the high-level sensing subsystem APIs with the multiple client support and Zephyr's high-level APIs to support Zephyr up-layer Zephyr applications. So as the up-layer is the Zephyr's application application and it supports multiple sensor clients at the same time to using the same sensing subsystem APIs. Okay, so for the next. Yeah, this is a major concept for the new sensing subsystem. First, we have two kinds of the sensor abstractions. Includes the virtual sensor is focused on the sensor algorithms and the physical sensor is focused on wrapper for existing sensor device driver and the producing the sensor data to the virtual sensor. And all these two kinds of sensor abstractions were composed like train mode, basic sensors report to the virtual sensors and also virtual sensor can report to another virtual sensors. And based on this train model, we have two major passes, including the config flow and pass and the data stream flow pass. The config flow pass is from the top to the bottom from the application to the sensors. And the data streaming flow as well from the bottom to the top from the sensor driver to the same subsystem virtual sensor. And finally to the application client. The whole subsystem supports the multiple clients with the arbitrations. So each sensor can be opened and the conflict by multiple clients. So with each application client, no need to worry about the compression conflict with other applications. All this will be carefully handled by the sensing subsystem. For example, at the currently we can support the report interview arbitrations. For example, one application set 100 hertz for a S-meter sensor. And another application set 200 hertz for the same S-meter sensors. And the sensing subsystem will arbitrate the report interviews. And this thing using the subsystem can also support the Android SETRAE framework. So it can meet the SETRAE's platform obstruction layers requirement to separate the SETRAE. And also it can support the long SETRAE applications like the HID sensor application to support the Windows clients. And also can support the MQTT Zephyr-related applications to support the IoT products. Okay, next. Okay. So Hubo just introduced a core concept of the Zephyr sensor subsystem. So in this page, we have a table listing the Zephyr-sensing subsystem features. So the scope of the Zephyr-sensing subsystem is focusing on the sensor fusion arbitration, sampling, timing and scheduling. So we will provide a sensor abstraction which is the physical sensor and the virtual sensor concept. And we will provide different data-driven model pulling mode and the interrupt mode. The sensor will be scheduled in the Zephyr-sensing subsystem. And also there will be batching support power management. And we will rely on the existing Zephyr APIs, like sensor APIs, task memory, RTIO and everything, all the sensor object will be configurable from the device tree. And our design principles is, we will take a reference from the Intel proprietary ISH sensor framework design, which was already mass production for more than 10 years with active evolution. Our solution will be fully open source as a Zephyr-native subsystem. So we already started our upstreaming work in 2023. Our first PI is the end-review and already submitted and more PRs is coming later. So and we are working together closely with Google on this upstream work. So the Zephyr-sensing subsystem will be fully configurable. Our key idea is to make it a reusable standalone subsystem. So which means that it will be configurable and also flexible as Herb was just said. It can support multiple different applications like HIE, like MQTT, like HID or proprietary applications. And in the next few pages, we will show an example of the new Zephyr-sensing subsystem application and also the demos of how this work on the real board. Okay, so, okay, so, Hebo. Okay, and this is the example application for the Intel's integrated sensor hub inflation for the Chrome OS. So the Intel's integrated sensor hub, it's integrated microcontroller integrated into the Intel's client SOC. So for the diagram, as you see, in the bottom, there are as such related BSP drivers, like the permasement and the money purpose. And for sensor drivers, we will reuse the existing Zephyr sensor device drivers like the S-meter sensor, GRO, Mac, RS sensors. All of these sensors will reuse the existing Zephyr ecosystems. So based on this existing standard sensor device driver API, we will have fully reuse the new sensing subsystem to measurement the whole world sensor subsystem and with the virtual sensors, which will be required by the Chrome OS next lead angle virtual sensors will be implemented as a virtual sensor with this new sensing subsystem. And based on this new sensing subsystem APIs, we have the Zephyr applications and in this Zephyr application, we have two host link clients. One is the HID host link client, which were wrapper underlying sensors from the sensing subsystem and the wrapper to the S standard HID sensors and exposed to the Chrome OS host through the HID and IIO driver stacks. These stacks are already existed in the Linux driver code. So all of them will be reusable. And another client is the HID host link client. It can consume the same sensors with HID sensors and HID client at the same time. So with the Satcharii framework, if you have some sensor features which want to dynamically overload from the host to the sensor hub, so you can use the Satcharii stack as the meanwhile. Okay, and later we will have a demo video to show all of this, okay. So next we have a look at current status. So at the current already, we support the Intel Chrome client reference platform sensor bombs, next estimator sensors, hinge angle sensors, virtual sensors and AR sensors. And with the features we have implemented as all the sensing subsystem APIs, but except the batching. The batching is still working in progress. And the whole function framework with the physical sensor and the virtual sensor obstructions and already implement the multiple clients with the Satcharii and HID sensor applications running at the same time. For the multiple oppression, we now support the sensor report interview and the data change sensitivities. We, at the current, we never did the standard Zephyr sensor device APIs for the physical sensors. So all the physical sensors, we reused the existing Zephyr sensor device driver just as we mentioned in previous pages. And we fully support the calling and the interrupt data driven models with the single thread scheduling. And all of this can be conflictable with the device tree. So in the device tree, you can describe the whole sensor topologic, topologics and the relationships. And we also implement the end-to-end sensor streaming data path for both the HID IO path and the Satcharii path. So later we will see this in the demo video. And we have started the stream work. The first proposal has been reviewed with Zephyr committee and the first PR has been submitted and now it's under reviewing. Okay, next to how to see the demo video. So we have two demo videos here. One is the demo which on the Intel's client reference board with the SSH to support the Chrome OS. And another example shows it how the sensing subsystem working with steam sensor bombs running on the ARM based board. Okay, let's first to have the demo with the SSH, Intel's SSH. Let's demo the physical Excel sensors and hinge virtual sensor data streaming through the CHRE path. Here is the demo with the Chrome OS running on End-to-Lake P development platform. The left side is the ISH formula log output through the URL port. The right side is SSH console from Chrome OS host. This line is a physical Excel on the base. We can see the base Excel data on the XYZ. It's a unit is a micro G. Since it's lying flat on the table, the value of Z axis is close to one G. This line is a physical Excel on the lit. We can see the lit Excel data on the XYZ. Since it's a vertical to the table, the value of the Y axis is close to one G. With all the data from the two Excel on the lit and the base, a hinge virtual sensor is created. And we can see the degree of the hinge is 96 degree from the log. Next, let's demo the physical Excel sensors, motion detector sensor and the hinge virtual sensor data streaming through HID path. IIO sensor tool is a command line tool based on Linux IIO system. Here we use IIO sensor tool to enumerate all the sensors information, including sensor index and the names. We specify the value of index to be three to show lit Excel data. And here the minus N30 means fetching 30 samples and the minus F100 means setting the frequency to 100 hertz. Then we can see the lit Excel data on the XY and the Z. The unit is meter first, square second. The other Excel sensor is base Excel. We specify the value of index to be one to show base Excel data. Next, the sensor is a motion detector sensor. We specify the value of index to be four. The minus T30 means fetching samples for 30 seconds. When the motion detector is moving, the data is changing from zero to one. And after standing still for a while, the data change back to zero. Here to show hinge angle sensor, we specify the value of sensor index to be two. When we close the lit, the data is approaching to zero degree. When we open the lit again, the data changes from zero to 180 degrees. Thank you for watching the demo. Okay. Let's have a look about another demo which was running on an armored open board. This demo is enabled by Tom Bardick. So thanks for his efforts. Great efforts. So with the syncing subsystem, the syncing supports the same sensor sensors, like the two estimator sensor and the two watcher sensors next to hinge angle and motion detect. Okay. So next curve are introduced our next plan. Okay. Thank you. Okay. So this is our next plan. So our goal is to catch up the Zephyr 3.6 LTS build, complete the Zephyr syncing subsystem upstream work by the Zephyr 3.6. So right now we are introducing the Zephyr sensor subsystem call with the PR submitted in Zephyr 3.4. And we will extend the features and the board support in 3.5, stabilize the solution by 3.6. And in the meantime, we are closely working with Google on enabling the Chrome production support. We will enable the Zephyr sensor subsystem in Google and the Intel Chrome production, meeting all the production requirements. And we will also enable the Intel ISH with the latest the UPX Open Development Board, like the one that just shows the arm open board there is also a Intel ISH open board as well. And furthermore, we will introduce the more and more advanced the sensing features to this new sensing subsystem, which includes the CHI Antoine support, the CROSS OS support with the HID sensors, the human presence sensing, which is a pretty hot topic in the client sensing world today. We will add the sensing batching, which is right now is still working in progress. We will also support the multi-stread processing, which is the important for some heavy workload algorithm processing. And so on, yeah. So, okay, so that's all for our presentation today. And welcome to the embedded open source submit and join our session. And if you have any questions or any interest, just feel free to contact me or help. Okay, thank you very much. Thank you.


Hello and welcome to this session. This is Professor Farhat in which we will discuss target costing. This topic is typically covered in cost accounting, managerial accounting, as well as the CPA exam. If you want to see additional lectures like this one, please visit my website farhatlectures.com. You will also find additional resources to supplement your courses or to study for the CPA exam. So when do we use target costing? Target costing is used when we are a price takers. What is a price taker? Price takers means we don't have an option. In other words, we don't set our own price. Why not? Because we are not selling a unique product. Well, it means our product is in the market that we are selling and everyone is competing on price. For example, when Apple came out with their first iPhone, Apple was a price setter, not a price taker. What do we mean by price setter? So price taker versus a price setter. Price setter means the company, Apple could have did not have to look for someone else to determine the selling price of the phone. They can set the price. Why? Because their product is unique. Here we are dealing with not unique product. Therefore, we are price takers. If we're not selling something unique, then we have competition. So what happened under those circumstances? We're going to look at the selling price. We're going to look at how much revenue we can generate by the market. Well, mainly by our selling price. Then we're going to set our desired profit motion. How much profit do we want to make? So simply put, it's a simple formula that you have to be familiar with. And basically, you have a target price. Wherever your price is, then you subtract your desired profit. How much profit you want to make, you'll get to your cost. Now, you could rearrange this formula. You can say cost plus profit equal to price. It doesn't matter. So let's assume, you know, you can sell something for 300. You'd like to make $30 in profit. Therefore, it should cost you to make $270. Now, what happened if you cannot manufacture this item for $270? Well, if you can't do so, you have to accept the lower profit because you can only sell it for 30. Or try to differentiate your product. So this way, maybe you can increase the selling price if you can. Or re-engineer the production process to lower the cost. But basically, this is what you have to do. The best way to illustrate this target constant is to work a couple of quick examples to see how this simple concept... Well, it's simple once you have it down. Market research indicates that a new product can sell well in the market at $21. So this is basically the selling price, $21. The company desired an operating profit of 20%. So remember, the selling price would include the cost and the profit. What do I mean by this? So simply put, your selling price should equal to the cost plus the profit, because the selling should recover your cost and give you some profit. Here, the selling price is $21. What we are saying, the $21 should give you your cost plus your profit. What we are saying here is, your profit, our target profit should be 20% of the cost. So we could replace profit by 0.2 of cost. This is what our profit is, 0.2 of cost. Well, let's complete this simple algebra. $21 equal to 1 cost plus 1.2 cost equal 1.2 cost. Now if you want to isolate cost, well, we can say cost equal to... We're going to divide both ends by 1.2, 1.2. So now we isolate cost, cost equal to $21 divided by 1.2. Now we can find our cost. So let's go ahead and compute this. $21 divided by 1.2, that's going to give us $17.50. Therefore, our cost is $17.50. So our cost is $17.50. Therefore, the profit is the difference, whatever the difference is. So what is our profit? So minus 21. So our profit is $3.50. What does... Sorry, I shouldn't have done this. So what does $3.50, 3.5 represent of 17.5? It represents 20%. Therefore, it's exactly what we did. We wanted our profit to be 20% of our cost. So hopefully this make sense. Let's take a look at another example. Let's take a look at another example. Market research indicate that our headphones would sell well in the market for a price of $149. Good. So we know the price that we can sell it for. The company desire an operating profit of 25% of cost. So how much what's the highest acceptable manufacturing cost would be willing to produce this product? So remember, we have $149 in total. It's going to cover our cost and it's going to cover our profit. Now, what do we know about this $149? We know if we take the selling price, it should equal to our cost, which is we don't know, plus it should give us 0.25 of the profit. Well, this is cost, let me do cost plus profit. $149 should give us cost plus profit. $149 equal to cost. Again, the profit is what? The profit is 0.25 of cost. Now $149 equal to $1.25 cost. Now if we divide $1.25 by both sides of the equation, we're going to get $149 divided by $1.25, $1.25. Let me just erase this and make it a little bit higher here. So $149 divided by $1.25 equal to the cost. Now again, we can do the same thing and figure out what is our cost. So our cost is $149 divided by $1.25. Our cost is $119.20. Again, the cost is $119.2 and the profit is, let's see, $119.2. I'm going to take the difference with $149. The profit is $29.80. Simply put, what does that mean? It means the, so if it's going to cost us more than $119.20. So simply put, when we manufacture those headphones, whether we are incurring variable costs such as, if we are incurring direct material, direct labor, a variable, manufacturing overhead, manufacturing overhead, when we do this, it should not per unit. We want it to cost us no more than $119.20. This is what we're saying. So the cost should not be higher than $119.20. If it's lower, it's great. If it's lower, if this is, let's assume this is $1.10, then guess what? If we can sell it for $149, our profit will go up. If you like this recording, please like it and share it. For additional recordings for managerial, as well as cost accounting CPA lectures, I strongly suggest you check out my website, foreheadlectures.com for additional resources. Good luck, study hard, and most importantly, stay safe.


Seven, six, five, four, three, two, one. So, let's go! What's up guys, welcome to today's vlog. Today I've got something pretty cool for you guys. My friend Shrek is coming in to get his haircut. So we're gonna do this men's cut. And the cool thing about this cut is that we don't do a tight fade. We give it texture, movement, and I also left a little bit of a fringy kind of feel right in the nape area. So it's pretty cool, unique. I think you're gonna like it. Let's get started with the step by step. Here we go. All right guys, so we're gonna start off. I did shampoo Shrek before I cut his hair. He had some product in his hair. And I think a lot of times we jump right into a haircut and we're like, let's just start cutting it. But it's good to get that product out of there. And then what I'm gonna do is go through and do a blow dry because Shrek has quite a few callix within his hair. So he has a nice fine texture of hair and a lot of callix. So you can see how that kind of pops in the back. And what I'm doing is I'm taking my Ergo paddle brush. I'm working the hair back and forth. What that's gonna do is work out that callix. So we're creating with the heat on the blow dryer. We're creating flexibility within that callix. So it allows the hair to fall exactly the way that we want it. I'm gonna do the same thing on the front. So I'm pushing the hair back and forth. What that's doing again, using that heat to create flexibility in the base. And then that's pretty much it. So once I got the hair dry, then I can go in and start my cut. Now this is a typical salon reality situation. I didn't wanna completely change his cut when he came in. He said, you know what? I don't wanna go as short as we've been going. So what I wanted to do is just kind of alter the haircut that he has and create some textures. So I'm using my T-trimmer, went around his ear and then I went through and I just did a little detail work with that fringy area in the back. Some would call it kind of like, if it was any longer would be like a soccer mullet in a way. This isn't mullet-y, it's just letting the texture live. And also you can notice that Shrek has a lot of calyx in the back of his hair. So having that extra length is kind of fun to play around with. So doing a lot of trimmer over comb, what this is doing is just cleaning up the shape. So I'll look at if there's any weight imbalance within the haircut. It shouldn't be that much cutting because we've already done a pretty good haircut on him prior, let's say three weeks ago, four weeks ago. So he has a pretty structured cut in there already. So I'm just making some adjustments to it using the trimmer over comb. Same thing on this side, pick up the hair. I'm using the looser teeth of my 339 comb from YS Park and just going through there and like I said, cleaning it up. So now what I'll do in that fringe area in the back is right at the nape, I'll lift the back hair up and then cut underneath it just so that he doesn't have neck hair. I mean, that's not really a style. So I wanna go in, I wanna leave it longer in the back but take away the neck hair. So we just kind of go underneath it. So now I'm gonna move into my scissor work and the scissor I chose to use today is the Mizetani DB20 scissor. This is pretty much my go-to scissor for everything. It's a 5.7 inch scissor, has a lot of power because of the shorter blade and also it's nanopowder metal steel which helps grip the hair, has a more consistent cut and stays sharper longer. So this is a scissor that we have available on freestyleneducation.com if you wanna check it out but it's definitely my go-to favorite scissor. So I'm gonna be working in the calic areas. You'll notice I elevated the hair quite a bit but I don't wanna over-direct any of his calic area. The more over-direction I do, the less control I'm gonna have in the back. So I'm just pulling the hair straight out from where it wants to live and that's where I cut it. Because I did the blow-dry earlier, it gave me that flexibility in the base of the hair. So when I go through and I cut around the calic, I get that nice fall. The challenge is we have to be teaching our guys how to style their hair, how to blow-dry their hair, what product to use. Because the biggest thing here is that if I don't teach him how to blow-dry his calic, then he's gonna take his wet hair, he's gonna throw product in it and then it's gonna have that separation in the back. The style's not gonna look like it does when I'm done with it here. So we need to make sure that we're coaching our guys on how to style their hair at home and maintain the look. A blow-dry on a guy's hair takes five minutes. I blow-dry my hair every day. Even though I wear my hair kind of crazy up and out of control, it's still blown dry because the product is more effective that way. So I definitely wanna get into this part. This is a slide cutting. What I'm doing is a half close of the scissor. So I comb all of his hair kind of forward towards the front and what I'm gonna do is just slide cut through and create some texture in the front fringe. I wanted to leave a little more density in the front of Shrek's hair because it gets a little bit weaker and he has that kind of finer fabric of hair. So as I cut through it, I wanna make sure that I keep the length in the hair, but just add a little texture to it, which will thicken his hair in the long run. So if you think about, if I just left it long and bulky on fine hair, sometimes when you add product to that, it makes it just look still fine. But if you add texture and pieces and movement, once I add that product to it, it kind of brings it to life and it makes it actually look fuller. So we're just going through this. At this point, I'm pulling the hair up. He's gonna wear his hair off to one side. So I over direct the hair towards me, which just softens it and allows it to fall the opposite direction. So you can see how this shape is starting to form. It's nice and clean through the sides. Gets a little bit longer towards the nape and also it's longer and textured on top. I'm gonna do a little detail work with my DB20 throughout the sideburn area. Just to clean that up, I don't always have to go through with a trimmer and really create a harsh line. Sometimes on a more textured cut, I like to have a softer feel. Even go up the hairline a little bit with the point of the scissor. And then the last thing that I'm gonna do, this is a really cool technique I learned a long time ago. Check out Ira Pope Sage on Instagram. It's at Ira, I'll spell it. It's at Ira Pope Sage. This is called shingles. It's something that he did a long time ago, but it's a technique that I keep in my toolbox for later use. And when I'm doing guys hair and I wanna create a lot of texture, this is a great way to do it because it's pretty harsh, but with finer texture hair or even thick hair, when you go in and you cut these just chunks out of it, when you put product in the hair, it just really comes to life and it adds a lot of texture. You could see the like valleys in the hair, the depth in the haircut. But once you comb it out, it pretty much goes away, but once you add product to it, that's when you really see it form. So you can see how it takes the chunk out, but then as soon as you comb it, it disappears. So, but once you get that product in there, that's when you'll see it really change.  Now this blow dry is a little bit different than the original one because we're not trying to smooth out any callix or anything. We're just getting rid of the loose hairs, but also blow drying it in the direction that I actually wanna style it. So if I wanna give it some volume at this point, I can do that. I'm going through with a little bit more of a smooth out blow dry. And now I'm gonna add my product, which is today Mitch Reformer by Paul Mitchell. This is their men's category, men's line. So I'm gonna go through. Reformer has a pretty solid hold. I would say it's not the firmest hold you've ever had, but it's definitely a product that will hold your style all day. If you want something with a little firmer hold, you can go with material, which is in the same line, but has definitely a really firm grip. So we're gonna add this. Now what I want you to focus on is I take the product, put it all through my hands, basically turn my hands white, and then as I start to work the product in, I start in the back. The back of his head has the most density. So why would I wipe all of the product, the thickest part of the product on the very front of the hair? I wouldn't wanna do that because then it would just create too much separation and make his hair look thinner. So I start in the back, start wiping the product in, work it around the calic area, then through the top, then the last thing that I do is work the front of the hair. That's really gonna help saturate the hair with the product evenly. I think a lot of guys have that challenge where they just take the hair, put a bunch of product in their hand, and they're wet hair, and they shove it up into the front. There's nothing good that's gonna come of that. If you put product in your wet hair, it dilutes the product like we talked about. It dilutes the product, you don't get to hold all day. So just learn the blow-dry, work the hair back and forth. I honestly, I keep a blow-dryer right next to my bed. It's already plugged in. I blow-dry really fast in the morning, takes me five minutes, and then I go through, I put my product in, and we're good to go. So my process does not take any longer, but you could see the difference in the result. You get that texture, his hair looks a lot thicker than it would if it was styled wet, and you really get the right outcome from the product as you put it through. So now what I'm doing is just some detail work.  This is the end result. This is one of my favorite haircuts I've probably ever done. So I hope you guys like it. Let me know in the comments below what you think, and if you have any questions, let me know as well. Thanks for watching. All right guys, and if you like Shrek's cut, then hit the like button, hit the share button. Share this video with all of your friends out there. And also if you want to save 20% on freesaloneducation.com, on scissors, carving combs, brushes, all different kinds of products, then use the code MATBEKVLOG at checkout. You'll get 20% off your purchase. Thank you guys so much for watching.  That is our website, where we put all of our FSE partner salons.  So thank you guys for watching. Thanks for the support. I'll see you guys on the next video. Thanks.


Collisions happen when two or more objects come into contact with each other and a transfer of momentum and kinetic energy occurs. Collisions occur every time you hit a baseball, bounce a basketball, or play pool. When objects collide in the absence of external forces, they form a system in which the net momentum of both objects before the collision equals the net momentum of both objects after the collision. There are two types of collisions, elastic collisions and inelastic collisions. An elastic collision is defined as one in which no kinetic energy is lost, no damage is done to the objects involved, and there is no generation of heat. In the real world no collision is perfectly elastic because so many other forces come into play like friction, air resistance, and gravity. However the game of pool offers a fairly good elastic representation.  When the cue ball hits the resting 8-ball, it sets the 8-ball in motion. Having transferred all of its momentum and kinetic energy, the cue ball comes to arrest. The net momentum of the cue ball before the collision equals the net momentum of the 8-ball after the collision. Momentum and kinetic energy are transferred and conserved. If the 8-ball is already in motion when a similarly moving cue ball collides with it, then the 8-ball will gain some of the initial cue ball's momentum and the net momentum before and after the collision will be conserved. If the 8-ball and the cue ball are traveling at the same speed and collide head on, then they will bounce off of each other with the same momentum but in opposite directions. Their momentum and kinetic energy are transferred and conserved. The second type of collision is an inelastic collision. In an inelastic collision momentum is still conserved but kinetic energy is lost in the system resulting in the creation of heat and damage done to the colliding bodies. Bodies that are involved in an inelastic collision end up entangled with each other or stuck together. A clear example of an inelastic collision is a car crash. In order to understand the conservation of momentum in this example, we'll imagine a car crash taking place in a world where road friction and air resistance have no bearing on the system. Let's take two cars, A and B, with equal mass. Car B is parked when car A plows into it head on at a velocity of 10 meters per second. Kinetic energy is immediately lost as the cars become mangled and stuck together. Some energy is converted into heat. Momentum after the accident however is conserved. With no road resistance, the doubly massive car wreck will continue moving in the same initial direction as car A but at half the speed. The after collision momentum is easily calculated using the conservation of momentum equation. Where the mass of car A times its speed of 10 meters per second before the collision is equal to the mass of car A plus the mass of car B times the final velocity after the collision. Rearranging the equation to solve for the velocity after the collision gives 5 meters per second.


Calling all CEOs and HR professionals, do you want to win the war on talent? I assume so is one of the most common challenges I hear from my corporate clients is the difficulty they're having winning the war on talent. Well, the very first step to winning the war on talent is not letting talent leave. How do you do that? You create a culture where team members feel safe, valued, respected, included, supported, appreciated, and cared for.  You create a culture where team members feel aligned with your organizational core values, mission, and vision, feel like they are fairly compensated and feel like they have a voice in how they perform their work. You create a culture where team members know their role, embrace their role, and take pride in starring in their role to the best of their ability. Where communication and feedback is open and honest and where accountability is welcomed, given graciously and received gracefully. You create a culture where the organizational beliefs and personal behaviors are congruent. What we say we do and what we do is aligned. Where team members feel they are improving, developing, and evolving and where they have a crystal clear path of career growth and advancement. You create a culture so strong that team members don't want to leave. Dr. Gary Chapman, the renowned author of the Five Love Languages, conducted a massive research study years ago and found that 70% of U.S. employees across a wide variety of industries felt underappreciated and 64% of them left their job because of it. Geez, that is equal parts staggering and unacceptable. As leaders, we need to be very intentional in showing our team members how much we appreciate the sacrifices they make, the effort they put forward, and the work they do. Rare and extraneous circumstances aside, no one, and I repeat, no one, leaves a job they enjoy, find fulfilling, and where they feel appreciated. I said it before and I'll say it again. The first step to winning the war on talent is not letting talent leave.


Hi everyone, it's MJ and in this video I want to answer what is the null hypothesis and why can't we accept it? Now with all of these stats questions I like to start by first looking at the big picture and the big picture is that in statistics We have some data. We calculate some things known as statistics in order to get information About parameters and distributions of this thing called the random variable that generated the data in the first place Now where hypothesis testing comes in is hypothesis testing says hold on Let's actually so yeah hypothesis testing. Let's actually make a guess Okay, it's a fancy scientific term for guessing and what we're doing by guessing is we're kick-starting an Investigation we're then gonna carry out a whole bunch of you know tests and We're then gonna gather some evidence from them and we're gonna see if we can either reject or Fail to reject so this brings us to the second part of the question if we know that the null hypothesis You know, what is it? It is a guess that kick starts an investigation We now I need to ask why can't we accept it? Why do we use this language of reject and fail to reject and This is because when we carry out these statistical tests. We are not 100% certain and This is where stats does become a little bit philosophical because if we had to start using the word accept It means that what we're accepting is there for the truth So let's maybe take a step back from philosophy and just look at a very quick example Let's say our null hypothesis is that the parameter that we're looking after is going to be equal to the value of 20 and then let's say we create a confidence interval where the statistical test that generates the confidence interval Gives us the following we have 25 and 30 and this is at a 95% confidence interval because our Parameter value or our guess of 20 does not lie within the confidence interval We can safely say that we reject it But if the confidence interval was say 18 to 23 With the say a 95% confidence interval. We now say fail to reject and the reason for this language like we said is Accept means truth and we're not a hundred percent certain In fact, we know we're not a hundred percent certain because of the fact that these confidence intervals are only at 95% and and what this basically is telling us is that five times out of 100 The confidence interval is going to be letting us down and we've got two types of errors So we've got these errors types of errors We have type one and we have type two Now type one error is when we reject the the null hypothesis But it is actually true. So over here. We reject Our null hypothesis even though it is true Type two is when we fail to reject The null hypothesis Even when it is false and because this is seen as more of a problem or because we want to try and Communicate the fact that we don't have a hundred percent certainty in our statistical test We prefer to use the language of reject and fail to reject rather than the word Accept as this would imply that we're certain that the parameter that we've guessed is true And because we're not a hundred percent certain we therefore use this language of fail to reject Now in most exams you will lose marks if you say accept rather than saying fail to reject So this is an important thing that you do understand so you don't make a mistake in the test that you write But as always if you guys have got any questions, please feel free to ask me and y'all check out the Udemy course for more videos on Statistics keep well. Cheers