Tom here from Lawrence Systems and we're going to talk about Project Fi and the Google Pixel 4. Well, I think it's called Google Fi now, but you know, I conflate those terms sometimes because what I signed up when it was still called Project Fi. If you want to learn more about me or my company, head over to LawrenceSystems.com. Feel like hires for a project or a hires button at the top. If you'd like to support Channel Otherways, there are affiliate links below for products and services we talk about on this channel. So I'm holding in my hand the fabric covered Pixel 4, which not everyone loved this phone. That's for sure. There's plenty of YouTube hate for it, I would say. And I'm going to say it's a very reasonable phone. I just took the fabric case off of it to kind of show the wonderful glossiness of this Pixel 4, which I'm not a fan of. Matt Black, there's a guy that talks about that, KBHD. He's very right on that. So I do agree with some of them in terms of, yeah, for what you pay for this phone, if you buy it at full retail price, it's going to be a little bit expensive. Compared to other smart phones out there that have other offerings. And I'm not here to really go into every little detail and debate about that. My experience, though, of an owner of this phone is I really enjoy it. And one of the things about the Google experience you get with Android is they give you a very clean experience under Pixel line of phones. It's the flagship from Google with all of the Google updates and features. And one of the things that matters a lot to me as someone who works in tech and security, and why I'm even talking about this, is security updates, patches and features. I don't want anything more than what I use on my phone. This is something that if you go through some of the other carriers, they load their extras on there. And this creates a lot of potential security problems. This was found through different research where all these other companies, some of these add-ons aren't as well vetted. They just want to get whatever it is they can do to upsell you. So they put these extras on the phone and to top that off, carriers and one of the more notable ones that's I think one of the most delayed when I was on their network, I don't know where they're at now was like Verizon would be an example of when there's an update for the operating system, they drag their feet and delay it.  We're not worried about security as much as worried about, you know, you not removing the extras that we installed on the phone. And that's obviously just really bothersome. Now why did I bring up Google Fi and the Pixel phone? Well, security really has to extend to both the carrier and the phone. And the carrier and the phone to me means using the Google Fi project. So it was called Project Fi. Now I keep calling it the Google Fi project.  But yes, it's now just called. You can get it at fi.google.com. And Google decided to get into the phone service business because I don't know. They want more information about you as one aspect. The other aspect is they've created a better service and no one else was doing it. They're not the cheapest service.  But they give me a lot more confidence than any of these other carriers have when it terms of people potentially hijacking your phone number. Because as much as I wish it was not true, too often your phone is the second factor of verification. They want to call and text you. So the attack method many of these bad actors will do is figure out who your carrier provider is. And the overly helpful customer service oriented people at these large carriers will frequently let you bypass any questions you put on there. Many celebrities have dealt with this directly where people have taken over their phones. And the nice thing about the way Google Fi works is you can't even talk to someone at Fi unless you have all your Google account information in order. By the way, the opposite is true.  They do offer both services. You're not getting back in either. So there is a risk of you could actually lose things if you're not organized and lose your password, lose all your lockdown on your Google account. But I'm fine with keeping all that information secure and by extension of that because the Google Fi people want to verify all of that before I can make any changes to the account. It's been really solid. Like I have a good confidence there. Now, little nuances that I've noticed as well.  One more security step I like that they take is, for example, if you wanted something sent to your phone that may be suspicious in terms of, hey, it looks like you want a reset sent. They don't send it to Hangouts. They send it very specifically to the phone. Why do I bring that up? Well, Fi has the ability to log in to your browser, logged into that same Google account, and I can make calls from my browser. I can text people from my browser. That's awesome. And you're probably thinking, well, here comes a security flaw. If people text you and reset things and you get it in the browser, that would be a problem. While texts come through for other services that are used that require like an SMS verification, Google realizes that they need to send a text to your phone to verify something because that's what you've chosen to have as your second factor. They'll send it directly to the phone and not to the web browser or any browser logged in. These are little things I've noticed that Google really seems to care a lot about security. Whether or not you feel they are a privacy-orienting company, which I know they're not, but how you feel about their privacy situation is very different than maybe you feel about their security situation. They may be like, gathering your data, they'll admit they really want to keep it. And that's something that does matter in the scheme of things when it comes to the way you manage your security around you. All these aspects have to be thought about. Now, the final things I'm going to talk about with the Pixel 4. The battery life on it, I find very adequate. This is Pixel 4 XL. I haven't had a problem with it. The camera is every bit as amazing as many of the people on YouTube have to admit that, yeah, the camera's really good on it. Google's on an excellent job between Night Sight, the photos, and to go beyond that, I also have the, because I know they didn't put a wide angle on this, but it's actually pretty wide. I go further and take some of the photos with the moment lens. I've had this since my Pixel 2, and I use it on my Pixel 4 here. So I'm really happy with the camera. I'm really happy with the fact that moment, if you're not familiar with them, I think I have a review of it. I'm probably going to do another review of the Pixel 4. It's just really impressive. Now, coverage is the last piece I'll talk about, and I found this really interesting. So my wife has my Pixel 2 now, and we're both on Google Fi. This worked amazing in very remote areas I was just at over the weekend up north. And that's kind of what made me think about this video a little bit more was, well, how well does it work as the question comes up? And I travel some, but I travel to major cities. So, yes, of course it works great. In every major city I've been in, there's international plans, but I don't really travel internationally, but they've got good coverage pretty much everywhere. But, well, how does it work in some remote areas? Well, Northern Michigan is not a very densely populated area, and I was excited that this worked. Not just worked. Worked really well. I had data, and my wife's like, what are you doing? I'm like, wow, I was replying to someone's message. She's like, I have no bars. Now, we're both on the same service, and I believe this is something that's a little bit harder to really subjectively test, but I can tell you that definitely made a difference is this phone, which obviously I didn't turn off, I think it's getting messages now, it had no problem getting full reception in rural Michigan versus I, my wife's phone was not, and we're on the same service. So, I've been really impressed. This is something I think they definitely must have stepped up as the radio technology inside of these. It's been very trouble-free. Now, pricing-wise, like I said in the beginning, a little bit overpriced for the features you get, but it works the best with Google Fi. There are other phones, such as Moto G7 is a less expensive one. That's 100% Fi-compatible. There's only a limited amount of phones in the store that work with Google Fi fully. There's other phones supported, and you can go through and figure out, they have like compatibility lists for which phones work, but of course, there may be gaps. There may be radio bands that aren't supported because you don't have the Google Fi phone versus when Google certifies in Google Fi, it's fully supported, top to bottom, no questions. And if you buy this one on Google Fi, they have a lot of offers for, when I got this one, it was more than half off through a December sale they had, and I just picked up a Moto G7 for my son, which works really well, and they have a half off deal on that. Little misleading, so to speak, on the half off, because you pay full price now, or pay half price, depending on how you want to look at it, you have to activate on Google Fi and they give you a credit on Google Fi. So yes, in the big picture, yes, you're going to get it for that price on there. It's just you're paying for it over time. So take that for what it's worth. And I'm not going to dive deep into pricing because the video is being recorded in January 2020. What I tell you the price is now, they may change it. They do offer unlimited plans. They do have, to me, very reasonably priced plans. But if you're someone who's using a whole lot of data, then Google Fi, if you're only looking at price, like I said, Google Fi may not be for you. But if you're looking for solid security and a phone that has solid, pure Android experience with good updates, the Pixel line is really good.  It's still the same phone minus a few bells and whistles that makes it a little bit less expensive. So that may be a really good opportunity when that one comes out. But overall, after using it since November of 2015, when I first started using Project Fi, became Google Fi, here I am here in January 2020, I still really enjoy it. I've had this absolutely, almost no problems at all. I've only talked to support once in almost four and a half years now. And it was because of an outage that T-Mobile had. And they had a really easy workaround. And the outage only affected some small area where I was in Michigan. And by messaging them online to figure out why the phone wasn't working, it was more of me testing them. They responded right away. As a matter of fact, they had given me a code that I could type in. They said it would last about 24 hours. It would just block because it connects to T-Mobile and Sprint's network, and I believe a couple others. It blocked trying to connect to T-Mobile's network because they were having a problem. I think this was like 2016 or 2017. I'm going back a while here. And then it was really fixed quite quickly. So it automatically cut back over to T-Mobile network. They said that after I typed the code and it worked for only so many hours to block the network and force me to be on one of the other networks. I never really think about which network the phone's on. It's not really been much of a concern.  I could send text messages if I needed to do so. So I wasn't ever out of communication, really. This is also nice, of course, when you're someone like myself and you may end up in basements of places and server rooms where cell phones just may not have access due to the location you are, sometimes in areas that just, well, not a lot of radio reception when you go inside of like a data center, but still being able to open up and have internet access through my laptop and be able to message people back and forth and text if need be or even make a phone call from the laptop. It can be difficult from a data center because of the noises and whatnot that'll be in there. But that's my thoughts on Google Fi. Like I said, really happy with it. I do have, if you want to, click it, not obligation, of course, an offer code down below that gets you some Fi credit and gets me some Fi credit as an offer. I'm always up front about the affiliate links. But I do recommend the service. I do enjoy it. I have been happy with it over the last few years. And so it's still something I recommend and something I plan to keep using. And the Pixel 4, too. Camera's amazing. Might be a separate review, but yeah. When I go on vacation, this is outstanding. Thanks. And thank you for making it to the end of the video. If you liked this video, please give it a thumbs up. If you'd like to see more content from the channel, hit the subscribe button and hit the bell icon if you'd like YouTube to notify you when new videos come out. If you'd like to hire us, head over to laurancesystems.com, fill out our contact page, and let us know what we can help you with and what projects you'd like us to work together on. If you want to carry on the discussion, head over to forums.laurancesystems.com where we can carry on the discussion about this video, other videos, or other tech topics in general, even suggestions for new videos that are accepted right there on our forums, which are free. Also, if you'd like to help the channel in other ways, head over to our affiliate page. We have a lot of great tech offers for you. And once again, thanks for watching and see you next time.


Hey everybody, so today I want to talk a little bit more about what we're going to be doing here on RetroTech in 2020 and this is going to be for March and then I also wanted to talk about what monitors that not only we're going to be repairing and Restoring for the month, but also which ones we're going to be listing for sale and kind of which ones will not be for sale first up You might have already seen the first video on this monitor But this is a 14 N6U and there was again a little bit of a mod video that we did About a week ago. So this one will first off be Completely restored and future-proofed in a couple of videos and we'll also go through and show you how to calibrate this one Because this is not a monitor that I've really covered before So the in-series now will get covered this one does do RGB So that's kind of why I've been waiting to cover this particular Monitor more in-depth, but we're good. I'm going to show you the entire Process of Recapping we're going to do this entire board. We're not going to just do the smaller section of caps like you might have seen in some other PVMs that have been restored or future-proofed this one's we're going to do the full thing because there's not as many Capacitors than this. It's a little bit simpler of a board design but it does have a full on-screen menu and it again it does support composite as video and As well as RGB and then it also does 240p at 480 i resolutions really well so it's got 500 TV lines and Again, we'll do of updated with the full series coming on that one with the restoration and the rebuild process And then at the end of that one I will announce that there will be a sale for that one most likely through eBay and We'll just start off like the others that we have in the past where it's just it's you know probably a hundred dollar auction starting point and then whatever it finishes that is it finishes that but This one will be the first one the 14 and 6 u And then There's another monitor that I've had and I'm getting ready to restore that I've not covered yet at all either and that is a 1943 MD which is the predecessor to like the 53 MD and then like the 20 M2 So this one is going back to the early 90s and this particular monitor You could see on the screen just some of the issues that it has as far as like calibration the color All the colors are there, but they're just not set correctly. They've just drifted out over time The big problem too with this one is there's a lot of Convergence issues on the screen that are going to eventually have to be adjusted as well So after that in 6 u we're going to start on this 43 MD and we'll go through And I'll Recap it. I probably I don't know we'll see if I end up doing an entire recap on this one I know there's a lot of capacitors in this one. So I doubt I'll do a complete 100% recap on it, but we'll see and Then I'm going to show you how to make adjustments on it because this one's an internal Adjustment monitor. There's no service menu on it. So you have to get in and adjust Internally with potentiometers and using a screwdriver in the back. So as I said, it's a 1943 MD it was produced in 1992 so it's a very old monitor and It does support both composite s video RGB and this one does not support component though So that one will come and then the last thing I'm going to talk about is the 20 or five because look a lot of people have Been asking me Hey, is this one going to be for sale? And look, I'm just going to tell you right off the bat. It's not for sale and It won't be for sale But I will be going through and doing some videos in the next couple of months showing you what eventually is Going to be the fate and what's happening with this monitor but I'm not going to be selling it and I just want to say if you get a chance It's really getting more difficult in 2020 now to to find a good multi format Monitor especially a larger one. I've come across quite a few 14 inch like BVMs that are D-series or Even an A-series one but not so many and any of 14 L5s, but not so many 20 inch ones they're really getting harder to get and And There's just not as many of them that are out there that are for sale because a lot of people have gone ahead and gobbled I'm up and are holding on to them, which is fine, but Just know that if you find one you might want and you really want one You might want to just try to get it if it's if it's what you're really wanting It's just getting more difficult to get them but I Hope you can use the information from the L5 series to you know help you get your L series Calibrated and set up perfectly and maybe even future-proofed if you want to go through and order that cap kit I'll be trying to make a cap kit or you know at least some kind of cap Kit or list available to patreons for the end series as well as the 43 MD series then The L5 I Probably not going to provide a complete cap kit for that because again, there's some other parts and I would just for the most part right now say go with save on Pat's kit and I probably won't though be providing a full-on Cap kit for this monitor like I do the other one so That's kind of a little bit of bad news, but it's okay It's not the L series is something that you know the problem with it is the caps are still really good in most of them and their The caps that Sony used inside of them are really high quality especially in this L5 14 or 20 inch L5 so they will last a very long time and It's it's more of an issue of you know are the replacement caps we're putting in them going to be even better than the ones that are already in them So as of right now, I know that I Will I will try to service them on occasion, but I won't probably be Providing the cap kits for this monitor, but that's pretty much going to do it for this issue our episode That's what's going to be happening in March And I will again have some more other videos not just those two monitors But those are going to be the big projects and then again the end 6u 14 inch and then the 1943 MD both of those in March will be available An auction to purchase if you're interested. So thanks again. I'll see you guys next time with some more retro content


Hello. My name is Brian Adams. I'm president and CEO of the Brain Institute of America. Here at my company, we're focused on several initiatives. The first being that we're partnering with academic institutions, academic scholars, oncologists, private corporations, all in an effort to understand how we can treat those with neurologic disorders. I feel that by working with these entities and having them involved in the umbrella of the institute, they can work together in a very collaborative and protected environment that can help them establish new questions and solve very complex problems in this space. The second goal of the institute is to develop effective biomarkers that aid in detecting the onset of neurologic disorders, as well as malignancies. Toward this goal, we focused on a particular set of non-coating RNAs and developing assays to determine the expression of these non-coating RNAs and normal cell types or normal tissue as compared to disease states. Here at the institute, we are extremely focused on understanding the science behind these non-coating RNAs. The reason for that is if we really understand how certain genes play a role in normal cell function, it helps us better understand how these genes cause disease and at what stages or processes these genes can function as biomarkers for disease onset. The third goal of the institute is essentially educating others on the amazing science going forward in the neuroscience field. Across the globe, thousands of scientists are dedicated to unlocking the mysteries of why certain diseases begin and making a concerted effort to treat those disorders. So in conclusion, the institute has a number of objectives, primarily bringing together academic scientists and private companies. We are dedicated to develop novel biomarkers specifically focused on non-coating RNAs to detect neurologic disorder at a very early onset. And then we have our education and outreach program to train new scientists for them to understand how cool RNA science is and how we can push the field of neuroscience forward. So with that, I thank you very much for your time. I do ask that you look at our website and if you have any questions, feel free to contact us. Thank you.


The ability to regularly communicate with your audience over time is really important. I'll just tell one quick story, a campaign that I contributed to. Every one to two weeks I had an email with an update about what was happening. What was great about that is the things you're going to learn from your funders. They were amazing. And what that entrepreneur was able to do was able to connect with so many people who could make suggestions or resources to make their process more efficient and more effective.


Hi, so we are going to talk about sustainability in the container native way. My name is Huang Mingxian, I'm working as a Red Hat's emerging technology team. My name is Chen Wang, I'm from IBM Research, I'm a research staff member. So the agenda for the day is that we're going to talk about the power management, power measurements in theory, and how we're going to do it in practice, and we'll introduce our projects for power measurements called Projects Capital, and we're talking about what's going to do use these projects for what's coming up in energy conservation, and we are going to be excited to share with you what has been happening in the community, and Chen will give you a demo for these projects. So as a refresher, energy measurements is not something new, it has been going on for many many years. We are talking about, we have both theory as well as the methodology. In reality, we care more about the question how we are going to manage the energy consumption indirectly or directly, especially in our operating system that is shared by a lot of running containers and processes. And now we come to the second question is how once we get the energy measurements in place, how can we attribute these energy consumptions to different processes or containers fairly and accurately? So this is about the two questions. So if you go to the wiki page, you find us there's a very exotic explanations about energy measurements in a digital world. The the gist of the idea of the measurements is that there are three components in the CPU energy consumption, the dynamic, the short circuits, and leakage. The detail of which you can go in deeper into the wiki page, but what you see matters here is that the dynamic energy which is consumed by running the CPU instructions is the major components of the CPU power consumption. And there's also something called leakage currents, which is the current the current needs to make the circuits running, even there's nothing going on. The dynamic power is determined by three factors, the capacitance, the number of circuits that are running. The voltage in real time in the data center, specifically, is not something you can tune. So we just leave it as static and the frequencies as which the circuits is operating. So just keep in mind that we have two things, the capacitance and the frequencies. That's the two things we want to get a hold of when we come to the power measurement. So now we come to the methodology. If you are electricians, you can attach the power meters to the circuits and measure the powers of each circuit and the durations and the frequencies. But in the software world, that is not something we can do. So we have to think about something creative. The way we are doing the measurements in software world is that we use certain things from the CPU, from the software counters and from the system measurements. For frequency, we use in the average frequencies that is running inside of the software, we can read from the CPU counter. Specifically, if you are running the x86 CPUs, there's like an 8-perth counter, you can read over the time what's the frequencies, average frequencies during the time intervals. That is used for our estimation. For capacitance, because we do not have great ways, or that's an impossible way to monitor the number of circuits being running. So we have some creative ways to use in the CPU instructions. Because the CPU instructions have very deterministic ways to use in the circuits on board. So by measuring the number of CPU instructions, you have good correlations with the number of, with the capacitance, with the CPU instructions. Finally, we also want to have the execution time. That's for the circuits to stay on. Since we do not know exactly how many times the circuits is being stay on, we use something indirect, we use the CPU cycles. As long as the CPU is still running, the number of cycles we count will be a good measurements of the execution time of the circuits. Now with the measurements in mind, the second question we're going to answer is how are you going to attribute your measurements to the consumption of each of the processes or just the containers. If you are familiar with this space that you have seen a lot of software projects or software packages, that's trying to answer this question. They come from different perspectives. The way is that every one of us agree on that we have to use utilization as a proxy and you attribute to your energy consumption based on the utilization. But that's the end of the agreements. The disagreements is how we're going to measure the utilization. Are you measuring the utilization based on time, based on the actual counting at the kernel level or as your measurements as the whole stack? Our ways of attribution methodology is that we measure the execution time at the kernel level. Whenever the process gets running, we start our counting. Once the process is scheduled out, we take a snapshot and we're using that to accumulate the stats as the benchmark for our estimates. In this way, we can fairly, accurately attribute the energy to the processes without the loss of transparency. Just putting things together, the way we're trying to measure the physical CPU or memory or any of the digital device is using the methodologies as approximations to the real-world energy measurements. We use models that we can derive from machine learnings to improve our accuracy. When we come to the attribution, we are trying to use the utilizations that's actually consumed by the process or containers to estimate the energies consumed by these entities without losing accuracy. This probably sounds simple, but that's the fundamental ways, the fundamental differences. All projects is different from the others. Now we have introduced the projects we have been working on. Collaboratively, it's called a Kepler. It's a Kubernetes-based efficient power level exporter. If you are a science lobby hobbyist, you can use it. It's constantly related to the astronomer, Johannes Kepler, who has these laws of planetary movements, and also correlates with the NASA, Kepler, the telescope. That basically means the same thing. You have to have certain ways to measure precisely and proportionately in real-world. Kepler is focused on three things. I want to do three things in the best way. It's about reporting. We are trying to collect information from the system about the GPU, CPU RAM, as well as the other hardware resources we are trying to measure. That's where we consume energy that we are trying to measure. What we are trying to do is both on bare metal as well as virtual machines. If you are running the machines on, for example, the hybrid cloud, you could have some of the energy stats coming up as well. We are trying to, because we are living in a Kubernetes world, so we are using a CNCF ecosystem. Prometheus is the way to go, so we export the stats from Prometheus. The way we collect this information about the performance counters, the CPU cycles, and the CPU time is through EBPF. This gives us the ability to attach to the kernel trace points and collect the snapshots of the performance counters without losing lots of overhead. Lastly, we are trying to use the science-based regression models to improve our accuracy of energy estimates. The first paper, because of this now we are in Texas, the first paper I read is about using performance counters to estimate power consumptions on a different level of the systems was of the paper done by professors from the University of Texas in about 10 years ago. So it's an interesting coincidence. We come to here to have our presentation. The architecture, it looks like the bubble upgrade. So if you are looking at the bottom, we are connecting data as the kernel level using EBPF. So the EBPF attached to the process switch function and collects certain information. And as those take a snapshot of the performance counters and take the deltas and push off that information to the data aggregation. On the left side of the data aggregation, you have the energy accounting stats. On the S86 platforms, you have Rappel. On other CPU platforms, you could have some other CPU energy counters. And we want to collaborate with vendors to see how we are going to get the information from there. On the right side of the equation, you will see different stats we collect as the aggregation layer, stats from the kernel EBPF, and stats from the CGRU file system, and stats from GPU libraries. Specifically, in this case, we use NVIDIA's GPU library to get the GPU power and process data. And we also collect data from the hardware monitors, information like frequencies, and we are going to have the information like temperatures as well in the future. We put all everything into a regression model that we are going to explain later. That's used to derive by the model server. And we're using simple regression models like linear regression to stats. And in fact, many of the research suggests linear regression is very powerful. It gives us lots of accuracy in energy estimates. As the data presentation layer, we present a package of data in the formats that we are going to be useful. Prometheus is the current what we support. But actually, that can also work with open dynamics as well. We are going to investigate that later. So the capital itself is not able to figure out what the models that's going to be used for power estimates. So we're using a thing called a model server to make these things happen. So capital as a process will export all these metrics as the power stats, the rapport data, the performance counters, C groups, file systems stats, information like that through Prometheus. On the other side of the Prometheus is the model server. As we are taking these stats, running these continuous online learning, and then build off the model. Once the model is satisfied to our consumption, the capital will just download these models through the Flux endpoints. And they're using this model for power level consumption estimates. And those estimates will be exported through Prometheus again. So you see there are two export points. One is for the model server. The other one is for the reporting purpose. At the power level, the energy consumption. And then with that, I will turn over to Chen for the demo of the running capital and running the dashboard. So thanks for having me. So basically today, we will show a very, very simple demo, running a Kepler exporter in microchip cluster installed on a biomedical machine, where we have the NVIDIA GPU car. So the necessary prerequisites for this is you need to install NVIDIA GPU operator, of course. And then we install Kepler and keep Prometheus to visualize the Prometheus data to load our Grafana dashboard. So let's start with a brand new microchip cluster on the biomedical. And sorry, I pre-recorded it because we needed to wait a certain time for the workload to show the energy data. So now we are in a brand new microchip cluster. The first thing we are going to do is to deploy Kepler exporter. And so we just go to the GitHub report, clone the Kepler report, and then there would be a deployment YAML file under Kubernetes deployment. What it has is a bunch of RBAC rules, service account configurations, and also the deployment YAML, the demo site YAML for the exporter. And here in argument, we enable GPU as true. So we will later show not only the energy consumed by CPU, but also the energy consumed by GPU.  Fund the Kubernetes deployment YAML on the manifest. And then all the cluster or service account will be created. So then we see the Kepler exporter part is running on the monitoring namespace. And we can first check the available metrics from the log messages. And here we can see for different pod names, we got those performance counters like CPU time instructions, disk write and read, et cetera. So based on those hardware counters, Kepler has a model to estimate how much energy one pod is consumed per component, such as CPU, GPU, DRAM. So another way to check the availability of the Kepler metrics is through its endpoint, which is on 9102 pod. And here we can export all the CPU scaling frequencies, pod CPU energy current, meaning this is the energy consumed per second for this pod. And then it is also we are showing the DRAM, CPU, and GPU energies in different components. Of course, we are showing the total energy consumed per pod. So of course, we need then to install the Kube permissions project. We already cloned that project here. So we just get into the folder. And if you get to the Kube permissions GitHub report, there is three lines of installation command you can use. And then you just copy them. And then it will set up all the necessary permissions stack. So we do the same here. And then we need to get into the Kube permissions folder. It takes about two seconds to install everything. Now the permissions is also installing our cluster. What we are going to do is to go back to our Kepler project and then configure the service monitor customer resources to actually configure the scraping interval of the Kepler demon site to permissions. So it's a simple CR, and it allows you to choose the application selector labels. And then it allows you to choose the intervals for scraping. We go ahead and create this CR in the cluster because the permissions is already in store. So it's a permissions operator. And it automatically recognizes this service monitor CR. So we double verify if service monitor is already available on the monitoring namespace. Then we won't validate while the permissions UI. What we can do is we can do a simple SSH tunneling to the bimetal machine and then also do part forward for the permissions endpoint to our local host directly. So this SSH tunnel, tunnels the remote 399 to our local 99. And then we have another part forward command to part forward the permissions endpoint to 399 on the remote host. So then let's go to check the permissions UI here. We have all the energy consumption metrics available. This part manager stack, we especially make it an object. So it includes all the necessary performance counters and also the energy consumption metrics for different components for a particular part. So in this way, you will get all the data in one query. And then it can be later used by all types of resource management optimizers like auto scaling and scaling. Also, if you have some particular controllers, those data is also available. So let's take another example. Here is the current energy per part. And if we choose a particular part here, which is the alert manager on the monitor namespace, part of the monitor stack. So we can see some data because the coupler is just running. So it only has around less than one minute data. What we are going to do next is in Kepler project, we also have several dashboards you can try out. And then we will similarly, we will do SSH tunneling to the remote host and port forward the Grafana dashboard to have a local host. And then we will show an example how to import our Kepler dashboard to Grafana, to the default Grafana. So now we are already tunneling through the remote 3,000 port. And then we can check the default Grafana dashboard first. Default password is at main, so we need to change it when we first log in. And then here is some default Grafana dashboard available in Kube permissions to show the research utilization of your cluster. And then next, we are going to import our Kepler dashboard, one of our Kepler dashboard. So I already cloned the report in my local laptop, so I just choose it from my local laptop. And then what you need to configure is only the permissions data source. And that it works. So this is a simple dashboard to visualize the Kepler metrics. And on the top, we kind of convert to the energy consumption to the equivalent pounds of coal, petroleum, and natural gas we will burn for a particular application. And you can choose the application while the namespace. So next, what we are going to do is we are going to deploy two types of workload. One is a CPU intensive workload, which is basically generating some random numbers. It's a simple command line CAD-DEV random.  And then the image is just Ubuntu image. So similarly, we will test another GPU intensive workload, which is the vector addition workload. We got from a video report. It will only use one GPU. So now all the pods are running. We should get back to the Grafana dashboard. First, let's change to the smaller window. And then this is still the monitor app. And then here, I kind of cut one minute video so to wait for the workload to run. And then the default pods are on. And we see there's still just a small amount of data, similarly for the GPU. But you can already see less than one minute data. And here, we can see for the GPU workload, and then the major energy consumption is from GPU. And if we switch to the CPU intensive workload, apparently the GPU DRAM usage is zero, and CPU is 100% of the total. So that's just a simple demo to show how Kepler is visualizing the energy consumption per application for different components. And the below two charts is showing in this namespace what is the PQ usage application. And then the bottom right one is showing over time how the energy consumption is building up for different namespaces. And what's important is we also use the default Grafana dashboard to show the resource usage of Kepler demo site. And then you can see the received packets and transmitted packets is only 70 to 100 packets per second. And the CPU usage is only 0.02 cores. And memory is about, let's go back to the memory a little bit. The memory is about 150 megabytes. Yeah, sorry. Here, it's always below 150 megabytes. OK, that's all of the demo. And let's go back to the presentation. So in summary, the data we are able to export it while Kepler right now includes all those CPU statistics, including energy consumptions, the CPU timeshare, the frequency of the CPU, and all related hardware performance counters like the number of instructions per container, and like the CPU share. And for memory, it's the same. It shows the cache misses per part and the resident memory size per part as well. In GPU, we can show the energy consumption and resident memory size, and also as well as the IO stats. And then in the future, we want to integrate this energy consumption with the carbon intensity APIs. So we not only show the energy consumption per part, but also show the carbon footprint per application. And then to further take advantage of this, Kepler, we also have some ideas like using those data to directly do the sustainable resource management, including auto scaling and scheduling, to further optimize the cluster management, resource management. So we welcome everyone to join us in this sustainable computing community. And we welcome all the comments, issues, and PRs in both the report and on the Slack channel. And then we want to send specific thanks to Intel and Waveworks for their good comments, suggestions, and ideas. That's all of the talk. Thank you. There were labels that were being emitted that kind of averages. Is that the case? Maybe I misread it. I think it is. Wouldn't the data card analogy be very high? Oh, yeah. That's a very good point. So when we build the card. Could you repeat the question? Oh, yeah. So for questions, when we have some of the labeled counters, some of the real correlations between the counters have a certain level of correlations. Well, so in some of the counters, I was seeing averages. Now let's go back to the screenshot. Oh, no, not the screenshot. I think it was in the demo, actually. OK. I think some of the labels were averages if I was reading it correctly. OK. Here? Yeah. So the energy pool, I think it was. A lot of energy pool or something like this one. OK. Average CPU problem. Sorry. Almost there. Yeah, so this one. That's that? Well, maybe I'll do this one. Yeah. OK. Average CPU reference. Wouldn't the data card melody on that be very high? Because you're committing the average as a label. So basically, any time it doesn't match, you admit a new metric. So for the new metrics? Oh, OK. Yeah. So we take this as an average over the sampling period. So we actually have, because the average is about, there was seven core A's cores. So average is about the A's cores. Over the time average. So if you are looking at the scale, I think the scale itself looks a little bit, probably the absolute number is not something that you are interested in, but the range. So each of the CPUs have its own range. As long as we see a certain range, I think the energy is about the same. So it's not the A's? The absolute number is not the absolute number. We are talking about the frequency range. My understanding is that when you tune the x86, you have certain scales, like 10 or 20 scales you can tune. As long as you are fitting to some of the scales, it's going to be similar frequencies. Because of these frequencies, the absolute numbers will be something very hard to get. You have so many cores and so much period. It's probably going to have a lot of variations. So based on the scale, then you kind of... Yeah, but still, the next question is, do you want to have core levels granularity or just like average core level granularity? That's going to be a scientific research in terms of follow-up. Yes, Scott, this gentleman first, would you do not mind? Yeah, let's go ahead. Yeah. Yeah, I was wondering about the linear model. Can you explain more of that? Yeah, so the question is whether the linear models are valid or how we're going to test this. The answer is we learn from the scientific research papers. The research I just mentioned from the University of Texas, the way they do it, they attach the parameters to each of the components, the pure memory and the disk. And they use the linear models to estimate the power consumption and compare with the power meter readings and they come up with accuracy. In the ideal world, we do the measurements where it should be doing the same thing, because we do not have this expertise in lab. So we just assume that the readings we have come up from the ripple counter is good enough and that's where our ground truth when we come up with the estimates. All right. What values to emit? Model server needs input from the processor in order to know what to base that on and I'm curious what the bootstrapping process is. Yeah. Yeah, so that's a very, so the question was how the model server and the capital were working together was the proper bootstrapping process. So that is a very good point. The ideal way, the way we are still under construction in the first place. The ideal way in my opinion is that we export all the node levels that's first and that is picked up by the model server. So model server will come up with the Russian model and then we'll tell the capital we just go and check the endpoints of the model server and download the model server and it gets the coefficients and estimates the power consumption. So that is the bootstrapping process. But once that bootstrapping process is finished we have a model in place. That's model can hopefully be ported to other environments as well. So when other capital process starts they already have the basic model to use start with and then during the learning process they're still emitting the node level stats and the model server will continue to improve on this initial model and come up with the better model. So I understand this is going to be a loss of learning and training and a validating process. So that's going to be many of the machine learning expertise built into the way. We are still developing this process and if there's a community has better ideas, better expertise can help us thus it's very appreciated. So regarding to the question of the model change and what is the other change? How the difference between the... So I still got your question first. If you don't mind just repeating it. And actually what we thought was seven instructions equals 10 watts is actually seven watts. Versus the process actually just uses three less watts than it did previously. Oh yeah, so for the question of how we're going to estimate if I just rephrase the question. For the question of how we're going to tell the difference between the process of using less watts and the different conditions. My gut feeling is that based on this paper again, based on this research again, if the counters and the linear regression models are sufficiently accurate, they should be resilient to the conditions of whether the power is off, certain conditions is fractured over time. But I do have your point that certain things are not being built into the regression model yet, even in these scientific research papers. So that is going to be investigations we have to carry on in the next phase. So there are uncertainties. I trust your intuition. And I do believe there's a certain knowledge you can still leverage, but whether that's where bring us to the end game is to be known and to be investigated. And there hopefully going to be some resolutions or some methodologies we can establish in the future. Yes. I have a distinguish between, like if the model gets updated, is there a way to distinguish between decrease in power because it's actually the model was reflecting the wrong data before? I see. Versus an actual power. I see. Yeah, so regarding the model accuracy versus the ground truth. So that kind of thing. So I think that this will come to the validation parts. So when we train a model, we also validate, right? So we get, you know, as I said, 100 samples for training. Some of them will be for the validation. So if the validation does not work, then we are not using this model at all. We only use the model once the validation phase we are passed, like the 95% accuracy for validation, then we're using this model. If that model is broken, only gives like 80% accuracy, then we are not seeing what's the end result, the predictions. Yeah, I can add something here. So in the online training, right? So what additional ground truth data you can get, right? So if you already have a very accurate baseline model in there, you already know, like, what the core containers are consuming, like the core containers used by Kubernetes, right? The default containers in Kubernetes. And then any additional new applications we add to that gives you new data. And that data serves as the additional data you can improve your model. Does that answer your question? We still have half an hour to dinner, so feel free. Do you have a question from the virtual? All right. So we solved the sustainability issue for the world. We're good. Thank you. Thank you.


This study examined the effects of excessive screen media use on the development of young children aged 24 to 36 months. It found that spending no more than two hours per day of screen time had minimal negative effects on development, while use beyond this amount was associated with poorer language development. Additionally, it was noted that when children co-viewed with an adult, sibling or other child, and when parents also had less screen time themselves, there was less excessive screen media use. This article was offered by Angel Bell CDY, Elaine Blythe CDY and Samantha Katrina Santos.


It takes, there's a phrase, it says it takes two to tango, right? And three for the politics to kick in. And if you add more people, which is if you have a large team, then that's a good breeding ground for various dysfunctions. And software development, if you leave some of the simple application aside, it is a team activity. The more complex the software, the bigger the team. And if you look at any of the industry analysis reports, the success rate of software projects is still pretty low. And the software projects fail not because we don't have smart people working in software industry. In fact, it is the other way around. The smartest or the smartest actually go for ITEC nowadays. The projects don't fail because they're not enough good processes or not enough tools. The projects fail because all the individuals are not aligned with the team goals. And those are some of the dysfunctions. So software development, just to reiterate, is a team activity. And I would like to ask the audience here, can you name some of the dysfunctions that you have seen? Maybe not in your org, but somebody else's org. You can assume everything is rosy in your side, but can you name something? Some of the dysfunctions. Anyone? Lack of collaboration among developers and testers. Not enough clarity and accountability and responsibility. Not good roadmap. So the team doesn't know in what direction we are moving. Good. So lack of clear communication across different functions, not just developers and testers, but the business folks, the sales, the support, and everything. What else? Overhead of processes. Maybe sometimes the processes become the end goals. So I think you all gave some very good examples, like lack of accountability, inattention to results, and so on. So there can be lots of these dysfunctions within an organization. And when I say organization, I'm not implying a large enterprise, but in the context of maybe a product, group, a team, or a division wherein some software is being developed. And there's a big debate about agile and these kind of dysfunctions. So there are two camps. One camp says that to really for agile to be successful, you need to take care of some of these dysfunctions first, which means as an organization, you could be spending next one year or two years just fixing these issues. And if things don't work out, in agile adoption, you blame it on these dysfunctions. The other viewpoint is that agile is actually a new social contract. It's not about just products. It's not about individuals. It's about the social interactions. And when you bring that picture in the forefront, agile can actually help remove some of these dysfunctions. Of course, it takes time. But better if you continue on the existing path and don't introduce a change, you will be worse off than actually introducing the change. So the only constant about change is the change will always be there. So either you don't change and perish or you change. And agile, by its nature, when it embraces change, it helps in alleviating some of these dysfunctions. So that's my opinion. And in the next 20 minutes, I'm going to talk about how different types of these dysfunctions can actually be alleviated through agile. There's a wonderful book by Patrick. How many of you have actually read this book? OK, a few hands. If you haven't read it, I will highly, highly recommend. It's like a fable. It's not like any other book. It's like a story. You can finish it in one sitting. And it gives you a beautiful structure, help you familiarize with how these dysfunctions feed into each other, starting with the bottom, which is absence of trust, to in the end, where you don't get the results you want. So the end result is a failure or less than optimal results. And this book was published more than a decade ago, even before agile was mainstream. And what I have done is I've tried to link this pyramid, these five dysfunctions, to how they surface in our world of software development, and how agile practices help us remove some of these. So I'll start with the first one, which is lack of trust. What defines lack of trust? According to Patrick, it's the unwillingness to be vulnerable within a group. When you're defensive, you will not tell the truth. You will try to always portray that everything is fine. You will try to defend your decisions and not be receptive to feedback. And how does this manifest in our software development? To start with, we got silos, unless it's very common, especially in outsourced world, where we got some development team sitting in one place, testing team sitting in another continent, and the business folks probably could be yet another place. And things are just thrown over the wall. There's lack of appreciation for the job that each function is bringing to the table. And it's all then about the organizational or the cross-functional, us versus them. I've seen it n number of times. I'll give you one example. So this was a time when one of the products was in really crunch mode. The code was churning very fast, and the build quality was poor for various reasons. So as a result, what was happening, every time the testing team picked up a new build, they hit blocker issues. And what development team was trying to do, they were trying to help. So they said, OK, let's not wait for the next build. Why don't we just take patch after patch list? We'll keep patching your testing environment. Or you come and sit with the developer, help debug some of these issues. And I heard a comment from a QA manager.  It's like we are helping the developers go through this exam by helping them. And we have this backlog of all this work to do, and we are going to fail. They're thinking by helping all the energy that they're spending with the developers that they will not get enough time to do their own job. So developers are the superheroes. Their job is done, and I'm the failure. That's typical us versus them. And this also results in information control. If silos are not bad enough, people try to control information even further. Again, to share some of the examples, I used to get daily reports from various product groups. And those reports were about the various bug metrics, how much test coverage has been done, the test planning, et cetera, et cetera. And one day, I spent an hour with the test manager trying to refine that dashboard in terms of the information that was coming. And I posed a bunch of questions, and the development manager happened to pass by. And since I had been asking a few tough questions the previous days, the next day, the reports stopped coming. Why? Because they thought, oh, maybe this information can be used against me. People are just not, when there's lack of trust, people don't want to be transparent. So how can agile help in here? So I think it starts with the concept of team, where the team's identity is the team, not individual functions. In fact, the individual functions of developers, testers, can be interchangeable. And that's what builds that trust, that we are all part of that same team. And what helps on top is all this face-to-face interaction. When you meet those people every day versus just getting emails. By the way, email is the worst mode of communication nowadays, because half the context is lost. Having these face-to-face interactions, daily stand-up meetings, pair programming, these are the things which help build that identity of the team and the trust. Now, when there's lack of trust, people don't engage. Or even when they're forced to engage, that engagement tends to be superficial. This is a beautiful cartoon picture which comes from a book by Jim Kramer. It says Moose on the Table. That's the title of the book. Again, wonderful reading. The whole idea this is trying to convey is you have a big problem sitting on the table, and everybody's pretending that the Moose is not there. They're just working around it. And they're doing other things. And that's a dysfunction. How many of you have seen gone into the meetings wherein you spend an hour, two hours at the end of the meeting?  Didn't we waste time? Has anyone of you felt that way? How frustrating it is. When people don't come to the point, they're just beating around the bush. And again, agile is not a silver bullet, but again, when team members, not just one person sitting in a corner who says, go and build it, when the team itself is involved in that planning process, the estimation process, there's a discussion, there's a debate, and there's a meaningful debate, because those people are working together on a day-to-day basis. They've built some sort of trust. They can argue in the meeting and still come out of the room with smiling faces. And what helps in terms of controlling that analysis paralysis is you have time box decision making. And the other thing is that if you truly agile, you are delivering customer value on a frequent basis. So you don't need to sit and keep analyzing what if, what if, what if. Sometimes just building it and shipping it and getting that feedback is a lot more productive than just thinking what ifs. And in this web application world, how many of you are familiar with exposure control or A-B testing? It's a wonderful way to get early feedback to avoid this kind of analysis paralysis. You quickly, you think of some idea, you build it, and expose it to a small set of customers. This is what Facebook, Google, Amazon, they do it on a daily basis. They build new features and expose to a small subset. Get that feedback. Use that information as a feedback loop to improve the end delivery. Now, if you go to that pyramid, the third dysfunction in that pyramid is lack of commitment. So of course, when there was a lack of trust and there was lack of meaningful debate, people sign up without real commitment. So there's not a real buy-in. It's a very superficial, yeah, I'm doing it because I'm doing it because I've been signed up. But that passion, that commitment is not there from inside. And how does it manifest? Various ways. One of the things I've noticed in a lot of teams is because there's not enough debate, everything becomes high priority. I had to deal with one situation wherein even though the team was supposedly adopting agile, but their initial, because we're still learning, their initial set of user stories, the product owner came back with 97 user stories. And when asked to prioritize, he said 95 are must ship. That's prioritization. 95 out of 97. And I really got into a debate for them. I asked him, do you really think all 95 are showstoppers? He said, yeah, because that's like the base functionality. Competition has it. We have to have it. My response was, you can take it in writing to me. If you want everything, you will get nothing. Because I can guarantee you all 95 will not be done, because they're always unknowns. And I think that got the message across. And the team then went through another round of prioritization. And they came back with three buckets. The must have, important, nice to have. And it was sort of equally distributed. And when you go through the superficial commitment, people are very hesitant to change, because they feel, oh, if I go through this another change, means we'll go through this analysis, paralysis again. And we never get to the decision. So how can agile help in these kind of situations? One, I think there's a strong emphasis on teams. It's the teams who actually pick stuff from the backlog and commit to it. It's not somebody else from outside saying, thou shall deliver x, y, z. The team is going through the backlog. They plan their sprint. They go through the exit criteria of the sprint. They do the demos, and they deliver. So there's a sense of that commitment, ownership. And what helps is, anytime there's a change, you have a prioritized backlog. So you stick things in the order of priority, wherever the new change belongs. So that way there's less randomization for the overall goals of the team. Now this is a big one. I think that Lady Howard mentioned about accountability. What is accountability when people hesitate to call out the bad behavior? Who do you think really owns the product? You get different answers. I'm curious, some of the answers you might have. What have you heard maybe from teams when you really press them hard? Who do you think owns the product? Any answers here? I'll start with. I've heard saying, don't know. Or maybe it's my boss. Anything else you have heard? Everybody owns it. So if it's everybody's problem, then it's nobody's problem. The best one I've heard was when I asked, who do you think really owns it? The answer was CEO. And I was like, CEO, why do you think it is CEO? Oh, because CEO set the direction. He made a big announcement to the press that we are going to deliver blah, blah, blah next year. So he's the product owner. That just blew my mind away. And you end up in this kind of this scheduled chicken. How many of you are familiar with this term scheduled chicken? Anyone? So scheduled chicken is basically when you have dependencies across teams, you're waiting on somebody else to call out that they are off the track. So then so that you can use that an excuse because the team on which I'm dependent on is delayed, so I'm delayed. So scheduled chicken is that each one is waiting on to call out the other one. Who will confess first?  And the blame game starts. This is a nice example of not my problem, lack of accountability. This is a picture of a road I took. You can see what's wrong with it. There's a big, high-tension electricity tower on the edge of the road. So this is probably version two of the road. Version one had maybe two lanes. Then they widened it. I did one more lane. And nicely put a lane marking also. The guy did his job, removal of the pole. According to him, not my job. So the sense of excellence or pride is missing in this case. And that's where Agile helps. Because when you have a clearly defined product owner, anybody can go and talk to that person and debate and argue and have that passion around building that product, half the problems are solved. And when team has a daily stand up, the focus is not on blame game, but finding out what the impediments are and how to overcome them. Every day team is looking for moving forward and not trying to figure out that scheduled chicken. And the team is making itself accountable by having commitments, not just commitments at the end of the project, but commitments at every sprint with where you actually do a live demo of what you build. So the final, this is the most important one. Because if individuals are putting their needs first, then the collective goal, which in this case is the working software, then you never got the results you wanted. How does it manifest? How many of you have heard this phrase when you ask somebody, hey, how is the project going? Are you done with coding? Yeah, 90%. Are you done the testing? Yeah, yeah, almost done, 90%. The fact is when if you hear the 90% phrase over and over, you actually need to do a multiplication by from everybody you hear. So 0.9 into 0.9 into 0.9. So your probability of getting that thing on time is probably 50%. And when the team is in these kind of dysfunctions, instead of what the end goal is, the process itself becomes the end goal. Too many times I've seen where there's heavy focus on dashboards. Oh, this is red. Why is it red? Why this is yellow? When do you think this yellow will turn into green? And there are lots of reviews. Review after review, there's a war room being set up. Everybody just going over discussions. There's not enough background information around it. And in the end, it's the bad quality. And the stuff that the customers reject. And if you look at agile, one of the principles is focus on the customer, not the process. Process is secondary. If the stuff doesn't work for customer, it just doesn't work. And the focus is not on PowerPoint presentations. Focus is not on those dashboards. You could have nice green dashboards and the product could still fail. The focus is on working software. And what helps is clearly defined sprint goals and clearly defined working software as a proof. So with that, I believe agile brings in a new social contract, which helps break down some of these silos, helps break down these walls, and helps alleviate some of these dysfunctions. And that's the end of my presentation.


David, how are you doing today? Good, good. Hey, how does defense try to move forward after game like that yesterday? Just got to correct our mistakes. We're on a short week, so we know we got to put it behind us and be on to the Patriots. Well, we're about to watch it as a team right after this. But we know what we got to correct, and we just got to correct it fast. And we got a game on Thursday, so we got to be ready. Did you get the sense that they would try to target me? Yeah, they'd go after you and see you after.  But no, I didn't get the sense, no. I mean, when you look back at it, do you feel like they were going after you? No, I do not. On the screen early, the big guy comes out. How do you do that next time? Do they do the screen over there and throw it back later? Yeah, it's covered too. I got to force them back. I got to force them inside. Just we got to play together. We got to execute the game plan. Didn't play together or something? We definitely got to play better together, definitely. Communication was all for anything? Just like I said, we got to execute the game plan better, communicate better, just play together better. Felt like they've been doing that since AJ's really good play. Yeah, I mean, there's two sides of the field. So yeah, definitely. How do you deal with that mentally? Just got to make plays. Got to make plays in one of my one-on-one matches. How do you feel like you've been doing that? I feel like I've been doing good. I feel like I still got a lot more plays to make, and I will make those plays. Yeah, and this mentally, when the unit has a quarter like that, how do y'all try to move forward and get ready for a quick game on Thursday? Like I said, it's a quick turnaround. So we got to move on and move on to the next game, get a game plan today, and execute it.