WEBVTT 00:00.000 --> 00:10.400 Hello everybody, I'm going to talk about PowerLetrics, which is a scalable infrastructure 00:10.400 --> 00:13.960 to measure your energy because we've seen, we've heard lots of talks aren't important 00:13.960 --> 00:16.360 is to measure the energy, right? 00:16.360 --> 00:23.080 So, here we are, and we are green coding solutions and we basically build software to measure 00:23.080 --> 00:27.560 and obviously optimize our ICT footprint. 00:27.560 --> 00:32.080 So, the problem, and we've heard it before, we all know the world is burning, we somehow 00:32.080 --> 00:39.120 some people care, we know that ICT produces loads of CO2, not like water obviously and 00:39.120 --> 00:43.800 all other resources, some people know that, but a lot of people know that like everybody 00:43.800 --> 00:50.960 talks about flying, but ICT is using far more, just like producing far more CO2 than flying. 00:50.960 --> 00:56.440 If we were to tell people you could save up to like 50% we saw the slide, that utilization 00:56.440 --> 01:00.800 levels are 12%, like we can save it, we can do this, right? 01:00.800 --> 01:05.160 There's a huge saving potential, but people aren't talking about this. 01:05.160 --> 01:08.800 And then when you talk about, okay, where are these say potential, nobody really knows, 01:08.800 --> 01:12.240 like when you talk to industry, when you talk to people, how much does your laptop really 01:12.240 --> 01:16.680 use, how much does Spotify use, nobody really knows. 01:16.680 --> 01:24.080 So, really enough Linux is in a position where we've been overtaken by Apple and Windows. 01:24.080 --> 01:28.720 So if you look at Windows, have the estimation engine, that's really good, that's a really 01:28.720 --> 01:29.720 good estimation. 01:29.720 --> 01:32.600 It will tell you, really jewel-wise, what processes are taking, they've done a lot of work 01:32.600 --> 01:38.280 on their flow of benchmarking, even macOS has power metrics, power metrics, which gives 01:38.280 --> 01:43.120 you fairly good estimations on energy footprint or energy values. 01:43.120 --> 01:51.720 Linux, pretty much has some ideas, but really doesn't have anything standard, there's some 01:51.720 --> 01:58.680 solutions, despite it being 70% of the server market, on the mobile phone market, we can 01:58.680 --> 02:04.080 get Apple readings, but that's also Windows and Mac, so it has also energy metrics on 02:04.080 --> 02:09.120 the CPU level, but nobody can really expose them because of security concerns, right? 02:09.120 --> 02:12.320 You can't really, it's very difficult. 02:12.320 --> 02:16.720 So we have models that work on CPU utilization, but CPU utilization, there's a bog article 02:16.720 --> 02:21.520 here that we wrote is a really bad value, like modern CPUs scale dynamically, they have 02:21.520 --> 02:27.960 two-able boosts, I don't know whatever, CPU utilization, you can't really get really 02:27.960 --> 02:29.960 good metrics out of CPU utilization. 02:29.960 --> 02:35.160 So that's something we were thinking about and we were like, okay, how are we going to do? 02:35.160 --> 02:40.280 And lucky enough the catalyst fund from the green screen coalition paid me to write code, 02:40.280 --> 02:44.840 which was awesome, and they're still paying me, they gave you more money, which is quite 02:44.840 --> 02:45.840 cool. 02:45.840 --> 02:49.680 So what do we set out to do? 02:49.680 --> 02:54.480 We want to put Linux on top, we want to be better than Windows and Mac, we want it all 02:54.480 --> 02:59.800 to be open, we want to be shared, we want it to be saved on servers, like most hardware 02:59.800 --> 03:04.400 runs in containers or somehow virtualized, and there's no real way to expose this into 03:04.400 --> 03:08.200 the containers, it was really important to expose these energy values into the containers 03:08.200 --> 03:12.080 and get them on servers, and we've talked to like multiple big server vendors and they're 03:12.080 --> 03:16.600 all interested in this, and obviously open source, it has to be accessible, it has to be flexible, 03:16.600 --> 03:21.240 we have to talk about this, we have to, all the other solutions are closed source, Windows 03:21.240 --> 03:26.040 and Mac is not documented, I think it's really vital that it's open source and we can 03:26.040 --> 03:28.040 talk about this. 03:28.040 --> 03:35.480 So we have three attack vectors, we have the L3E engine, which is like a non-linear statistical 03:35.480 --> 03:43.200 model that can calculate energy usage values, we have power metrics with like a benchmarking 03:43.200 --> 03:49.440 tool, it's a clone of power metrics for Mac, so it has the same API, it has the same output 03:49.440 --> 03:56.560 formats, so you can port programs that work under Mac, you can port them to Linux very easily, 03:56.560 --> 04:01.680 and we've got the kernel extension that exposes all the power and energy values into the 04:01.680 --> 04:03.720 Prox file system. 04:03.720 --> 04:07.720 We wrote a paper about there, so it's been peer reviewed and it will be published on 04:07.720 --> 04:13.160 the green's workshop in July, I think. 04:13.160 --> 04:19.600 So there's one, when we started this, we talked to loads of people, and everybody seems 04:19.600 --> 04:23.120 to want energy, right, and everybody's like, are giving really jewels, giving really 04:23.120 --> 04:26.120 jewels, what nobody tells you what they want to do with this value, everybody's like 04:26.120 --> 04:31.160 mini jewels, but getting energy values is really, really hard to get them precise, so we 04:31.160 --> 04:35.080 also have the green metrics tool where you can do this, we run like a specialized hardware 04:35.080 --> 04:43.080 cluster, has a specialized Linux on it to get precise energy values, so I think we can't 04:43.080 --> 04:47.200 give you energy values, but I think that's all stops the discussion, I think we should 04:47.200 --> 04:52.800 talk about an abstract value that gives you indication, so we've got the energy footprint 04:52.800 --> 04:57.400 Apple, game along and did this energy impact, which is also, it doesn't it correlates 04:57.400 --> 05:01.720 to Jewel, but it's not equal to Jewel. 05:01.720 --> 05:09.520 So there's two programs, there's PowerLetrics, which uses EDPF in the kernel to get the 05:09.520 --> 05:16.520 values, to get the values it needs, puts that in the L3, and then exposes it through the 05:16.520 --> 05:19.760 PowerLetrics user space, and then you can benchmark in start PowerLetrics, start your 05:19.760 --> 05:25.680 programs, and you'll see all the processes, everything sort of interacting with each other, 05:25.680 --> 05:29.160 and that's really great, if you're benchmarking, that's really great, if you're looking 05:29.160 --> 05:33.480 at your code, if you want like a quick idea, what's happening on your machine, but 05:33.480 --> 05:38.480 then we thought, okay, nobody's going to run a EVBF script on their servers all the time 05:38.480 --> 05:42.680 and write something around it, so then we also have the green kernel, which is the kernel 05:42.680 --> 05:48.360 module, that does basically the same what PowerLetrics does through the engine, but exposes 05:48.360 --> 05:53.400 it to the PROC file system, and like techies will know the PROC file system, every process 05:53.400 --> 05:58.040 basically has a folder structure in there, and then you can, and that's a file, and you 05:58.040 --> 06:02.920 can just open the file and get your energy metrics for that process, and then you can just 06:02.920 --> 06:08.280 use log-stash cart, whatever you want, grab whatever tool you want, to access it. 06:08.280 --> 06:14.160 So this is PowerLetrics, you can see we've got all the different values, but the important 06:14.160 --> 06:19.040 thing is, this is a classical system, this is me when I'm developing, the first 50 processes 06:19.040 --> 06:25.480 I'm node, and they're using huge amounts of energy, basically it's VS code, doing I don't 06:25.480 --> 06:32.920 know what it has to do, so, exactly, so I talked about this, so it has EVPF, it imports 06:33.000 --> 06:39.000 Ruffle, and it separates an appropriate process, level your energy usage, and it has an overhead 06:39.000 --> 06:40.640 of 0.2%. 06:40.640 --> 06:46.800 So these are overhead, but it's not statistically relevant, I want to say. 06:46.800 --> 06:51.200 You can try it, it's a Python package, you can do pip install, PowerLetrics, it does all 06:51.200 --> 06:56.480 the compilation, that's another thing for you, should be fairly simple, please give me 06:56.480 --> 07:01.480 feedback, try it, and this is the power kernel, I wanted to have this release, that falls 07:01.480 --> 07:05.240 to the input and that edge, so this is going to be released in the next week, so this 07:05.240 --> 07:10.120 is a kernel module, obviously you need root to run it, you need the assist admin to install 07:10.120 --> 07:15.040 it, but the sweet thing is, it gives you all the stuff in the prox faster, and because 07:15.040 --> 07:19.280 it's in prox, it will also give it to you in containers, right, so if you have, if you're 07:19.280 --> 07:23.680 like a classical cloud vendor, you install this kernel level, and all the containers, all 07:23.680 --> 07:27.240 the virtual machines, you can just funnel it through, so each container will know how much 07:27.240 --> 07:32.040 energy it's using on the host system, and there are no security concerns, if you use 07:32.040 --> 07:35.920 wrap all something, you can do side channel attacks and everything, but through this because 07:35.920 --> 07:40.760 the update interval, we recommend to set it to five seconds, there's no way you can 07:40.760 --> 07:45.840 expose any secrets or something, but like this, you can just add it to your log start or 07:45.840 --> 07:52.240 whatever, every Docker container knows how much energy it's using on the host machine. 07:52.240 --> 08:00.960 Exactly, everything is on GitHub, please contribute, look at it, the E3 engine, the 08:00.960 --> 08:05.560 L3 engine is easily replaceable, you can tune it, because obviously every hardware is different, 08:05.560 --> 08:12.040 so we're looking at, for example, you need different weightings, you need different parameters, 08:12.040 --> 08:16.160 what's an all major destroys, and we're trying to make it easy to use, so a lot of 08:16.160 --> 08:19.980 problem we're seeing with all these like really specialized tools, also with our grim matrix 08:19.980 --> 08:23.900 tool, is it has a very steep learning curve, and people don't want that, people want 08:23.900 --> 08:26.260 to just see a value, right? 08:26.260 --> 08:31.380 Exactly, thank you again to the catalyst fund for funding this, it's been awesome to 08:31.380 --> 08:36.660 just get money and work on this for a month or two, here are all the links, and if you've 08:36.660 --> 08:39.140 got questions, drop me in, you know, thank you. 08:39.140 --> 08:56.620 So I was thinking, I quite have quite short of processes, can you aggregate how are you 08:56.620 --> 09:04.740 to do your own time by control groups, yes, you could, yeah, I haven't done it, but technically 09:04.820 --> 09:07.020 there's nothing against it. 09:07.020 --> 09:15.860 Yes, if you measure the whole variety to those by measurement tool, because I guess 09:15.860 --> 09:22.540 that it gets the use of energy to collect all the data, it can be variable according to the 09:22.540 --> 09:30.020 quantity of processes that they're missed, so if you, so, yes, we, we, we have benchmarks 09:30.020 --> 09:37.100 of you that, and the 0.2 is max sort of a benchmark with a thousand process, I think, 09:37.100 --> 09:41.460 so, but obviously it scales with processes, because we have to look at the data of all 09:41.460 --> 09:45.500 the processes, but luckily the way the kernel works in the VPF, the data structures are 09:45.500 --> 09:51.340 quite optimized, so we don't have to do, so the initial load of the process is, let's 09:51.340 --> 09:55.100 say, expensive, right, because we have to do all the resolution and everything, but then 09:55.100 --> 09:59.140 luckily the kernel gives us a very good data structure that we can query quite in effect 09:59.140 --> 10:04.580 of, but yeah, obviously, if you've got a massive server with 10,000 processes on it, 10:04.580 --> 10:10.700 you're going to have a higher overhead than the small embedded device, yep, thank you.