Welcome myself Giridhar Jain, Assistant Professor in Electronics and Telecommunication Engineering, Vulture Institute of Technology, Sallapur. Now today, I am going to explain Holtage to Holtage Converters. Learning outcomes of this session are, at the end of this session, students will be able to draw, circuit and derive expressions for output voltage for fee-to-fee converter. And second output, students will be able to design Holtage to Holtage converter. Contents of this session are, fee-to-fee converter circuit and transfer characteristics, derivation of output Holtage and design of fee-to-fee converter. So, this figure shows the circuit diagram for fee-to-fee converter. This is first op-amp and this is a second op-amp. So, 741 is used as an operational amplifier. If we look at the circuit, the first operational amplifier is connected as inverting summing amplifier, where there are two inputs, one is fee-in and second is fee-os. Fee-os is the offset Holtage, which is obtained from a potentiometer RP, where variable point is connected, where there is a fee-os and plus fee and minus fee are the power supplies. Second operational amplifier is connected as a inverting amplifier with RF is equal to R and R1 is equal to R. Therefore, gain of the second stage is minus 1 and this is the transfer curve. So, output versus input. When input changes from fee-a to fee-b, there is a corresponding change in output is fee-o-a to fee-o-b as shown in figure. Derivation for output Holtage, first operational amplifier is a inverting summing amplifier. Therefore, fee-o-1 is given by fee-in minus RF by RI minus fee-o-s RF by ROS. Therefore, taking this minus sign outside fee-o-n equal to fee-in RF by RI plus fee-o-s RF by ROS. Second op-amp is inverting amplifier with gain of minus 1. Therefore, fee-o is equal to fee-in RF by RI plus fee-o-s RF by ROS. Now, if RF is equal to ROS, then fee-o becomes equal to fee-in RF by RI plus fee-o-s. Therefore, this is equation of straight line Y is equal to MX plus C, where M is the slope of straight line, which is M is equal to RF by RI and C equal to fee-o-s. So, C is the intercept on Y axis. So, here Y is fee-o and X is fee-in. Now, slope of the transfer characteristics can be obtained by this formulae. So, this is transfer curve. Input varies from V-A to V-B and output varies from fee-o-A to fee-o-B. Therefore, slope M is given by delta fee-o upon delta fee-in that is fee-o-B minus fee-o-A divided by fee-B minus fee-A. Now, pause this video and think on following question. What is maximum output voltage of this fee-to-fee converter circuit? Maximum output voltage of any operational amplifier circuit is limited by plus fee-sat and minus fee-sat of the op-ohm used in the circuit. So, in this circuit, 741 is used as op-ohm and plus fee-sat and minus fee-sat depends on the plus minus fee-c-c. So, it is approximately 1 volt less than the fee-c-c. So, design of fee-to-fee converter. So, let us solve this design example. So, design interfacing circuit for conversion of 2 to 6 volt input voltage into a equivalent of 0 to 5 volt. Now, solution, the circuit diagram for which we have made the derivation earlier, same circuit is used and for the circuit from the given data. So, it is given that the input changes from 2 to 6 volt and output changes from 0 to 5 volt. So, from this, a slope m is obtained by the formulae m equal to delta fee-o divided by delta fee-in that is fee-o-B minus fee-o-A divided by fee-B minus fee-A. Substituting the values, fee minus 0 divided by 6 minus 2 equal to 5 by 4 that is 1.25. Therefore, m is equal to RF by RI 1.25. Therefore, RF is equal to 1.25 RI. Now, select RI is equal to 1 kilo ohm. Therefore, RF is equal to 1.25 kilo ohm. To find the offset voltage fee-o-S, we use the equation fee-o-B equal to fee-in-B into RF by RI plus fee-o-S. Substituting the values in this equation. Fee-o-B is 5 volt. At that time, fee-in-B is 6 volt. RF by RI already we have obtained as a 1.25. So, plus fee-o-S. Solving this equation, we get fee-o-S equal to minus 2.5 volt. Now, this is the transfer curve of the design. So, in this transfer curve, input voltage varies from 2 to 6 volt and corresponding output voltage is 0 to 5 volt. So, this is transfer curve of the design. Now, complete circuit diagram and the component list is given as below. So, this is the complete circuit diagram. So, in this circuit diagram, the component values which we have calculated earlier are RF is equal to ROS that is equal to 1.25 kilo ohm. Now, all the resistance used in the design are quarter watt. Now, after selecting RF and ROS, let us calculate RI. Now, RF is 1.25 RI. Therefore, RI is equal to 1 kilo ohm. Now, in the second design, this is resistance R. This is resistance R. So, both are equal. Therefore, RI is equal to R is equal to 1 kilo ohm. Now, this is R compensation. So, R compensation is obtained by taking the parallel combination of RF and RI. So, it is parallel combination of 1.25 K and 1 K which comes approximately to 560 ohms. Now, RP. RP is a potentiometer. So, 10 kilo ohm linear potentiometer is used as a RP. Now, select power supply voltages as plus phi is equal to 12 volt and minus phi is equal to minus 12 volt. So, these are the power supply voltages plus 12 and minus 12. So, now this is the complete circuit and these are the component values. All resistors are quarter watt and this power supply is plus 12 volt and minus 12 volt is a regulated power supply. These are references, operational amplifier and linear integrated circuits by Ramakan Gaiquat, PHI publisher and second is electronic system design by Vaibhav Tarate, Electrotech Publications Satara. Thank you for watching this video.


The webinar series, these series evolved from sessions that were held by the PTAILs regarding updates to their projects at each summit. We converted them into webinars to extend the reach of these events beyond the summit. Today our PTAILs are going to update you on what may be new for Juno, as well as detail any other items of note for users and operators. So we're joined today by David Lyle with Dashboard and Kyle Mestri with Networking. David is going to present first and then Kyle. So, David, let me put your presentation, presentation mode and there you go, when you're ready. Thanks for the introduction. Yes, so I'm David Lyle. I'm the Horizon Program PTO and today I'll just give you a little bit of an update on what we're looking at for features for Juno. First one to start out with, so recently inside OpenStack, we've tried to get all the projects to be a little bit more unified on how we represent ourselves and details about it. One of those items of consistency is having a mission statement for each program. So just wanted to start out with the one for the dashboard program and here it is, to provide an extensible Unified Web-based user interface for all integrated OpenStack services. So one of our key goals is extensibility. We realize that whatever we deliver in OpenStack Dashboard is not going to be enough for most operators out there. It's good for a proof of content platform but there's going to be, you know, either proprietary features or extensions that people want to load in. If you're running a public cloud, you're going to need something about billing, you're going to need a lot of different monitoring, that sort of thing. So one of our primary goals is making the dashboard extensible so that companies that pull it down and want to use it can add those extensions and those modifications, do a little bit of branding as well to provide a user interface that will work for them. I also want to point out that it's a unified Web-based, so the unified part is saying that really we don't want a bunch of disparate user interfaces across OpenStack. We're trying to have the services managed in a singular graphical user interface. Obviously the CLIs also exist and the APIs are available but as far as the graphical user interface, we want them to be in one unified piece of software. And then the last piece is where we're supporting all integrated OpenStack services. So there's different stages in the life cycle obviously of becoming part of OpenStack and we don't pull them into the Dash, pull these, or support the services in the dashboard until they are integrated but at that point we definitely do want to have support for them in Horizon. And along those lines, so one of the key features for Juno is Sahara has come, the project has completed incubation and then graduated and become part of OpenStack and so we want to integrate a lot of the great work that the Sahara team has done on Horizon component into Horizon proper. So they developed it alongside Horizon and right now we're in the process of pulling support for Sahara and so you can manage your Hadoop clusters from Horizon in OpenStack, so that's slated to be here in Juno pretty quickly. So another large item that we're working towards is a richer user experience. So we have a large amount of API support but we really want to focus back on making that API support usable and so there's some areas we're concentrating on for most users of Horizon, the primary use case is I want to launch an instance. Right now the workflow to do that inside of Horizon is a bit cumbersome and you have to have some knowledge beforehand to be able to complete that task. So we're taking a critical look at that, we have been over the past, I'd say six months, we actually did some usability studies that were presented at the OpenStack Summit to find the pain points there and we're going to rework that interface to allow users to more easily be able to get their instances up and going. There's some other things that we want to add in for user experience, one of them is the richer filtering, so do more API-side filtering, this becomes a mandatory for anybody who has a larger installation or for admins, being able to find the information they're looking for in Horizon right now is somewhat hit or miss, we want to get that unified and then provide that to admin users. Pagination is also somewhat hit or miss, so we want to get that unified inside of Horizon as well, again to support those larger scale installations. Validation, so we want to be able to do more input validation for forms when you're trying to update items in Horizon, so we want to be able to provide some client-side validation for that to give user better feedback and quicker feedback without having to make round trips to the server to figure that out. And then the last item here that it's not listed, but we also want to focus on accessibility, so we really want to make Horizon a product that companies can pull down and use, and so one of those, one item there that is lacking in Horizon right now is accessibility for screen readers, and that's the big thing right now, so we want to be able to support screen readers out of the box and allow, you know, there are restrictions on web software that certain companies can't use that if it doesn't support those requirements. So over the past two releases we've been working on, role-based access control support inside of Horizon. Horizon, from early on, has supported basically two roles inside it, it opens back member and admin, and that's it, those are the two user roles that you could have. We've been, over the past couple of releases we put in a policy engine inside of Horizon and we've started rolling that implementation into the different panels and tables that we have inside Horizon, and this release we're trying to take the final step where we can actually turn that on and allow more diverse roles going forward, and also trying to consolidate some of the views so that it uses that role-based access control to show you what controls you have that you can use and hide the ones that you don't have access to. And an ongoing effort in Horizon is to increase the API coverage, so we have, we cover a lot of the APIs from the different services, the services are always moving forward and that's great, obviously it makes our job challenging to try and keep up and so as we move forward we're going to try and increase some more of that and we have blueprints to cover many features that say in Trove that weren't, that were added in Juneau, but we don't have support for them in Horizon yet. Cinder's another big area that we want to, that we have a lot of blueprints to focus on that API disparity, and then across the other services as well, we have a lot of work out there to do and a lot of great people picking it up and contributing to Horizon. So behind the scenes we're also doing a bit of a retooling, we're going to split our repository. So right now we basically have a toolkit inside of OpenStack and we have the main application that causes us some issues and so we're going to split that out and the other benefit of that is a lot of people like to use the toolkit by itself to build web applications or future dashboard elements that would come into Horizon as they come out of incubation. So this will aid that process going forward, they won't have to pull down an application and a toolkit to be able to do that development. It also helps, because Horizon is kind of a weird case right now, they don't fit the mold. So this is a lot of behind the scenes work, but it's a big priority for us to tackle in this release. We're also working on an integration test suite. So Horizon isn't as tied into, it's tied into the gate like all the other services, the gating mechanism for code to merge, but it's not, it doesn't have much in the Tempest test suite right now. So we're working on a set of, last release we added an integration test harness inside of Horizon and now we're adding, we're trying to build out that test suite and get it stabilized to the point where we can get it included into the automated test runs. And that's all I have for you today. Great, thank you. Does anyone have any questions? If they go off to see, not yet, okay. All right, let's go over to Kyle then. Thank you, David. And then we'll see if we have any at the end. Okay, Kyle, so when you're ready, all set. Okay, perfect, thanks. So good afternoon or morning or evening, wherever everyone is. My name is Kyle Mestri and I'm the networking PTL in OpenStack now. So I, these, I think we'll just do the similar thing that David did, basically go over some updates for OpenStack networking for Juno. And like David did, I think a good place to start is, is with the mission statement that each of the projects have. So for networking, this, this is our, this is our, this is our mission statement. And one of the things that we've done in networking to, to kind of achieve this is, you know, Neutron is, is a pluggable interface pretty much up and down through everything. So all of this is implemented through, through plugins and drivers as well, both in-tree and out-of-tree as well. And that's one of the things that's served us pretty well. We have a large, large number of plugins, both core plugins, ML2 mechanism drivers, service plugins for the different services we have as well. So it's, it's, it's actually served us as a project pretty well. So I, I thought what I would start with for people here is, is to note that, that we do, one of the things I did after the Juno Summit was come up with a project plan. When, when we were in Atlanta for the Juno Summit, we, we as a project, you know, had, had two and a half days of design summit sessions. And after that, one of the things I really wanted to capture was the high-level community, the tasks that were important for the upstream Neutron project. These were, these were the items that, that I felt should be captured in a project plan and documented so that people had some visibility into where some of these things were going to land in the, the milestone releases, Juno 1, Juno 2 and Juno 3, and which would ultimately be in the release. And, and I think most importantly it was, this has really helped us as we interact with distributions, with, with the people who are going to consume the upstream release and distribute it, whether that's Red Hat, Canonical, Mirantis, Rackspace, whoever else is, is doing that. This has given, this has really helped them I think by giving them some visibility into when things should land and things like that. So I think I've been pretty, pretty happy with this. And I think that I've gotten some good feedback from others. So there's a link in here in the slide if people want to go take a look, because what I've tried to do in this presentation is highlight some of the bigger ticket items. There's a lot of littler, smaller items that are in this project plan as well. So let's, let's jump right into, you know, what we're doing for Juno. This, this was the number one item that the Neutron has taken on is achieving parity with Nova Network. And we, we did a lot of work as a team in Ice House to lay the groundwork for this. And we're still, we're still finishing this off in, in Juno at this point. We're going to, the plan is to, is to officially close the gap with this and to move forward here. You know, we had, we have a plan that's been blessed by the, the TC as well that we're working on as well. A lot of people are focused on this and this covers everything from database migration stuff to migrating from Nova Network to Neutron, to implementing Nova multi-host mode and things like that. I think one of the, the big things that we're looking to do here is to start off with a migration script which will allow existing installations running perhaps Ice House with Nova Network to be able to migrate to, to an equivalent Neutron functionality for Juno during that upgrade process. And that's something that we're working on now. We don't have any, any sort of scale numbers at this point as to what we're going to be able to support there. But it's, it's something we're very actively working on right now. So the other main item that, that we're working on for this is actually on the next slide. So yeah, distributed virtual router. This is, this is the feature that will allow us to implement the Nova multi-host mode. And so what this does is, this is going to implement L3 routing across the compute nodes for the east-west traffic there. It's also going to, it's also going to implement floating IP namespaces per compute node as well. So for those features, you will no longer have to send traffic to network nodes. You'll be able to do this on a per host basis. This, this is the equivalent of what Nova Network multi-host mode was doing as well. It's, it's worth noting as I, as the third bullet says that the SNAP traffic is going to remain centralized, but there's, there's another feature. And the only reason that that's the case right now is because that's going to be a further improvement post-juno to try to distribute the SNAP functionality as well. The problem with doing that right now is the, the amount of IPs you have to burn on those public networks for that. So that, that's something that we're looking at doing post-juno. We, we are going to improve the situation around the network node with regards to HA by there is some work going on to, to implement HA for the network nodes using a VRRP as well. So this, like I said, this is, another big item with this has been, has been testing this functionality right now in the, in the gate when commits are pushed up, there, there is no multi, there's no multi-host testing that goes on for those types of commits. For something like DVR, the functionality to be able to, to test commits with multi, multiple nodes is, is actually pretty useful. So that's, there, there is some work going on to explore that functionality and see if we can implement that in the gate as well. Besides that, there's a lot of organizations that have volunteered to help test this DVR functionality at, at scale. And so we're working, we're working around that to, to ensure that we have this tested as well. So the next slide here is around DB updates and migrations. This is also something we are going to, to fix in Juno and address. The problem we had beforehand was it turns out that our database migrations were not item potent such that they were dependent on the plugins and the service plugins that you had implemented in your installation. So we're actually going to implement the healing migration in Juno and from Juno forward, all of the migrations will include all the tables for all the plugins and service plugins and such. This will provide a much more consistent experience for operators as well and should make things much easier if, if installations end up changing, changing plugins or adding plugins or, you know, mechanism drivers or service plugins or things like that. So I think this is a, this is something really useful for that. Another, this has also been a big focus for Neutron, third party testing and CI infrastructures. And this really started in ice, in the ice house timeframe as well. And there's a little bit of history behind this. You know, when, when Neutron was first started back when it was known as quantum, we, we originally had a small number of plugins upstream and the requirement was typically, you know, a plugin would have a core developer upstream as well, kind of shepherding it in addition to working on community features and the rest of the code. That, that didn't scale as well because it was hard to find that many core developers that fast. We ended up with a deluge of plugins and so that didn't quite work. So in ice house, what we did was we, we started to mandate third party CI testing and we put in place some requirements around it. Most people got the CI systems up and running and what we're doing in Juneau is we're actually continuing that by, by trying to come up with more consistent experience for developers and, and by developers, I mean people are submitting patches, possibly see them fail on other third party CI systems. We're trying to come up, make sure that people are following a consistent way of using the, the tools around this. So the developers have an easier time to look at failures there as well. And it also, the other nice thing about all of this is it provides consistent testing for all of the entry plugins as well. That's, that's really, that's really what the main focus has been around here is, is to try to improve the quality and things like that. What happens with Neutron is a lot of the plugins may require either some sort of hardware, which is not around, or even some sort of virtual machine to implement the networking abstractions. So this, this allows the vendors and even the open source plugins to, to implement that third party testing on their own infrastructure, wherever, you know, in their own lab or whatever. It's actually been pretty successful. And I, you know, Neutron has the largest third party CI testing setup upstream. And then one other note on this, there's actually a meeting on IRC on Mondays around this where we're trying to let all of the third party plugins and CI systems developers and owners exchange information, ask questions, and that's actually been fairly successful as well. So the next item I wanted to touch on was, was Elbas or a little balancing as a service. We, we as a Neutron team have spent a lot of time on this, even leading up to the Juno Summit and post the Juno Summit. And so what the result of all this is that we're going to, we're going to unveil a version two of the Elbas API in the Juno timeframe, a brand new API with a new object model. We're, we're going to, we already have work underway on the API and the object model. And in addition, there's work to update the Intree HA proxy driver so that it will reflect the new API and the new object model. I think one of the more interesting things here is that in addition to the Intree HA proxy driver, there's been a group of companies that have decided they're going to start a new Stackforge project called, which they're calling Octavia and this is going to be an operator or carrier grade implementation of load balancing in Neutron. It's, you know, the nice thing is they've been involved with the new Elbas APIs in Neutron. So they're, they're pretty excited about those. And, and by doing this Octavia project on Stackforge, it allows them to kind of iterate at their own pace outside of Neutron, but tying themselves into the Neutron Elbas APIs. So I'm pretty excited to see the result of Octavia once that happens. So I also wanted to touch base on the group-based policy API work that's been going on in Neutron. This, this is an API, it's an extension API to Neutron. And this, this is going to provide a declarative policy driven model for, for people that's really application focused. This, this work started in, at the Ice House Summit in, in Hong Kong was when it was first presented. So the team's been working on, the sub teams have been working on this since then, and, you know, the work was, was approved for Juno and is, is ongoing right now. So this is, this is something that some people have, I actually won't take credit for this quote, but someone, someone mentioned that, that this could be, you know, Neutron's porcelain APIs to go along with the plumbing APIs that exist already. So, so we'll see, but this is a, this is looking pretty promising and, and should be pretty exciting as well. So the next item here is something I alluded to when I was talking to the DVR functionality previously as well. And this is a HA for, for L3 routers. This is what's going to be used with the centralized snap functionality as well to provide redundancy for those nodes that are providing that. But even outside of that, for people that don't want to use the DVR functionality, this will provide HA for all of their, their L3 routing nodes as well. This work is also scheduled for Juno right now. The entry implementation is going to utilize, keep a live D for this right now. There is a blueprint file for this right now. This is also something that I think a lot of distributions are, are interested in, in getting upstream as well. So I'm, I'm hopeful that this work should land in Juno and, and leave some of the issues with the, with the networking node being a single point of failure for a lot of operators. So one other, one other note, one other interesting thing from an operator perspective is the work we have in Neutron going on around flavor frameworks. And a lot of this ties back to, to services to some extent, whether that's service plugins like LDAS or VPN or firewall or something like that. The idea with the flavor framework is this is a way for that, that we're going to allow operators to offer network services to their clients and their tenants, essentially. We're going to try to separate the driver functionality and configuration from the consumers of these services as well. And additionally, we'll allow multiple backends to function here as well. There, there's currently some discussions going on, on right now around the flavor framework. There's, there's a couple of different solutions that we're looking at trying to tie together to come up with a common one to, to have this implemented. But I think this is something that, that the operators are, are excited about. We, we had a meeting with a bunch of operators in, in San Antonio last week and they were, they were pretty excited about the flavor framework. And, and I think even, even the vendors have been pretty excited about this as well. It's really nice because it allows the operators to expose different functionality, different service level and tie it back to specific back-end driver implementations as well. So, so I think this is going to be a pretty exciting thing as well. I, I thought I would, I thought I would throw at least a slide up about NFV as well. There actually is a, an NFV sub team or project, which is not specifically under any sort of neutron umbrella because NFV and OpenStack encompasses more than neutron. There's also some things that's associated with NOVA as well. I just wanted to highlight that, that there are some people in neutron that are working with this NFV sub team as well on, on the different features that they want integrated in here. And obviously these would be things like service chaining, traffic steering, things like that. There are a lot of proposals around this right now. There's, there's in fact some sub teams that have been looking at service chaining and traffic steering for, for the last cycle. So it's hopeful that we can get some of this work merged upstream, but I suspect a lot of this may end up being a, a longer than Juno term type of thing. This, this would also include even simple things like VLAN trunking support for tenant networks as well, things like that. So a lot of the NFV work is, we'll see what lands in the Juno time frame. And I would expect that there'll be a larger push in the K time frame as well. So the next couple of slides, I wanted to highlight for Juno what new, what new plugins are, are either in the process of being merged or already merged and also what plugins are, are going to be removed from upstream. So right now in the Juno time frame, we've, in Juno one, we merged a Cisco A-Pick plugin and a free scale SDN, excuse me, a Cisco A-Pick mechanism driver and an L3 routing service plugin. And we also merged a free scale SDN ML2 mechanism driver as well. So those have merged. And if you go to the next slide, please, we, these are currently a list of, of the, of the existing drivers plugins and service, or excuse me, driver's mechanism drivers plugins or service plugins that are also proposed at this point. So we continue to have a, a fairly healthy ecosystem of, of both vendors and open source solutions proposing, mechanism drivers, plugins, service plugins and all of that upstream as well. You know, again, I mentioned before the, the third party CI and third party testing has been really integral to be able to handle this type of load with all of these new additions coming in and things like that. And we've, we've tried to focus on, on ensuring that as these plugins come in, we, you know, they're, they meet all of the different code standards that we have upstream and things like that. And it's, it's been really, that's been a good, good for us as well. And then I just wanted to highlight that in Juno, we're going to actually be removing the open V switch and Linux bridge plugins from the upstream source tree. This, this has been announced for a while. These have been deprecated for, for two releases since the modular L2 or ML2 plugin essentially takes over for both of these. That plugin still works with the existing OBS and Linux bridge agents at this point, but, but the general direction has been to deprecate these and move over to ML2. And I think as you saw in one of the other slides, there's, there's a healthy bit of ML2 mechanism drivers that are also being merged upstream. So, but these will definitely be going away in Juno. So that's all I had. So Margie, I'll, I'll pass it back to you. Okay. Great. Thank you. See any questions? I'll open up the line. Someone wants to ask a question. You are now unmuted. Um, I'm going to just ask, open it up with a question. It's kind of general. Uh, Kyle, I just wanted to know a little bit more about the flavor framework. Interesting. So are you hoping to standardize around a few different sets of frameworks with some suggested SLAs and things of that nature, or it would be kind of a, you know, a group of, of many. So I think the idea is in, in, in various deployments, you may have service plugins that offer different functionality. You may have load balancers. You may have multiple, if you use load balancer as an example, you may have a fancy hardware based load balancer from 810 or brocade or some vendor, and then you may have just HA proxy implementations that run as, as VM somewhere. So in that type of environment, you, you as the operator may want to set up flavors where tenants who want to utilize the hardware based load balancers may, maybe, maybe build more. And then if they're using the HA proxy based ones, they may be build less. It may be that the hardware based ones are offering some sort of advanced feature, which not everyone needs. And that's why, that's why they're, you know, they're going to be build more. But basically it's a way for the operators to, to more tightly control access to the different functionality for the, the different services that they're providing. Thank you. And then, David, I know that there was a lot of interest last round with dashboard with all the changes and extensibility and new look and feel to the design. Do you, do you see a lot of that input? I mentioned it in your presentation, but do you see a lot of that input coming from the personas group that kind of morphed into the horizon UX or, you know, from that side? And for those who don't know, there's a, there's a group of people who are looking at horizon within the Opusda community and kind of doing testing on the dashboard side. So I was just curious if that continues to grow or, or you're getting feedback from across the board. It's not necessarily just them growing. I mean, it's kind of an evolution of that group, I guess. Right. Yeah. So that's kind of a subgroup of the overall OpenStack UX effort, and we've been getting a lot of valuable input from, from both those groups. The personas group did most of the, or set up and ran most of the usability testing that we did. They also ran another study to try and determine the most common personas in OpenStack. And we're definitely there in the process of trying to, to working towards finalizing the output of that. And we're definitely looking to use that as input as we move forward, but a lot of the usability that we're addressing right now is not directly based on those personas. I think that's going to be down the road a little bit. So we're trying to let them finalize their work and then we'll, and then we'll pick that up. But that effort is definitely ongoing and, and very productive. And we're looking forward to being able to consume that. Okay, great. It's good to know. I peeked it on that group in five at a time, just curious. Okay, well, does anyone else have any questions? Quiet group? Okay. Well, this session will be on the Foundation's YouTube account in the next few days. If you do have any questions after the fact when the meeting is over, you'll receive an email and you can email us at the Foundation directly and then we can get back to David and Kyle as well. Or I think David and Kyle shared their information too, so you can contact them directly. David and Kyle, I know you're both very busy. Appreciate your time. And with that, I think then we'll, we'll conclude. Oh, thank you. Thank you. Thanks everyone. Have a great day. Bye.


Today, we will start discussing about very important topic in microfluidics which is surface tension driven flows. As we have discussed earlier that as we go down to smaller and smaller scales, surface effects become more and more important as compared to volumetric effects. So there are possibilities by virtue of which one can exploit surface effects to a benefit or surface effects may be used as a control mechanism for controlling or driving or actuating fluid flow. For example, when we think of a pressure gradient driving a flow, it is really a challenging proposition to create a good enough pressure gradient to drive a good amount of flow through a microfluidic system because of huge frictional losses. So what one can do instead of using a pressure gradient directly, one can exploit a pressure gradient that is implicitly induced because of a surface tension gradient. So it may be possible that naturally occurring surface tension gradients are there or naturally occurring surface tension forces are there or surfaces can be engineered to create surface tension gradient and because surface tension occurs so nicely in small scale systems, it is very important that we study the behavior of surface tension or the characteristics of surface tension driven flows in general and surface tension driven micro flows in particular. So a brief motivation what I have discussed that in small dimensions surface tension dominates over other forces. So it is not that it is a very new kind of force, it is something which nature has been knowing for a very long time. Like if you think of the transmission of water from the lower level to the topmost level of a tall tree, how that is possible? There is no pump, there is no pump made by engineers by which water is pumped from the root to the topmost level of the tree but how it is possible? It is possible by surface tension, it is possible by capillary action. So because of the smallness of the capillaries that we will see that because of the smallness of the capillaries, surface tension force can lift the water to a significant height and that significant height is good enough for supplying the tallest, the topmost branches of the tree with the necessary water that is sucked from the ground. So there are many examples where surface tension forces are important like one can use surface tension force to manipulate droplets, to manipulate bubbles and these droplets and bubbles are also very important in microfluidics based applications. So we will briefly revisit the fundamentals of surface tension that is what is the surface tension and why is it important. So I will come to the board, of course it is represented in the view graph also but we will utilize this view graph for mostly summarizing our observations but just for simplicity we will not consider a complicated scenario but consider a very simple scenario when you have a container there is an interface, the interface separates the vapour from the liquid. Now I mean whether the interface is flat or curved forget about that at this moment, we will discuss about all these issues in much more details later on but for the time being let us assume that the interface is of some form, some shape. Let us consider some liquid molecule here, when the liquid molecule is here this molecule is acted upon by forces equally from all possible sides because all sides are surrounded equivalently by other liquid molecules. So there is equal attraction from all the sides, however consider a molecule on the interface when you are considering a molecule on the interface what is happening on one side you have liquid and on another side you have vapour which is more dense liquid or vapour, liquid is more dense. So liquid being more densely packed it is more likely that this molecule is attracted more strongly from the liquid side as compared to the vapour side, if that be so then what is the possibility then the possibility is that this liquid this molecule at the interface has a very special character we do not call it liquid or vapour but it is an interface but it is also having molecules and this molecule will have a tendency to dissolve into the liquid phase but that does not happen because if that happens no interface can be formed. So interface is formed that means that the molecules at the interface are having grossly speaking from the system level they are having some energy so that they can overcome that attraction this net attraction and remain at the interface. So this is called as interfacial energy or surface energy. Now not only that how this energy is expressed typically it is expressed like that so when you have an interface because of this reason the interface is considered to be under some tension and since the interface is considered to be under some tension this state of the interface is described by a force which is also called as surface tension and it is expressed in terms of force per unit length. So the surface tension or the surface tension coefficient sigma between 2 phases is expressed as a force per unit length of the interface so its unit is Newton per meter okay. So this is what is summarized in this view graph so you can see that like there is a volume element which is identified and we are that volume element crosses the interface or cuts across the interface and we are seeing that there is a differential force or extra force towards the liquid as compared to the force towards the vapor because of the differential density okay. So this is what we have discussed I am not going to reiterate I mean this view graph discusses about what is surface energy and what is surface tension. So of course there are more formal definitions associated with this but this is a qualitative way of understanding the concept which will be useful for us for our analysis. Now we will of course start with the basic understanding of surface tension but the question is how can surface tension actuator control fluid flow that is what is of very important concern for us. So of course surface tension itself is like a force and as a force it can actuate the flow by itself. On the other hand there are other subtle means by which you can control flow by surface tension. How other than surface tension being utilized as it is you can use the gradients in surface tension not just the surface tension itself but gradients in surface tension to manipulate the flow. So that is possible by using a gradient in temperature. So gradient in temperature can create a gradient in surface tension this is known as thermo capillary flow we will discuss about this in details and the corresponding convection is known as marangoni convection is one of the like classical mechanisms by which you can control surface tension driven flow by virtue of temperature gradient. So not only that you can create a gradient in concentration because gradient in concentration can create a surface tension gradient. You can use electric field to modulate surface tension we will see how that is possible. You can modulate contact angle through design hydrophobization or hydrophilization of solid substrates. So you can control the surface tension force by altering the contact angle and the contact angle can be altered by making the surface or designing the surface either hydrophilic or hydrophobic with a particular contact angle or a combination of above effects. So these are some of the possible ways by which you can create gradients in surface tension. So these are some of the ways by which you can modulate the flow other than of course using surface tension itself to manipulate the flow. So using surface tension itself is something obvious that is what I have not kept that in this slide but I mean the creating gradients of surface tension to manipulate the flow is something which is not always that intuitive. Now we will start with a very basic law or very basic equation governing surface tension and that equation is known as Young Laplace equation. So Young Laplace equation what it does it relates the pressure difference across an interface with the surface tension. So to understand this I will also draw some schematic in the board to supplement what is there in this view graph but first I am explaining you what is there in the view graph because the schematic which is there in the view graph I will not reproduce that in the board I will reproduce only a part of that in the board. So let us say that there is a membrane with dimensions x and y. So this dimension is x this dimension is y. So this is a membrane and this is a curved membrane. So the side with x has a radius of curvature r1 and the side with dimension y has a radius of curvature r2 okay. So these are sometimes called as the principle radii of curvature and like these similar considerations are used in many other aspects of engineering like for example if you are talking about pressure vessels and all these things different radius of curvature they come into the picture. Now forget about that let us come to this particular example. Now because of a pressure difference between the inside and the outside there is a change in the area of the membrane and there is a displacement also of the membrane. So how that is possible? So because of the pressure difference there is a displacement delta z and because of the work done by virtue of this pressure difference there is an additional energy imparted to the interface and that makes the interface assume a greater area because the surface energy has increased. So what has helped in increasing the surface energy that is the work that is input to the system by virtue of the pressure difference between the inside and the outside. I will explain you that how to qualitatively assess that like which side is of higher pressure which side is of lower pressure and all those things I will discuss about that in details in the board. But now so the membrane is stretched now once the membrane is stretched because it has now more surface energy as work is input to it. So you have now the dimensions of the membrane as x becomes x plus delta x and y becomes y plus delta y okay. So with this little bit of understanding let us come to the board and we will figure out the eraser just bring the eraser. So let us say that this is one of the curves of dimension x. I am not drawing the other one of dimension y. So this becomes x plus delta x this is r1. I have just magnified the figure to make it clear to you of course like these are all differentially small changes so this is delta z. So from similar triangles you can write r1 by r1 plus delta z is equal to x by x plus delta x. So this becomes r1 by delta z is equal to x by delta x. If that be the case we can similarly write that r2 by delta z is equal to y by delta y right because the radius of curvature r2 is associated with that side with dimension y and radius of curvature r1 is associated with that side with dimension x. Now let us apply the work energy consideration. What is the work done to push this interface from the initial location to the dotted location delta p into A into delta z right. Delta p is the difference in pressure across the 2. So that time say is the net force and force time displacement is the work right. And this is equal to the increase in surface energy because of the stretching of the membrane. So surface energy is surface tension coefficient or surface tension. Surface tension and surface tension coefficient are the same. They are just same things expressed in 2 different terminologies. So surface tension coefficient times the change in area delta A. So what is the change in area x plus delta x into y plus delta y minus xy. So this is sigma x into y gets cancelled with x into y then x delta y plus y delta x. Now the neglect delta x delta y this is a small lower order term as compared to the other terms. And what is this A here A is x into y. So we can write from here what is delta p sigma x into delta y divided by xyz xy delta z. So sigma delta y by y delta z plus delta x by x delta z right. Now look at this what is delta x by x delta z this is 1 by r1 and this is 1 by r2. So we can write finally that delta p is equal to sigma into 1 by r1 plus 1 by r2. This equation is known as Young Laplace equation and a very very important equation because it relates the surface tension with a pressure differential.  Now so surface tension as a driving force what it is fundamentally doing? Surface tension as a driving force is actually creating a pressure differential. So although it is a force acting on the interface but it is eventually giving rise to a pressure differential across an interface and that pressure differential is actually manipulating the flow okay. So now if you consider the surface tension as a force therefore this will appear to be a force in the Navier-Stokes equation only at the interfacial control volumes where there is a sudden jump in pressure. So that is the way in which you can treat it numerically but in this chapter we will mainly concentrate on how to handle these issues analytically. Now let us ask ourselves certain very simple questions. These questions might appear to be too simple but let us try to answer that even if the question is simple I mean it is okay if we attempt to make an answer. So the first question is that we are writing delta p. So when there is an interface there is an inside of the interface and there is an outside of the interface right. So delta p we are talking about what p in-p out or p out-p in so and how do we know that? So whenever we are asking any question this is what I mean for any examination or any tutorial or any discussion I would always encourage that whenever I am asking a question I am not minding a wrong answer because many times I can also give wrong answer or wrong interpretation but it is more important that what is the logic that you are applying to give the answer and that is where actually the concept lies. Sometimes we may use the logic little bit incorrectly so that final answer becomes wrong but sometimes the final answer is right but we just know it as an information rather than something which is of scientific origin then that kind of knowledge actually has no value. So let us try to see what is the scenario. Let us say that this is an interface okay. Now can you tell that if this be the interface then what is the direction of the surface tension force? So the surface tension force just like if you have cut the interface here it will be the interface will be in some form of tension. So now if you resolve this force in various components you can see that this component and this component they may cancel and along this direction let us say this is x direction along this x direction you have a resultant force due to surface tension right. So if you have a resultant force due to surface tension here then you also have some force due to pressure. So you have a resultant force due to pressure inside from this always remember that pressure is by definition positive pressure means acting inward normal to a surface. So this is a force due to inside pressure this is a force due to outside pressure if this is inside and this is outside. So for equilibrium we can say that force for pressure inside is equal to force for pressure outside plus force surface tension right this being a positive quantity that means force for pressure inside is greater than force for pressure outside that means pressure inside is greater than pressure outside because they are acting on the same area okay. So do not just make it like an information that you want to remember if you use this logic you can come to this conclusion by very simple mechanics that where should the pressure be more inside or outside. So this is nothing but Pi-Po. Now let us see that how do we apply this equation. Let us assume that there is a channel in this channel there is an interface this is liquid and this is vapor okay. So now you can clearly see that this interface can be of any shape right. You cannot presume that it is spherical or whatever but if this thickness is small if this height is small then it can be thought of as a part of a large sphere without making very significant amount of error if this gap is small then like this can be thought of as a part of a sphere. So this can be thought of if you imagine a large sphere this can be a part of the surface of this of the large sphere. So if you have that kind of a situation then for a sphere R1 is equal to R2 is equal to R sphere okay. So I am so much emphatic with this subscript R sphere here because R sphere is not same as the radius of this capillary that you must understand right. So the radius of this capillary let us say is this one and the radius of curvature of the sphere is something different from that okay. So now if R sphere is something which is known and you can clearly find it out provided you know what is the contact angle and I will discuss about what is the contact angle later on. I have not yet introduced the definition of contact angle. So we will stop there for the moment but for a sphere we know that because R1 is equal to R2 is equal to R so delta P is equal to sigma into 1 by R plus 1 by R, R sphere plus 1 by R sphere. So 2 sigma by R sphere this is the formula that you commonly use in undergraduate texts for finding out the pressure difference between inside and outside of a droplet spherical droplet. So this is how the formula comes. So one important thing we can get from here is that in many cases assuming the interface to be of spherical shape is not something which is pragmatically bad. So we can assume that and let us go to the next view graph where we do the same thing the previous derivation that we made that delta P equal to sigma into 1 by R1 plus 1 by R2 is general. It does not assume any shape of the interface but if you assume the shape of the interface you can do the same thing for a droplet or for an interface which is a part of a sphere and for that we can use the considerations of energy minimization for making the derivation and I will show you that how the same see the first derivation that we did purely from work energy principle right. The work done due to the pressure differential is adding to the surface energy that is the work energy principle that we used. Now we will use the energy minimization principle what is that that a droplet in its equilibrium shape will try to adhere to a configuration with minimal interfacial energy because that is its stable configuration. So what is displayed in this view graph is a droplet which is a part of a sphere then there are certain parameters which are defined we will first define the angle theta which is called as the contact angle. So again I will come to the board to discuss a little bit more about this figure and more about this derivation. So let us say this is a substrate and a droplet is sitting on this substrate which is a part of a sphere. Let us say that this is like a hemisphere up to this is like a hemisphere. This black is actually a part of the hemisphere this is liquid this is vapour and this is solid. So you have a triple phase contact actually. Now what you do you draw a tangent to the liquid vapour interface and the angle that is made from the liquid side with that that angle is called as the contact angle with respect to the substrate. So this theta is called as the contact angle. Now different surface tension forces act along the interfaces. So for that see when we say sigma it actually has no meaning we have to say sigma with respect to which interfaces solid liquid vapour solid vapour whatever. So when we say the surface tension force here so what should be the subscript? So sigma between liquid and vapour so you can write sigma vl or lv that makes no difference but commonly we write sigma lv. So in the formula where we write 2 sigma by r that sigma what we write is commonly that is actually sigma lv. Now what is this? This is sigma sl or ls whatever you say and this is sigma sv. So what is the surface energy of the droplet? Sigma sl-sigma sv into Asl-sigma lv Alv. What is Asl? Asl is the solid liquid interface area. So if this is say some radius then pi into that radius square right this is remember this is a part of a sphere. So its footprint on the solid surface will be a circle right you cut the sphere from anywhere you will get a circle. So then what is the liquid vapour interfacial area? The liquid vapour interfacial area is the area of this curved surface the black curved surface. Now this energy is minimized subject to some constraint. What is that constraint? Volume of the droplet is conserved right so the volume of the droplet must be conserved. So this has to be minimized subject to constant volume. So it is as good as minimizing this minus lambda v equal to 0 where this lambda is called as Lagrange multiplier. This is one of the ways in which we solve optimization problems in mathematics that minimizing this with a constraint that v is a constant is as good as minimizing this minus lambda into v. Where lambda is a parameter which is known as Lagrange multiplier. We will see that what is the physical significance of this Lagrange multiplier in this case. Now to proceed further we have to figure out what is ASL and what is ALV. So let us construct some more lines in this figure. So we join this line like this. So this blue dotted line is perpendicular to the green dotted line because the green solid line because the green solid line is tangent to the surface of the sphere and this blue dotted line is the normal that means this angle is 90 degree minus theta. So this angle is also 90 degree minus theta okay. So ASL so what is this particular radius if r is the radius of the sphere what is this radius r sin theta right. So ASL is pi r square sin square theta. This black curved surface will be a full hemisphere when this theta is equal to 90 degree okay. So when this theta is equal to 90 degree then this will be just pi r square where r is the radius of the sphere. Now let us find out what is ALV. To find out ALV what we do let us consider that at an angle phi this angle is phi arbitrary angle we consider a small strip of d phi. So what is the surface area of the shaded region? So it is a small part or small slice from the sphere is actually like a small cylinder with some radius and some lateral dimension right. So 2 pi what is this radius r cos phi. So 2 r cos phi 2 pi r cos phi into r d phi ALV becomes this integral with phi from what to what phi is equal to 90 degree minus theta to 90 degree. So this is what 2 pi r square sin phi from 90 degree minus theta to 90 degree. So 2 pi r square into 1 minus cos theta check for theta equal to pi by 2 that is the surface area of a hemisphere that is 2 pi r square double of that is the area of a sphere 4 pi r square. So this is ALV what is the volume of the sphere I mean part of the sphere v is equal to so it is like pi r square h right. So pi r square means r square cos square phi what is the height of this one r d phi is the lateral dimension cos of that. So r d phi cos phi again from 90 degree minus theta to 90 degree. So pi r cube integral cos cube phi d phi from 90 degree minus theta to 90 degree. Now we can express cos cube theta in terms of cos 3 theta. So we can write cos 3 theta is equal to 4 cos cube theta minus 3 cos theta not visible in the board write it little bit below cos 3 theta is equal to 4 cos cube theta minus 3 cos theta. So instead of cos cube phi we can write cos 3 phi plus 3 cos phi by 4. So this will become pi r cube by 4 cos 3 phi will become sin 3 phi by 3 plus 3 sin phi 90 degree minus theta to 90 degree. So pi r cube by 4 minus 1 third plus 3 then minus with another minus we will make it plus so cos 3 theta by 3 minus 3 cos theta right if I make any algebraic mistake please correct. So pi r cube by 4 8 by 3 plus 1 by 3 cos 3 theta minus 9 by 3 cos theta. So pi r cube by 12 8 plus cos 3 theta minus 9 cos theta substitute theta equal to 0 sorry theta equal to 90 degree that is the hemisphere you substitute theta equal to 90 degree this becomes 8 pi r cube by 12 that is 2 by 3 pi r cube double of that is 4 by 3 pi r cube which is the volume of a sphere okay. So let us write the simplified expression for E sigma SL minus sigma SL minus sigma SV into pi r square sin square theta plus sigma LB into ALB 2 pi r square into 1 minus cos theta minus V into lambda. So minus lambda into pi r cube by 12 8 plus cos 3 theta minus 9 cos theta this is what is the expression for E. For minimum E what you have one is del E del r equal to 0 so that means sigma SL minus sigma SV into 2 pi r sin square theta plus sigma LB into 4 pi r into 1 minus cos theta minus 3 lambda pi r square by 12 into 8 plus cos 3 theta minus 9 cos theta equal to 0 and you also have del E del theta equal to 0 that means sigma SL minus sigma SV into 2 pi r square sin theta cos theta plus sigma LB into 2 pi r square sin theta minus lambda pi r cube by 12 is equal to minus cos 3 theta is minus 3 sin 3 theta and cos theta this will become plus 9 sin theta that is equal to 0 right. Please check carefully whether there is any algebraic mistake because we will continue with these expressions for finding out an expression for like the equilibrium condition for the droplet. So to summarize what we have discussed so far in this particular lecture we have discussed about what is the work energy principle that governs the relationship between the pressure difference across an interface and the surface tension coefficient and then for a droplet which is a part of a sphere we have tried to derive the same consideration from energy minimization principle. So we have written an expression E which is the energy minus lambda into volume so for a constant volume that needs to be minimized so for minimization of that we have set the partial derivative of that with respect to r and theta equal to 0 and we will derive our subsequent relationships or subsequent expressions by using these two final equations. We will take it up in the next lecture. Thank you very much.


Hi everyone, Joe for Jaspy's casebreaks.com coming at you with a three box break of 2022 Fnatic's under wraps autographed baseballs. Remember, this is one autographed baseball per box. Note that there is one spot that gets any and all multi signed baseballs. So any multi autos like that ball right there goes right to that spot. So there are no randomizers between players or anything like that. Big thanks to this group right here. So one spot gets you nine players, so we're going to multiply this by nine. So there's one already, there's two, three, four, four, five, six, seven, eight, and ninth and final time. You can see we match up right there, so that's the right amount. So 171 spots total. Let's gather all the names, put them into a blank list here, and all the players are right there and that there's the any and all multi signed baseball spot right over there. Good luck. Let's roll it. Let's randomize names and players six and a six, 12 times each. One, two, three, four, 11 and 12th and final time. After 12 we got Steve all the way down to Bradley. Six and a six, 12 times for the players, one, two, three, four, 11 and 12th and final time. So after 12 we got Vlad Guerrero Jr. all the way down to Hammer and Hank Aaron. Now there's way too many names, I've got to preserve this golden voice here. I'm not going to read off all the names. But I'm going to show you all the names as is, right, and then I'll alphabetize by your first name so you can see all of your players grouped together. All this is on the recording so I just wanted to get all this on wax, on tape, on video, however you want to call it. Nice, Ryan G, any and all multi-autoed baseball cards in this quick little three box break. Good luck. So if you want to audit this list after we upload it you can kind of go through it and go through in slow motion if you'd like. Let's sort now by column A by your first name. So Bradley, there are your group of players right there, down to Hank Aaron, nice. Dan Golan, you got a lot of players here, you got that group plus this group right over there, Harris, here's your group of players, Kevin, Pat Wolfe, Ryan Gansby, and then Fernando right there as well. Steve H, Steve H, Steve H, and Steve H, there's your last bottom mojo players right there. Tristan, here's your group, and then Tristan again, and then you're off with Tristan, Hays, Cole, Jordon, Alvarez. All right gang, I'm going to pause the video, when we come back we're going to see if there's any, you can trade, you can trade players, we're going to see if there's any trades, and then we'll have the break stick around, BRB. All right, welcome back everybody. So a little bit of trade chatter, but in the end no deals were done. Let's see what we got, here just a small example of what you could potentially get. We could play a little bit of America's favorite game, Who Am I, a game that we made up, no one else plays this game at all, but who am I? I am, I am no longer with us. I passed away in October of 2020 at age 91, batted left through left, my stats, win-loss record 236 wins, 106 losses, played for one team my entire career, had a 275 ERA and 1,956 strikeouts, 10-time All-Star, 6-time World Series champion, Cy Young Award winner, World Series MVP, 3-time AL, wins leader, 2-time MLB ERA leader, my number 16 retired by this team, a second ballot hall of famer, 77.81% of the vote, Chad and James getting it, nice. It is indeed Yankee's legend, Whitey Ford, got all the authentication stickers right there and there you have it, nice. We've got the card down there as well, all right, who has Whitey Ford? That's gonna go to Bradley, has the Whitey Ford. Marking the post-it note while you guys were guessing, it's been a while since we played this game, there you go Brad, nice, next box, active player, a hitter, a first baseman, a righty, lifetime through 2022, lifetime 295, average 1,750 hits, 315 home runs, over 1,000 runs batted in, 147 stolen bases, 7-time All-Star, 4-time Gold Glover, 5-time Silver Slugger, 2-time NL Hank Aaron Award winner, NL Home Run leader, NL RBI leader, a gold medalist in the World Baseball Classic back in 2017 and a recent, this is gonna give it away, and a recent NL MVP. So think about your recent NL MVP first baseman, in fact, he won this last year. That's right, it's Goldy, Paul Goldschmidt, there's the authenticity, hits you with a Goldy inscription as well, nice, Goldschmidt card in there as well, Paul Goldschmidt going to Kevin, Kevin M with the Goldy, all right, congrats, so that was David and James with the Goldy guess, and the third and final box, it's gonna be for this person here, all right, final round of who am I, also an active player, also a first baseman, and a righty, through 2022, got a 261 batting average, 146 home runs, 380 runs batted in, played for one team my entire career, a two time all star, all NBA, NBA, all MLB first team, NL Rookie of the Year, MLB Home Run leader that year as well, and an NL RBI leader in 2022 last year, also, this is gonna give it away, but I also have the MLB Rookie Home Run record, I don't think Chris Bryant was ever the MLB Home Run leader the same year he was Rookie of the Year, and did not have the MLB Rookie Home Run record, yep, David's got it, the polar bear, James, Ed, Steve Birchconcurs, there it is, and so that goes to Dan Golan, who got randomized Pete, can show you his autograph, I can get it out of, there we go, there it is, it's got all the authentication stickering, the fanatics authentication sticker, the card in there as well, alright, there you go Dan, thanks for getting into Random Player number 10, thanks everybody more coming up later, jaskyscasebreaks.com, I'm Joe, I'll see you next time for the next round of Who Am I, the next Who Am I game, bye bye.


All right, good turnout. So it is now 11.35, which means the presentation is about to start. And so being at Linux conference, the next presentation is about Linux. So this is Raphael, and I'm sure he's going to give us an amazing presentation. So everyone, please welcome him. Thank you. So hello everyone, and let me introduce myself briefly. My name is Raphael Vesotsky, I work at Intel Open Source Technology Center, which is part of the software and services group at Intel. And I'm based in Warsaw, Poland, Europe, pretty much on the opposite side of the air from us now. So that's how far I can go. I can travel without leaving the air, actually. So it's good to be here, and thanks for coming and choosing my presentation over whatever interesting things you might be doing instead of listening to it. Okay, so I've been working on Linux for around 10 years. I started to contribute to the Linux kernel in 2005. And I've been maintaining the power management core of the kernel since 2009, and the ACPI cores since 2012, so I've been around for quite a while. That's the plan of my presentation today. I will be talking about system suspend. So this is, you might ask, why system suspend? It has been around for a while. It was there before I started to contribute to the kernel already. So it's not new, it's not very exciting, probably. But the reason why is that it doesn't change a lot over time because that is a fragile thing and it's easy to break, so we don't really change it very often. But in fact, it changes from time to time, and this is the main reason. It has actually changed over the last year. And I'd like to say something about those changes, what happened, why it happened, and so on. So first of all, I will say a few words about where system suspend is. What's the place of system suspend in the whole big picture of Linux power management? Then I'm going to talk about a new flavor of it, which I'm calling suspend to idle. And finally, I'll say a few words about other developments related to system suspend, which are perhaps not the big items, but also important. So let's start with a big picture. Yeah, we have two broad categories of power management frameworks in the Linux kernel. One of them is about individual components like CPU cores, CPU sockets, devices, IO devices, I mean, and so on. So the idea is that if the given component is idle, it doesn't do anything useful. It should be put into a low power state into an energy saving state so that it doesn't consume energy in vain, right? And all those frameworks on the green field are for that. They try to track the usage of devices or usage of components. And if they are not in use, they should be put into energy saving states individually, not necessarily at the same time. So, you know, some devices may be in an energy saving state, some other may not be in such states. Things happen asynchronously and concurrently to each other. And so the green field is mostly about the state of the system in which work is being done. CPUs generally execute instructions, devices do IO, and so on and so on. On the other hand, the brownish or orange field represents the frameworks that work on the entire system at once, like they cause the entire system to go into an energy saving state. And in that state, nothing happens. I mean, no useful work is done. Processors don't do any useful work. And it's just there to save energy. So, things on the left-hand side are for a situation where work is done. Individual components may or may not be in low power states. The things on the right-hand side operate on the system as a whole. And I'll focus on this yellow circle here, which is system suspend, and a particular flavor of it, which is suspend to idle, as I said before. Oh, by the way, why the CPU idle framework is here in the cross-section? It is an interesting thing, because in some cases, we can, on some platforms, we can actually cause the whole system to go into an energy-saving state as a whole through a CPU idle transition. I mean, if it turns out that there are no instructions to execute for no processors in the whole system, then it can go into an energy-saving state of the whole system through an idle transition sometimes. So that's why I put it here, and I'll get back to that later. All right, so I'm going to focus on that thing, and on this in particular, going forward. So the system-wide power management in Linux can be pictured as a pyramid like this one. It's like the base of it is the working state in which CPU is the work, and everything above that red line is a sleep state in which actually no work is done, and which saves energy for us. So perhaps from bottom to top, this is a... Yeah, that's the reason why I call those sleep states, just because they are there to save energy, and no work is done in those states. So the first of them is Suspental Idle. It used to be called Freeze, and there are some... This name appears in several places in the kernel. Yeah, those two are also suspend states that the difference between those two and the Suspental Idle is that these require some support from the platform, either hardware support or platform firmware support to be accessible. On the top, there's Hibernation, which is suspend to disk in other words, so we save the contents of memory to the persistent storage and then turn everything off, hopefully. The idea is that the lower the state is in the pyramid, the more energy it consumes, so the higher it is, the less energy is used in that state. So the width of the level corresponds to the amount of energy that roughly corresponds to the amount of energy consumed in this state. On the right-hand side, there's a list of operations that have to be carried out to get to this level, like, for example, for Suspental Idle, that we need to freeze tasks and then suspend devices, so that's how you can picture all that, right? So first of all, those things have been around for quite a while. As I said, they used to be present in the kernel when I started to contribute, so it's more than 10 years ago. And this is quite new, so I like to say something about differences between those states and this new one, but for that I need to say how these are supposed to work and then talk about differences, right? So that is a suspend code flow, system suspend code flow, this is a system resume code flow, these have to be complementary. And all of the operations here are carried out on the whole system, right? So when I say quantifiers, it's kind of a global thing, and it goes through all the subsystems that have registered notifiers, and it's similar for the freezing of tasks. So first of all, the notifiers are for kernel subsystems, all of that is going to be about the Linux kernel, I'm not going to talk about the third space, okay? So notifiers are for the subsystems that want to know about when a system suspend is going to happen, and they can register a notifier for that and it is called before doing any other steps of this. The next thing done is the freezing of tasks, and actually it's about taking user space out of the picture so that we don't have to worry about what user space can be doing during the next steps, because user space may mess up with things in many different ways, and they are not really controllable, some of them are not really controllable in any way, they are very difficult to intercept. If you think about things like M-map, for example, registers of a device can be memory mapped so that user space can access them directly through memory addresses, then that is very difficult to intercept, and it's better to just get rid of user space entirely and not worry about it anymore, and this is what that is for, right? So here, in this point, we don't need to worry about user space anymore, we are purely in the kernel. That big box represents the operation that I'm calling device suspend, which is about putting devices individually, I.O. devices into low-power states. Each of the balloons here represents a loop that goes through all of the device objects registered in the kernel, so each of them transitions those objects or devices that they represent into lower and lower or more and more energy-saving states, and after that, hopefully, no device should consume energy anymore, except for wake-up devices, right? Because obviously, when we go into sleep or when we put the system into sleep, we would like it to wake up at one point, for this reason or another. So, yeah, we need wake-up devices to be able to signal something, and those have to be powered for that. In the next step, we turn off or put non-boot CPUs offline. That's because we don't want them to take any interrupts and we want things to be scheduled on them going forward. The next step is putting core system components into lower-power states. These are things like interrupt controllers. We just turn them off. And finally, when we get here, we either call a platform firmware to turn the system core logic off for us or we trigger a platform driver that we do the same, hopefully. So this is a step that requires platform support, but if we don't have that, it's not useful to do the previous two steps already. So this is the idea of suspend to idle, right? So we have a transition that looks like system suspend, but the final step is just waiting for a wake-up interrupt instead of putting all the non-boot CPUs offline, turning off system core components, and so on. So we just suspend devices. At this point, they should not consume too much energy and then we wait for a wake-up interrupt just as in an idle state of the system when CPUs don't have any instructions to execute. Yeah, that sounds straightforward enough. Unfortunately, there's a problem with it which is related to wake-up interrupts. Wake-up interrupts are wake-up events in general. So we want the same wake-up events to work in this state for these transitions and for suspend to idle in the same way. So if I have a wake-up device like an internet controller and I want it to wake up my system from full suspend, which was the previous slide, and I also want to wake it up. I would also like it to be able to wake up the system from suspend to idle so that from the user's perspective, those transitions or those states behave in the same way. That is not very straightforward to achieve. And to explain that, I need to go into these a bit. So, yeah, that's how it works on an x86 PC. We have PlatformFirmware here, which is a black box on purpose because we don't really know what it is doing and we hope that it is going to do the right thing for us. But that's how far we can go with it. So we have PlatformFirmware that hopefully will put the entire platform into an energy-saving state in which the platform will consume a minimum energy. And now I use two different colors for those boxes here and for the balloon here and for those things above. And the reason why is that at this point, we are carrying out a very special operation, which is to disable device interrupts. And originally, it was done as a hack to work around PCI bugs or bugs in PCI drivers that were related to shared interrupts. Like, don't really want to go into details with that. But this was done just to avoid crashing the system by buggy PCI drivers. But the bottom line is that from that point onwards, the device interrupts are not really handled. I mean, the interrupts handlers are not invoked by the IRQSAP system. It just marks them as pending and it will trigger the interrupt handlers at this point when we get back from this state. OK, so device interrupts are off, meaning that the handlers will not be invoked. And then we do those two steps I was talking about before. And then we call the platform firmware to put the platform as a whole into a low power state or into another saving state for us. Then when there is a wake-up event, like the user opened a laptop lead or pressed the power button or something like that, the platform firmware, again, is supposed to wake up the platform and then jump to the kernel. And then we can just continue by restoring the functionality from the grounds up. OK, that's when the platform firmware is available, and it can do those things I was talking about. Obviously, relying on platform firmware is not necessarily a good idea sometimes, as you know. So some platforms actually don't have it, but still they support the idea of putting the platform as a whole into a low power state to save more energy than is otherwise possible. And how this works or how this can work is illustrated here. So suppose that the platform has two interrupt controllers. One interrupt controller is used in the working state for handling interrupts or for signaling interrupts to the CPU, while the other, the secondary CPU, the interrupt controller is only used for signaling wake up events. So when the system goes into a suspend state, into a sleep state, the platform driver switches over from this primary interrupt controller to that secondary one that is only used for signaling wake up events. And if we have a wake up device that is supposed to signal wake up system wake up, then it has to say that, hey, I'm a wake up device and I'm going to use this secondary thing in a sleep state. And we have the enable IRQ wake function for that. This is to tell the IRQ sub system that this device is going to signal wake up through the secondary interrupt controller. And if we have that, we can just implement the functionality that was or that is carried out by the platform firmware on x86 PC just by using that hardware support. And in that state, in that step, the platform driver in the kernel actually switches over from using the primary interrupt controller to using the secondary one. And then when the wake up event happens, for example, a device gets a signal from the outside. It is for one another. Then the secondary controller will trigger and it will trigger a CPU, will wake up the CPU from sleep and will trigger the system wake up this way. And in this block, we just go from the secondary interrupt controller to the primary one. We switch over back to it. And then we can just restore the functionality of the whole system from here upwards. All right. Now we want suspend to idle to work like that, too, because we want it to look like real suspend to users. And we really didn't want drivers and other components or subsystems or bus types or other things like that to care about whether we are going to use suspend to idle or we are going to use full suspend. So we needed to make wake up interrupts work in the same way as here in the suspend to idle case. So now we have just this loop waiting for a wake up interrupt instead of all the transitions from one interrupt controller to another. At this point, we are still using the primary interrupt controller, but we want things to happen as though we were using the secondary one. For that, we use the observation that we disable device interrupts at this point and enable them here. So we use that by we kind of tapped on that. And now instead of simply disabling device interrupts, we just switch them over from working mode to suspend mode.  And if that interrupt is not a wake up one, it will just be ignored or mark the spending here. All right, so this way, suspend to idle actually works in this from that perspective, it actually works in the same way as full suspend. So we have two modes of operation. One is the suspend mode. One is the working mode. And in the suspend mode, wake up interrupts trigger system wake up. And in the working mode, they are just regular interrupts. All right, so are we there yet? We have suspend to idle, not we aren't. And the reason why is this. Well, so what if we have a kernel timer, which is periodic? That's what happens. The timer generates an interrupt and wakes the CPU from idle. We get the timer interrupts here. It is not a wake up interrupt. Timer interrupts cannot be wake up interrupts. So we ignore that interrupt and go to idle again. And when the timer triggers again, then we get another wake up and so on. So in fact, that gray box I printed on the previous slide is actually not just waiting, but looping over timer interrupts like that, which really means that it looks like it is suspended. But in fact, it is still consuming energy for handling timer interrupts. So that still is not addressed in the mainline kernel. We have a patch for that, which basically works by turning off timers before going to the idle loop here. So it just suspends the entire timekeeping system of the kernel here. And then we don't get any timer interrupts anymore when we are in this gray box below. So we don't need to worry about this particular thing. But that patch is waiting for a review from the relevant people who haven't been able to do that yet. But it's in a pretty good shape, in my opinion. So I hope we will be able to merge this particular patch pretty soon. So yeah. So that's suspend to idle. This is a new thing. And well, the benefit of it is that there's no platform support is needed for it to be useful, for it to be accessible, and it should be available to all platforms. It may not save as much energy as full suspend, but then again, it should work just for everybody. Well, there are other improvements related to system suspend that I'd like to talk about briefly. First of all, we started the profile system suspend and measured times. How much time does it take to suspend a system? How much time does it take to resume it? And how much time does it take to suspend or resume individual devices? And there's a special tool for that, which is called analyze underscore suspend.py. It's available in the kernel script directory. So it is included into the kernel source. You can use it. You can profile your own system. Well, and this produces, this is an HTML graph, and it is kind of interactive. You can zoom in, zoom out, see how much time it takes for a particular device driver to execute a specific callback, and so on. So yeah, and you get a graph like that. Well, does anyone see a problem here, particularly on that side? So user space starts to be running at this point, right? But it has to wait for all of those two things to resume, and for that one thing to resume, although all of the other devices have resumed already way earlier. And if that particular piece of user space doesn't access those two things or those three things, it could actually start running already here, right? Well, yeah, this is another trace. This was for full suspend. This is for suspend to idle. There are differences that they are not very big. Again, we have those two things. These actually are scarce devices, which means storage. And this is a wireless-fi driver that waits for everything else to resume for some reason. Yeah, and only then we start user space, right? So this is not very efficient, let's just say, and well. And where there's a problem is that Android is a big user of system suspend today. And Android really wants suspend and resume to work quickly, and by which I mean that it wants the user space to be able to run as quickly as possible after resume. When there's a signal somewhere here, there's a wake-up event. We really would like user space to be running as soon as possible, because it has to act on that event, possibly, right? Well, but the problem is we can't really help with. We can't really make those boxes here shorter. This is how much time it takes for a device to become available, because that device may be complicated. It may be a disk, and it may just need that much time to reset itself and become operational. So yeah, we can't really help that. But what we can do, we can cheat a little. And that's how we can do it. That's how we can do it. So the green code flow is for devices that are handled in a traditional way. The blue one is for devices that are cheating, or drivers that are cheating somewhat. And what you can see here is that instead of waiting synchronously for the device to resume, they actually start a separate thread or queue up a separate work queue item that's going to wait for the device to show up, and then it can just wait and allow the other things to proceed in the meantime. So what we can do this way, we can just defer the resume of those two things and move that line somewhere over here, or perhaps not that line, but that box along with that line somewhere over here. Yeah, at this time, the individual drivers have to do that trick, and we don't have framework support for that. We should probably provide it because that's a trick, and it is useful, and it may be useful in many cases, so potentially at least. So probably we should be providing some framework support for that, work in progress. So this is one thing. Another one is, well, sometimes we need to resume devices during system suspend. So I said that we had those two categories of framework where one category work on individual components in the working state, and the other category is system-wide. So if we have suspended a device in the working state and now system suspend triggers, yeah? Then we have a situation where the device is suspended at this point, and we may want to suspend it again. And now the question is what to do with it, right? What to do with it? Do we have to handle it in any way, or do we not have to? Maybe just leave it alone. So yeah, the approach one year ago and before was that we would be resuming all devices that have been previously suspended at runtime, which is not very efficient, right? Because if those devices are not wake-up devices and they don't really need to be reconfigured during system suspend, why resume them? So last year we started to work on that problem, and now we are checking the state. Yeah, the solution was that the device prepare callbacks can be used for telling the power management core that this particular device need not be touched during system suspend if it has been already suspended. And if that happens, then the core will just ignore it, right? So the callback checks if the state of the device is right for system suspend. If not, then it will be resumed. And if the state is correct, then it will just stay at runtime suspended. And we are not going to touch it during the HALT transition here. This graph is for the diagram is for a suspend to idle, but obviously it also applies to full suspend. So yeah, if we can keep the device in runtime suspended state, we'll do that. That requires support from a device driver and a subsystem. And also it requires the dependencies to be satisfied. But generally the idea is that if we have suspended devices when the system suspend triggers, then we won't touch them. Another improvement, that also is work in progress. Some support for that have already been added for a couple of subsystems I'm working on PCI today. And hopefully we'll have more of that going forward. So yeah, work in progress again. Last thing I wanted to talk about today is the reuse of callbacks, which also is a problem a bit. So yeah, every stage of system suspended in the museum requires is probably not a good word for that. But potentially requires a separate callback or even a set of callbacks provided by the driver, bus type, and if there's a power domain used, the device is in, then the power domain driver also will provide the callback. So potentially there's a hierarchy of callbacks for each of those steps. And we have well up to four suspend callbacks for system suspend for every device. Well, it's a lot. Those two are probably mutually exclusive. So if you implement suspend ORQ, you probably won't do that. So yeah, that makes it a little simpler. And in addition to that, we have the runtime power management framework, which also provides or requires its own callbacks. And so question here is, can we use the runtime suspend callbacks for system suspend? Or can we use runtime resume callbacks for system resume? And if so, then how to use it? Well, and this illustrates that, well, it's not that easy because the conditions for running this are not necessarily the same as conditions for running that or that or that or even that. Well, so first of all, the prepare callback requires no changes to be made to the device. Obviously, runtime suspend makes changes to the device because it's supposed to put it in a low power state. When this is executed, the device may still be in use while runtime suspend callbacks actually have to assume that device is not in use at this point. This one assumes that the device, the interrupt handler of the device driver is not going to be executed. So no interrupts, right? This one cannot make such an assumption. So it has to assume that the interrupt handler can be run at any time. So it has to handle that situation. Well, the remaining one that can possibly be replaced or possibly use the same code and this one is suspend late callback. But the problem here is what happens if the device is already suspended when we execute it. So it should, in principle, check if the device has been suspended. And if so, do something and if not, do nothing. And if it has not been suspended already, then it should suspend it. Well, that would involve some code duplication between drivers because then every one of them has the device being suspended. Well, if not, then we suspend it. If it has been suspended, we do nothing at this point. So yeah, people encountered the problem and introduced wrappers around 10 PM at callbacks that can be used in your, that can be pointed to from your suspend late callback pointer. For system suspend, the wrapper function is called PM runtime for suspended. They may not be very good one, but I don't know what. This is what the patch author used and I didn't have a better name for it. So yeah, that's how it's called. And that function will just do that check I was talking about. It will just check if the device has been runtime suspended. And if that's the case, it will just skip everything. And if the device has not been runtime suspended, then it will execute the runtime suspend callback for it. So that's how you can reuse runtime PM infrastructure for system suspend in device drivers. All right, so that's all I had for today. These are two presentations I gave on related things during Linux Foundation conferences. That is some source code documentation and other resources that you can use. In particular, that is a link to the suspend to idle patch for handling kernel timers I was talking about before. And that is where you can get the latest version of the analyze suspend script. Everything else is the kernel source tree. So I guess this is the time for questions. No questions? Oh, yeah, there is. With a new hardware P-State driver in kernel 3.19, will we be getting any user space tools to monitor the P-States? In the i915 driver, you mean? And I'm not sure I understand. In the kernel 3.19, I see you made some new P-State, the hardware P-State drivers. Hardware P-State, oh, yeah. You mean hardware P-State in that is about CPU freak? CPU frequency scaling. And the question is about, are there going to be any user space tools available for that? Yeah, it's the. So I don't think it is related to my topic today. We can talk about it later. No one else has any other question, so. Yeah. It is not related to system suspend really. It is about the CPU frequency. It's about the per component power management part, right? Right, that's good. Thanks. Are there any questions about that? I'm not really a kernel hacker, but from time to time, I found the need to debug suspend because it just hangs and does nothing. And I was googling around a bit, and I was somehow surprised not to find any good instructions how to debug when it hangs during suspend. Can you give any pointers quickly how to do that? Yeah, so there are a couple of things you can do. And basically they are, if you go to the documentation power directory of the kernel source, there is a basic PM debug file. Basic PM, basic underscore PM underscore debug.txt file, I think. There are some instructions in that file. You can use, we have some test modes for system suspend. You can use those modes to figure out when it hangs, basically, at what stage of the transition it hangs. And then possibly identify the device driver that is responsible for that or something. And it is described in that file I was talking about. The next thing you can use is a PM tracing mechanism that was introduced several years ago. It also is described in one file in the documentation power directory. Actually, I don't remember, but I guess I can look up the name for you. I'm not sure which one of them it is. But anyway, under documentation power, you have some instructions on debugging, including the description of the trade. So the way you use it is by using the RTC to store the mark of what was the last device driver that was called. And during a transition, when it hangs after that, you can read the information from the RTC. Obviously, it will override the date and time information that was previously in there. But then you can use the RTC memory to store it. There is some work on using a persistent store for debugging suspend.resume. I don't know how far that goes, honestly, at this point. What else? Well, one of the techniques you can use is if you suspect something, like the driver, then you can try to not to unload the driver before suspend and then try it. Sometimes, if the graphics is involved, it sometimes works either in console or in the graphics mode. And it may work in one of them and may not work in the other. It's worth trying. And yeah, there are other ways. I can't recall at this point, but there's multiple different techniques you can use. The first one I always recommend is to start using the test modes, which is you can just exercise the individual steps of the system suspend and see where it actually fails. Right? More questions? Unfortunately, we can't do any more questions. Oh, I see. Yeah, we've just run a bit quite a bit over time. If you do have more questions, though, you can take this outside. You can have fun discussions all day long. Yeah, I'll be available. So on behalf of Linux, we've got a small gift for Rafael. Thanks a lot.  Thank you.