Hi folks, we'll give it just another minute or so as people log in. But welcome, so please stand by. Okay, we're going to go ahead and kick things off. Welcome to today's episode of the latest LF networking webinar. Today we're going to be speaking with some folks from the phyto community. And the topic is Calico VPP Kubernetes networking with boosters. Before we go into introductions of our speakers, just a couple of housekeeping items. Attendees will be muted during the presentation. However, if you'd like to ask a question, there is a little Q&A window towards the bottom right of your screen. Feel free to click on that and type in questions at any time during the presentation. Our speakers may be answering some of those via type type to response in that Q&A window, but we are holding some time at the end for open questions. So just know that if we don't get to your question during the presentation, we will do our best to address it towards the end. Additionally, a recording of this webinar will be available in the next few days. Anyone who registered for the session will automatically get an email with a link to the recording so you can go back and rewatch it. It'll also be available on YouTube and you can access it from the LF networking website. So without further ado, our speakers today are Chris Topkins and Nathan Scribzak. So I'm going to hand it over to Nathan to do a quick intro of himself and then he'll hand it over to Chris. Thanks Jill. So nice to meet you. I'm Nathan. I'm a software engineer at Cisco working in the FD.io project. I'm a contributor on the Calico VPP integration and on a personal side, I'm a biking and hiking enthusiast here, as you can see in the photo. And a personal note, I have a French accent, at least I assume despite the name. And I'll hand it over to Chris. Yeah, hi there. My name's Chris Tomkins. I'm a developer advocate at Tigera. I was formerly a Calico user at the company I worked for before Tigera really enjoyed working with the product. So so I joined the team. I tried to update this slide to make it interesting for people who seem all the wants. So today's obsession I bought a globe and I'm very excited about it. I'm also never without music. So I'm listening to Van call the friendly fires at the moment. I'm always looking from a technical point of view to learn and share. So you'll see at the end how to get in touch with us but I love to challenge my knowledge and learn more. So let's connect. So I'm taking lead on the first part of this just to talk a little bit about what Calico is before we move into VPP specifically. Project Calico is a network open source networking and network security solution for containers, virtual machines and host based workloads. It is developed and maintained by the project Calico community. A great way to implement best practice kubernetes security across public and private cloud across many kinds of environments, and it offers exceptional performance proven real world scalability and interoperability. It's been running on production clusters for many years so it's you know reliable production hydrogen setup and it has full support for kubernetes network policy. It has an active in contributor community and you might have noticed I left the top left one until last. The reason for that is because it's related to what we'll talk mostly about today about data plane support. So, Project Calico has three data planes today in, in production, production ready data planes which are the epf data plane the standard Linux and the windows data plane. But today we're going to talk about a fourth which is intact preview which is VPP. But before we do. I wanted to just talk about a few software concepts that are important to understand which will help the context of the conversation. The first is modularity. So on the right, we've got a diagram that most network engineers will be familiar with which is the SI model. And you can see that it looks something like a brick wall and the reason it looks that way is because when we build software. We build in modular blocks using a concept known as modularity. It allows us to keep the abstraction of each of the functionality of each block separate to those above and below it and that makes the software easier to maintain and has other benefits. So sometimes this works very well. So if we look at the OSI model layer one at the bottom of the physical layer is a huge success in terms of being modular in relation to the others. By that I mean that we don't really think very much about what the physical transport medium of our internet connectivity is, you know, you can use fiber or copper or even the air for wifi. We just don't have to think about it and it has no bearing on the higher layers. So it's a success in the sense that layer one is isolated and entirely modular from from all the other layers. Failure where the concept applied but it wasn't implemented quite so well is layer three. So, again, network engineers will probably know that layer three is where IPv4 is implemented or IP is implemented. And you'll know the story of how we are still struggling to move away from IPv4. And that's happening, because we need to move away from IPv4 due to address exhaustion, but it's becoming incredibly hard to do so and that's because layer three is tightly coupled to the blocks above and below it so it's not as modular as it should have been. So I would say that layer three has overlap with layer two in the sense of broadcast behavior, it has overlap with layer seven in terms of browser behavior, it has overlap with layer seven again in terms of name resolution. So basically, layer three is not as modular as it should be. So this concept is important modularity. And the next important concept is software coupling. There are two bits of example software here. One is a pizza store system, and you can see that between the two parts of the pizza pizza store software, you can see that there's a strictly defined software interface. You can think of it as two departments in business that have to talk to each other through that interface, and by having that strictly defined interface. It makes it very easy for us to fix troubleshoot and replace any block of software without affecting those around it. So that's called loose coupling. And on the right we have tight cut them, which is where the two parts of the software stack are basically merged into one, and it's very hard to edit one part of that software without having undesirable effects on the others. Now so I've gone through those quite quickly because we have more interesting things to talk about but modularity and coupling are both key software concepts. Now in network devices, what we're seeing in the diagram here on the right hand side. Is a single network node that network nodes could represent a switch a router a virtual machine hypervisor a container host, but at the end of the day it's a network node. Network nodes tend to have an architecture of a control plane and a data plane. So this is a modular software with a defined loosely coupled interface between the modules. Well, the job of the control plane is to wash will go into that a little more in a moment but it's to get an overview of the network. And the red arrows represent the actual user traffic by which we talk about emails or cat videos on YouTube content or whatever is passed between the data plane. The control plane doesn't have any direct visibility of the actual network traffic. Instead it exchanges network state, and that's represented by the green arrows. So if we elaborate a little bit more on the role of the control plane inside the network node, the control plane is responsible for figuring out a high level complex consensus of the network. So that might mean for example the consensus of sophisticated routing protocols like BGP or SPF for ISIS. It is necessarily complex software. There's a lot going on. And so as a result, it's typically implemented on a general purpose CPU because a general purpose CPU is needed to to be able to carry out that that kind of complex software functionality. So the CPU in fact is something a lot dissimilar to what's in what's in your alone laptop. The data plane in contrast is responsible for processing the actual transit traffic that moves through the node. As a result, it has to forward an awful lot of traffic, very fast. And if possible it should use whatever the hardware acceleration features are of the node. On whether this is an expensive switch, it might be a hardware ASIC, or it might be kernel functionality or other software functionality or acceleration in the NIC. The data plane's job, since it's designed for just forwarding traffic, its job is to be the simplest possible implementation of the required packet forwarding features. So maybe you have a requirement for cryptography in your data plane. Well, then that's a required feature. So it needs to have the simplest possible limitation. But it could be that your data plane requirement is very, very simple. There's a really good example of this which if I have more time I'd go into more detail but MPLS is a great example of this in the sense that IP forwarding has a certain amount of necessary complexity. There's a certain amount of variable length submit masks and so on, but MPLS which is hugely successful in service provider networks. Sidesteps a lot of that functionality and reduces the necessary feature set down to a very, very simple minimal feature set. And as a result MPLS was hugely successful. So this is a good example of how data planes can be designed for different roles. There's no one right solution. Calico was designed with a four tier modular wall from day one. I was really excited when I joined the team to realize that this this thinking had been there since day one, and those four tiers were the data model, the Felix calculation graph, the data plane driver and the data plane. So I think of the top to the data model and the Felix calculation graph as being analogous to the control plane of the node and the data plane and the data plane driver as being analogous to the to the data plane. Now, each of those is loosely coupled to the ones above and below it. They are very modularized now we'll talk in a minute about why, why that benefits us and then you can probably see where I'm going with this but VPP is one of the different options that we support and we're able to support any data plane that appears that offers, you know, great features like VPP does. So, in the case of Calico's data plane depends upon what what do those four components actually do. Well the data model defines the actual custom resources used to enable Calico. So it's the data structures that allow Calico to do the work that it needs to do. So it lives up in the control plane. The Felix calculation graph makes the smart decisions that of what needs to be programmed that need to be programmed into the data plane so we said the data plane offers a certain set of functionality. Well the Felix calculation graph does the complex. Calculations and then programs the data plane to make those forwarding decisions. It does that for a data plane driver which is a simple and minimal driver for programming the data plane so it's like an abstraction layer between the Felix calculation graph and the data plane itself. And the data plane which is responsible for actually forwarding the packets. So we'll look at the diagram first of all. This diagram says data path but you could use it as data plane just the same. In a way this this diagram is great because the Calico cat logo actually sits in the scenario of the control plane. It sits above the various data plane options, but you don't have all three implemented in a single node at a single time you would only have one. The Felix IP tables is our original data plane which is performance and very very well battle tested. The windows house networking service is our different sports windows and Linux ebf data plane is an alternative data plane for Linux that has extra requirements around the kernel version, but also offers better performance than RIP tables Then there's the fourth option which is VPP, which is not yet shown in in this diagram because it's intact preview. But we'll, we'll go into what VPP can offer us in a sec. So, why do we even have a pluggable data plane well it allows us to reuse the control plane code. So, all that complicated sophisticated code that was written for the control plane doesn't need to be torn out and replaced. No matter what data plane. It also allows us to keep the data plane code specialized and minimal so it's easy to audit easy to test and lightweight, and it allows us to target a particular feature set, and it allows us to future proof. So we're able to switch orientation and support particular data planes that our customers would like us to. It makes both us and our customers agile. So, I've already spoiled this slide a bit. I should have remembered it was there but broadly we offer those four data plane choices. So we're pretty much on time so with that background knowledge, thinking about modularity, coupling and data planes and the advantages of supporting multiple data planes. Let's hear Nathan can tell us a lot more about VPP the specific data plane choice. Thanks Chris. I'll try to switch to sharing. I think you need to stop. Yes, I think I need to stop. That should be sharing. Yes, we see it. Okay. Thanks. Thanks Chris. So, now let's take a look at how we can leverage the Calico architecture that Chris described to insert VPP as a data plane for Kubernetes networking. So first, a few words about VPP. It has been presented many times in many presentations. So I won't spend too much time on it here. But in short, it's a user space network data plane, which is highly optimized both for packet processing and at the API level as well. It is also easily extensible through plugins, which is something we use a lot for the Calico integration. If you'd like to learn more about it, there are plenty of presentation and resources available so feel free to go there. Now for the Calico VPP integration, what we do is we use this module that Chris described and we add VPP as a data plane under Calico. So when you deploy Calico VPP on a Kubernetes cluster, you will get one VPP instance on each node that processes the container traffic. It does the routing, of course, but it also implements the Kubernetes specific data plan features such as policies, the service load balancing and also potentially going traffic source netting, IPIP, VXLAN, the tunnels, the IP sector and so on. So all this logic is done in dedicated plugin that are optimized for this use case. So we wanted to make it as easy as possible for users to configure just a switch to flip. So you only need to pass an interface name that VPP will use at its uplink and a driver for consuming it. Actually, you can even leave the driver and VPP will try to find the best driver for the environment. We also configure VPP in a friendly way for container environment. For instance, we use interrupt mode instead of pull mode so that we don't waste CPU cycle busy looping for packets. In many cases, we support running without huge pages as well to limit the number of provisioning step on the servers that that might depend on the driver. But now you might think why do all this? What are the issues that require such performance or specific features that the regular Linux kernel can provide? So we'll describe a few of the ones we are aiming at solving the main three. The first one is internal decryption. So if you want to enable encryption from every node to the other. Second is exposing highly available services in a in an easier fashion. And the third one would be network intensive application like VPN or proxy is being deployed in an instance. So for the first risk is internal decryption. The thing is encrypting traffic is usually required at some level for compliance and security reason. For example, if you want to talk to compliance or PCI DSS. You will require it some sort. And having the infrastructure provide this encryption has really nice properties because it guarantees that regardless of application evolutions. And also maintenance gets easier because if patches have to be applied or security parameters have to be bumped. You only have to do it in one place and you can separate the concerns between the encryption infrastructure and the application. The main issue with that comes from performance as the default Linux implementation usually makes it quite impractical to use in production as it reduces to the for put enough that you it does not really make sense to enable it. But with Calico EP as we expose optimized implementations. We allow this to work at line right and and with a manageable CPU usage. So that enables us to use it in production. And then we also expose both IP sec and we got to address the different requirements application might have. The second use cage is, we target is HA for services. So Kubernetes aims at providing highly available services that are robust to pod or not failure. But this usually gets quite complex in practice because Kubernetes will often drop all connections going through a node when when the node dies, even if the target pod still lives. And there is no guarantee that the node will load balance the same way when it restarts because all you have to synchronize state in a in another way. In Calico VP as we have our custom implementation for the humanities services, we can we chose to expose a maglev enabled load balancer, which allows us to keep connections, even when the load balancing node dies. They are only lost when the handler for this last. And we're starting node with a load balance deterministically without having to share state and services can then be exposed by routing external IPs or service IP directly to the nodes. But doesn't require to fully change for ingress and it allows even allows for a simpler topology. So you just have to be cmp between the nodes to to have it to have it work to have your ingress working. Finally, for the network intensive use case like the VPN proxies CDN or storage. The network stack usually becomes quite quickly a bottleneck as the traditional offloads we have like GSO GRO so packet coalescing cannot be leveraged. So application developers can use SRV to to get around the performance limitations. But then they have to do the addressing scheduling on their own so they don't get the benefits on communities. What we try to do on that use case is offering an high performance alternative so still high performance alternative to the Linux kernel without breaking the benefits that communities brings. So we do this in two ways, either providing your memory memory enable the interfaces members that are exposed by the two pods to to speed up a packet transfer. And we also try to want to expose if it's a stack that that provide the alpha or plus so layer for implantations of protocols, the CPU Dp TLS and quick to applications. And when we put all these use cases together it starts to look like this. It gives the following architecture. So here we have three nodes each running BPP. The ingress of balancing is done in two layer one ECMP in blue and one maglev in green. And there is an accretion layer between the nodes, but showing you this this graph is the graph gets a bit cumbersome so I'll dive quickly into the detail to explain a bit more about it. So let's let's first dive into the VPP logic. So the way it works is we provide an extension to the regular Calico YAML declaration. So the regular Calico agent feel like still runs as a demand set on each node as Chris stated the we keep the same code we keep the same mechanism. In addition to that, we add a VPP demand set so one VPP instance running on each in a pod on each community is not living on alongside. And this is VPP registers itself in the Calico control plane, so that the control plan will program it instead of the Linux or the Windows or EPP Firm. We start VPP with a low footprint configuration by default, no DPDK know which page is an interrupt mode to be as lightweight as possible. And then the VPP plugin implementing the Kubernetes logic do the magic and do the actual networking. So now because VPP is a user space stack, there are several things that will be different between VPP and the data planes. As we can see here on the topology VPP inserts itself between the host network it's in red in the figure. So on startup, it will grab one of the host network interface the one that's specified in the configuration and consume it with the appropriate upland driver. It then restores the host connectivity by creating a tune interface in the host root network namespace that will and then replicates the original upland configuration on that interface. So it restores addresses routes so that things behave similarly to from the Austin point. That's that that's really useful. For example, on environments where you only have one interface and your SSH in through that interface on the machine and you still would like to keep your SSH session after VPP has started. The pods are connected just like the hosts with a tune interface in each of the pods namespace. And the Calico Contra plays running normally on the host and it configures the data function. Once we are using tune interfaces and not VIF. We also don't need to worry about the layer two in the pods, which is a better match for the humanities networking model and we also gain a few bytes by not having the help to add there. Taking a closer look at the packet flow on Calico VPP node, the way application will consume this. The application that runs in the pod uses the regular socket API to send and receive traffic. And the kernel transfer stack then generates the corresponding packets and send them to VPP through the tune interface. And then afterwards VPP forwards these packets to the rest of the network. So the main advantage of this setup is that from the applications and points it's completely unchanged. The pod is also still provided by the kernel, which limits the security constraints we put on VPP. So the way West is really similar to regular Calico. From a higher standpoint, the logical architecture will look like this on a node where you deploy your Calico VPP. So there are two pods on each node. One is running the regular Calico agents. Here are the blue components if you exclude the Kubernetes API. And one running the VPP pod here in white. The second part consists of two containers, one for the control plane and one for the data plane. So we kept them separated because this allows separating the concerns. It keeps the VPP life cycle separating from the agents and that reduces the risk of control plane events impacting the global connectivity. And also you can upgrade both independently if usually data plane upgrades are not that correlated to agent bumps. The state of this project is currently a Calico tech preview and it lives in the Calico GitHub organization. We now support most of Calico features, so most of what the control plane is able to tell us. And we're looking to get feature parity in the near future, hopefully getting generally available sometime soon. So it's an open source project. If you want to contribute, you can find us on GitHub under Project Calico. In the short term to list a few of the upcoming features, we are focusing on the cloud deployments, providing support for operators and public clouds. Actually, operators should be close to being released, easing even more the deployment process and supporting even more public clouds to really allow testing to be quite easy. We're also aiming at adding package interfaces, the Mami file I spoke about earlier, and VPPO stack support should come right after. In the long term, we are aiming at leveraging those integrations, those features in complementary solutions, like Envoy or NSM network service mesh to allow to address even more specific use cases and speed up those specific use cases with the optimizations we provide. So this should give an overview of the architecture of the project, the way it works, and I hope it makes the overview picture I have shown earlier a bit clearer. So now what I propose is diving into the use case we mentioned earlier, so encryption, highly available services, and packet intensive applications. And seeing the way they integrate with this, how we can leverage them in applications, and what are really the performance improvement they allow in terms of them. So I'm going back to internal encryption. So we, as I said earlier, we expose a couple of options, we have support for Wayagard, which is cross compatible with Calico Linux and Calico EVPF, so you could imagine having hybrid clusters talking to each other with Wayagard. We also support IPsec, which is the standard encryption algorithm, and that's also benefited from the most optimization IPP yet because it was developed a bit earlier. IPsec even comes with an asynchronous mode, which allows to distribute the crypto operations of a single tunnel to all the CPUs or a subset of those CPUs that are assigned to IPP. And this allows to reach a much higher throughput than when doing this operation synchronously on the worker, the tunnel, the IPsec tunnel was pinned on to, because RSS pins us on a single worker, spreading the operation really allows to spin things up. So we did some benchmarks to showcase the performance that this can give on a bare metal cluster. The test we did, I'm going to show is, it consists of a simple IPer throughput benchmark between two nodes, with traffic being tunneled with different encryption modes, different ways of doing the encryption. So when using Wayagard, which is available, which is the one being available on the free implementations, the Linux, CPPF and VPP, we didn't test Windows yet, but maybe at some point we will. So the kernel implementation reaches 2.6 gigabits on one tunnel, both for Linux and VPP, and VPP goes a bit faster at 5 gigabits. Actually, performance should be a bit better with VPP as we really recently integrated a crypto backend optimization for Chacha 20, which is the crypto part of Wayagard. And that gives around 30% on specifically the encryption part, so it should be better. We'll update the results afterwards. On IPsec on the other side, it gives better figure, but this would here only with VPP. We're reaching 9.5 gigabits in synchronous mode, and asynchronous will be 14.4 on a single tunnel, which is leveraging multiple calls. We also measure the global CPU consumption on both nodes during the test, and VPP doesn't consume significantly more CPU to reach that throughput. So this really makes enabling encryption across nodes possible in, let's say, production environment, and still keeping an acceptable throughput. The second use case we are considering is highly available services. So here we took a Kubernetes cluster with three nodes, each running some containers. So in the figure, there are two services with the, with VLC and EngineX running. And let's say we expose those through service IP that we want to have available outside. So doing ingress and exposing services with regular Kubernetes is a bit hard because doing traditional ECMP between nodes usually kills all the connections on the node failure or when adding deleting nodes. If we use a dedicated ingress load balancer, it can create a single point of failure or only some sort of state sharing. So as we have the load balancing code living in the user space plug-in, it allows us to do a bit of magic, and in this case, leverage the maglev load balancing algorithm to ease that. Just a quick recap, if you're not familiar with maglev, it's a stateless load balancing algorithm with some nice properties. It comes from paper that was made by people at Google. And it's, the algorithm is deterministic in that the same flow will always be balanced to the same backend if the state of backend doesn't change. And if we add or delete backends, there is some consistency guarantees that most flow will still be balanced to the same backends. So minimizing the last or rich or full connections when, when events, when rebalancing events happen. So if this work is as follows, we generate a list of buckets in the middle. So usually we take a big prime number and generate a list. And we make the backend successfully choose buckets by order of preferences. So they, they say, oh, I prefer that bucket. And with a round robin, they choose the different buckets. And incoming flows are then consistently asked to a bucket and the bucket leads to the back end that shows it. The, the nice properties with that is that if we add a back end here, back end screen read as back end one and two will still have the same preferred buckets, the number of flow that change back ends will stay low because back ends will mostly get their preferred buckets. And, and so flows mostly won't change on change locations here are actually I didn't draw any flow that change but as I did draw drawing I choose the best possible scenario so but, but it's the general idea. So moving back to what this give for Kubernetes cluster leverage leveraging model GLEV. This allows us to, to directly use ECMP for incoming flows. So we can have a stateless load balancing layer in front of the nodes that will change when the node changes. And when we take an incoming request to a service site going to a service IP. So here we should give a node provided by ECMP here we take the node A. It will enter the PPP the way we saw earlier and my level load balance it to a pod so maybe on the same node maybe on another here it's node C. In the event node disappear. So here node A is gone. It will remove itself from ECMP pool. So we're changing the load balancing decision for the flows. So our flow from the past figure will then reach a different node. But with the consistency properties of Maglev the load balancing decision will be the same. So the flow will still reach the node C. So for the pod serving the connection things will be transparent which won't be the case with traditional load balancing. One of the things I hate a bit in this. So first the set of back end changes as node A was running a pod with an NGNX logo. But this shouldn't affect Maglev as back end changes are mostly consistent. And also here it's a reduction of the number of back ends. So actually their buckets will be spread a bit more but existing flow won't be reshuffled. Second for the return traffic we have to enable direct service return DSR. Because if we do the unnatting in the Maglev so if the return traffic follows the same path that means we have to store state and that we will lose the state upon node deletion. So we have to use that but that's something we also implemented in Calico EVP. And finally the fact that Maglev is stateless also has nice properties in the event of data plan restart. So this can happen if you want to upgrade your CNI or if PPP crashes but we know this never happens for software so that won't happen. But in this case you don't have to restore per flow state. So the load balancing decision will also stay consistent. And the flow will still be low balance to the same direction. And finally the last thing about this is that as this is only an implementation detail because Kubernetes does not say anything about the algorithm being used. This would work in combination with non Maglev nodes provided that you don't ECMP to them. And finally for the last two scales, we wanted to focus on our package oriented applications. So here we have the schematic showing the standard way of consuming packets in container. And finally the nice properties of being transparent to the application. As we stated earlier for endpoint application this can prove performance enough but with kernel optimizations such as GSO and GERO. But when you start processing small packets you might find yourself limited by the network stack. And same thing with compute intensive L4 like TLS or quick crypto or even TCP kernel might be a bottleneck. Another way to address this is to change the way you consume the interface within the container. You can attach the application to the container with AF packet, packet a map or AF XDP. That brings up a bit of performance gains but it's still marginal in terms of terms when building packet oriented applications. As a side note it's AF packet and AF XDP inside the pod not for connecting VVP to the uplink. Both are possible but sure it's inside the application. What we enable with a Kaliq RUP or want to enable because it's still work in progress is requesting an additional packet oriented interface in the container. With simple annotation and for example the destination port and protocol you want to receive on it. And the application can then consume this memory interface, this MAMIF directly in the pod either by running another VPP inside the pod or by leveraging DPDK or libMAMIF directly from the application. So this enables full user space networking so packets will never touch the kernel on the path from the application to VPP. And continuous can even leverage zero copy on the way from VPP to the application. Not the other way around because otherwise we would have to expose VPP memory to the application which is not ideal from a security standpoint. The drawback being that the application now has to be aware from libMAMIF and knowing how to connect to it. Same thing can apply to well for protocol, we expose or want to expose the same mechanism. So VPP has support for TCP, UDP, TRS, DTLS and QWIC. And that's through the host stack. So you just need the same way to with an annotation, tourist quest support in the pod. That will expose a socket like API in the pod that you can consume leveraging the VCR which is a library that you can, a socket like library that you can use in the application. So this enables the same way full user space networking in Kubernetes, so no going through the kernel. Optionally zero copy depending on your implementation. And that way you can leverage VPP's optimized crypto or optimized TCP. But again with the drawback that you have to make your application VCR aware. So that's a bit of the middle ground between getting better performance that you can get with the interface. But the application should know that it runs with optimized interfaces. To recap a bit the different ways of consuming traffic from within the container. In a Calico VPP-enabled canister, I summed here up the pros and cons. So for endpoint application, we don't have really definitive figures yet as this is still work in progress, but the performance gains are still quite substantial. Even though when it comes about crypto, there are a lot of numbers in CISIT, but that are not really Calico VPP numbers yet. I should thank Florin for the work on those optimizations. And concerning packet oriented interfaces. So the MIMIF, the Orgner of magnitude of PPS that you can expect is around 10 millions per core per queue. But again, this is what we're working on on improving it. So we will need to do a bit more testing and optimization to go there. But that's the thing we want to expose. And both have the same drawback of having to do some updates to the application, but I think that's the counterpart of exposing higher performance. At some point, the offload has to be shared by the application. The knowledge of the offload has to be shared by the application. So that's it for this presentation. We have a number of new exciting features on the horizon, including the mag level balancing, the packet oriented interfaces and hopefully soon general availability in Calico. I hope we were going to achieve that soon. So if you'd like to stay up to date on the project, don't hesitate to join the VPP channel on the Calico Slack. The link is there. We publish our release there and then follow the Calico releases. If you'd like to try it out, you can head over to the Calico documentation, which has the setup instructions. And if you have any questions at any point, don't hesitate to ping us on the Slack channel as well. We will try to answer, but you can ask the question right away. Yeah, thanks a lot. Nathan. Yeah. That was great. Thank you. I've answered a couple of questions that were that I knew the answer to, but we have several more in the Q&A. If you have a look with me. Okay. I went straight ahead on the presentation. So I didn't. Oh, that's okay. I picked out a couple anyway, but we have plenty of time now to run over them. Let me find my Q&A. I can read some out to you if that's easier. So the first question that came in is regarding fast API support, 200K updates per second, which VPP data structure is updated at that rate? Is it classifier node? So from what I understood, so if I understand the question correctly, it's how fast VPP can update its data structure. So the way it works, VPP is connected to the agent via a binary API. On some APIs, it can go quite fast up to, I think, way more to 200K per second. I think a million if I recall correctly, but as we leverage different, so many API calls that might get reduced in the case of fast humanities updates. We did actually do a bit of testing on the scaling part of when you want to create a lot of services. And from the testing, the main bottleneck was the SCD slash the Kubernetes logic being able to forward us the updates. So VPP is not the bottleneck yet, but we were definitely looking at optimizing this. And then we upgrade, we update internal structures, data structures that are internal to VPP. So for that, the data plan will use them. Great, thank you. Next question, is it possible to use this as secondary CNI via multis? It is. It is definitely, we haven't tried it. It might lead to some quirks and some tricks to make it work properly because of the way we do swap the interface. We sort of steal the interface from Linux and replace it with a fake one. So depending on the configuration that you have and who is the chicken, who is the egg, you might get into weird situations. But if you have different plain interfaces, I think that won't be any problem. There are definitely ways to make it work. I think that's one way we'd really be interested in you joining us on Slack as well. If you decide to try to do that and share your experiences and it may be that that we can help to unblock you. Yeah, definitely. Also would be really interested in knowing the blockers if there are any on the thing we can do to improve that. Another question, whether VPP batch processing model has an impact on latency? Any benchmarking done with service networking? So batch processing, it has an impact, but it's very, very small. There is a guy in your team who did some measurement with that, but on regular nodes, it's really under the microsecond level. So from more testing, it's barely noticeable. So the fast pass, slow pass going through the NAT and the service logic will be in order of magnitude slower than the batching. So to explain a bit, VPP has this concept of doing vectors of packets, if I understand correctly, the question and processing them all at once. So the first packet of the batch will be processed a bit slower than the last, but that's usually really fast. And the other part of the question was about service networking. They don't use our later moves to answer. We didn't do. I actually, I actually marked it as answered. I think you'll find it in the answer section. I think you, I feel like you answered it really. I think the only, the extra part was, was, have we, have we specifically benchmarked the service networking? So the service IPs. So if by service networking, it's the NAT thing, we did a couple of benchmark on that one. If throughput it does not impact and on PPS, it starts to be a bit of bottleneck at some point. But we are trying to improve that. It plays a role in the, in reducing the 10 million packets per second on the net. So, but they are ongoing improvements. So on most benchmarking, we do an effort on benchmarking, but we also do an effort in improving the benchmark at the same time. Next question, would it be possible to run a VPP based NFB application in a pod with Calico's VPP data plane? In other words, VPP on top of VPP. Definitely that would work. So that, that, that doesn't work in the latest release because we, we still have to add to publish to the support for that. But so, I mean, that, that would definitely work attaching VPP to a tap that would work better with added support for my mute that we are going to going to release. But yeah, there is definitely not nothing that prevents this from running. Maybe so this might bring some concerns on the addressing model and because NFVs are not. And Kubernetes is really made for dealing with endpoint applications in the industry. So this might bring some questions and some things might be done better. So if, if the, the, the person who asked this question, he wants to, to join in and discuss with us will be really interested to find the best way to answer the things that might not be ideally answered by Kubernetes. But, but from a technical standpoint, yes. Okay, just a couple more questions. How does a packet processing workload interact with Calico BGP control plane? Surely it needs to advertise a subnet rather than a host route. So, yeah, that, that starts diving into the how to do addressing and with four packet processing applications. We don't have yet a strong opinion on how to do this. Considering the Calico BGP, we don't, we didn't do any changes to it, which we just integrated it as, as it works with Linux. So we could build something specific there that's dedicated to, to a networking application, but the way we've thought about it for, for, let's say, start up, start up packets processing applications would be to use end caps and to sort of bypass the Kubernetes at first. So you could, you could think about Kubernetes being just the scheduling, starting pods and giving them memory interfaces with addresses. And then on top of that, you could end cap state packet and build your own, your own network. But you could also integrate with the BGP and but that would require a bit more specifications. So it's still something we are thinking about. So happy to discuss also. Okay. And I think we might just have one more question here. Does Calico make use of G go VPP bindings for interacting with VPP. It does. It does. It does use go VPP under the hood. So yeah, we, we use, we use this and we have built a small, small interaction layer between go VPP and our integration to ease the updates when the API change and we play with specific features. But under the hood is that yes. Okay. Well, I think that covers all of our questions. So unless there's anything else I think we can wrap just a couple minutes early. Thank you everyone for joining. Thank you to our presenters and we will see you on another episode of the LF networking webinar series. Thank you very much. Thank you very much for everybody who joined in the lesson. Thanks a lot for LF hand to you. All right, bye bye. Bye.


I am Dr. Teller and every day I take a little scuba dive into the delirium aquarium of the public hospital that I work at in Johannesburg. In my fourth year of medical school I was tasked with taking blood from a patient who had a heart attack or something similar and I managed to poke and prod the guy so much that I fainted next to his bedside and came to kind of dangling from his bed and when I really came to I was in the casualty bay being resuscitated by my own colleagues. At that stage my colleague asked if I wouldn't perhaps consider another career which looking back perhaps I should have. South Africans medical program is structured in six years.  You go through to fourth year where you start interacting with patients and are unleashed unto them and by sixth year you're a slightly bigger fish in a slightly smaller pond.  Mercedes wants to sell you a car. Banks want to give you a bank loan. The future looks very bright and you are now the dogotellers of the country so to speak. Dogotellers Zulu for doctor. No one tells you at that stage though how lonely it can be standing in an eight hour surgery for example. How much blood is actually involved in doing medicine and how harsh it can be hammering away at people's bones drilling into their heads. It's very gruesome and certainly very visceral on a day-to-day basis. You soon realize as a medical doctor that you don't really need to be that smart nor do you need to be that patient or kind but you certainly need to have endurance, stamina, no affinity to sleep whatsoever, a mildly neurotic personality and probably some narcissistic or sadomasochistic tendencies within you. That is most certainly evidenced in your first 36 hour call if not before then where you are likely to be spat on, coughed on, passed on, bled on and I started wearing Wellington boots to my calls after the first one where my socks were soaked with who knows what. You are faced as I've said with very visceral scenarios and an example here is this baby who was suffering from hydrocephalus who four hours after I took this photo actually died not because I didn't resuscitate him but because there was no oxygen cylinder available in the hospital for me to do so. This gentleman had had pins put into his leg about eight months before I took the picture and I removed the pins along with about five maggots and that's what you can see just next to the pin in the photograph. When you go to get some nice reprieve from the chaos of the hospital what greets you is certainly not the nice grey anatomy well-lit room with a hunky doctor on the top bunk but this rather dishevelled room with unwashed sheets in it and then you're called to see a baby who's four months old with multi-drug resistant TB who has to spend six months in an isolation cubicle. The scope of things that we see as young doctors in this country or doctors in general is very very heart wrenching. Fetuses abandoned in casualty with no one to claim them, removing butternuts from men's bottoms as they fell on them and all range of things that are both comical and also incredibly devastating. As dog a teller so to speak in the country so one asks how do you cope? How do you get through every day trying to be patient trying to be the kind doctor that everyone expects you to be? I had an idea one day as I took blood from a patient with leukemia for the umpteenth time and he told me the next day was his 18th birthday and he'd be spending it in hospital so I baked him a cupcake and I baked cupcakes for the whole ward including the staff and the nurses and for that day everything was just that little bit better. I started letting patients use my cell phone to call friends and family when because they were distressed. I let kids play with my stethoscope. I wore brightly colored scrubs to work. I tried to make every interaction just a little bit better and not to face patients with impatience so to speak that comes with being so overworked and understaffed and underresourced. I developed what I'd like to call my felicity suit. Felicity meaning a state of happiness and it's really a coat of armor that is love, joy and happiness that I try to wear every day to keep up this positive energy that I that I try to to maintain within the hospital. Some of the qualities of my felicity suit are certainly durable fibers to face that constant barrage of pain and despair that I encounter in the hospitals. A blubber like emotional coating certainly helps and it needs to be body fluid splash proof included as well as some blissful ignorance which isn't what you'd expect from your doctor but it's certainly necessary and a determination for happiness. A more practical quality is non-sweet underarm patches after your 36th hour in the same outfit. My felicity suit is perhaps not what one needs. You need more of a coat of armor facing South African casualty situations but it's something I found that has improved my quality of life and perhaps those individuals who I've interacted with day in and day out and at 2am in the morning. Design is not perfect but I'm working on it. Thank you.


Six things narcissists do when you go no contact. There are certain things that narcissists will do when you go no contact. But it's still something that I recommend. They will make it difficult for you, but it is the right thing for you to do. Because otherwise they will take over your life.  Because they came into your life to rob you of everything you have. They came into your life only to take from you. To be you, while devaluing you and putting you down. Which is why you have to go no contact.  But when you do this, there are certain things that the narcissists will do. They will go back to the love bombing phase. When the narcissists first targeted you, they love bombed you. Because that's what pulls you in. That's what secures you. So they go back to that again. Because they're assuming that it's going to keep you around. Since that's what got you with them in the first place. So they will try to rekindle the relationship. They will try to make you have feelings that you had in the past. They will try to charm you again. They will do whatever worked for them before. They will hoove you. They will call you on the phone. They will message you on social media and then they will try to pull you back in.  If the love bombing doesn't work, they will become very obsessive. The messages and phone calls will become more persistent. And they will become more pervasive. They will show up at your work. They will show up at your home. They will be talking to your family and friends behind your back. But somehow you will hear about it. And it will feel like you just can't get away from them. As though they have imaged themselves in every part of your life. Three, they will start a smear campaign. They will talk about you to other people. They will smear your name. They will assassinate your character. They will say horrible things about you. They will make false accusations. They will spread rumors. They will discredit you. Because they want to prevent your occurrence. They want to remove you from consideration. They want to deny you access to a place, group or privilege. They want to isolate you. They want to punish you for going no contact with them. So they want you to feel like they're doing better without you. And you're making a big mistake. So you're the one who has to pay the price for your decision. Because now everyone is going to be against you. Everyone is going to think you're crazy. Everyone is going to think you're bad or you're the narcissist. It's divide and conquer. They make people disagree with you. So that you will not join together against them. It's how they maintain their control over you. Four. Narcissistic rage. When you go no contact with a narcissist. It will cause a narcissistic injury. Which will be followed by narcissistic rage. They will be very angry. They will try to force you to do what they want. They will make excessive demands. They will try to control you. Because they're trying to intimidate you. They're trying to punish you. They're stunted at the emotional development.  So when you go no contact. They will throw a temper tantrum. And it's because they can't get what they want. So they will be angry. Because they know you're slipping away. They know they're losing control of you. So this is how you know that they're losing their grip. And this is when things will start to get better for you. Because narcissists are at their worst. Just before they give up. Five. They give up. Eventually the narcissist will give up. They won't know what to do. They won't know what to think about the situation. They will no longer be able to uphold their grandiose covenant image. So they will withdraw. Because they have a very fragile ego. They see the world as a place where they have to survive. So they're constantly in survival mode. But sometimes they just give up. They stop trying. And when that happens. You won't hear from them. Because they don't want you to know about it. They don't want you to see it. They don't want you to have the last laugh. So they stay ghost. They stay hidden. Six. New supply. At some point they're going to look for new supply. They can't live without it. It sustains them. But it won't always be a relationship partner. It could be a friend or family member. Someone they're using as their emotional tampon. Someone that they can vent to. Because they have all of this emotional baggage. And it's too much for them to carry. And you're not willing to hear about it anymore. So they have no choice but to find someone else. Someone who is going to listen to all of their problems. Someone who is going to believe all of their lies. That's the only way that they can feel sane. They need people to validate the illusions of their false self. Thank you for watching. I hope this video resonated with you. Please like, comment, share and subscribe. If you would like to donate. My PayPal link is in the video description. Coaching inquiries. You can email me at coaching.naxivert.uk Thank you for watching and I'll talk to you soon.


I've been videoing the whole thing. I just videoed that whole sequence. Scaring the laver. Yep. I just can't believe that. No number on that helicopter is HOL, so waiting for them to do their shot. Couldn't hear it from here. It's too far away on the choppers. Also facing the other way. I'll see some of that valley. Another shot. It's the third shot now. Fourth shot. Saw a big ball coming back down that gully. Saw a centre screen there coming back down so the chopper went back in and hurt it and back up. Five. Not particularly good shots. This is all happening on dock land. Six.  Apparently they've got the tar underneath already so they've just pulled it up so we're going to gut it out now. Just there on the right hand side of the skid. Can't tell me that's not trophy hunting because they flew past a lot after they skid them out.


Welcome to All Hands Update. I'm Petty Officer Andrew Johnson. These are your headlines for Tuesday, July 8th. Sailors in Japan are preparing for Super Typhoon Naoguri. Naoguri is expected to arrive in Okinawa as a Category 5 storm with winds reaching 150 miles per hour. Sailors are encouraged to be ready throughout the typhoon season, which runs June through November. In career news, an update to Special Duty Assignment Pay, or SDAP, for eligible enlisted sailors was released in a NAV Admin June 7th. The program encourages qualified sailors to serve in Special Duty Assignments by offering a monetary incentive of up to $450 a month. SDAP bonuses are offered to sailors working in specific jobs. For more information about the SDAP program, visit the Navy Personnel Command website.


I don't think there are security pins in this lock, but the tolerances are definitely quite good. Especially for what's clearly a very used lock. ERA, no idea what model. Lock, very used. That's prepaid. And, soon to be gutted. There it goes. Circle it off. Key in. Rotate. Follow our lever. We've got more key pins. I'm just going to dump it. All right. Plug, nothing special. No counter milling. And all standard pins. So I'm just going to go with a good tolerance lock. And... Andor. Very novice picker. We're both. These things that I think are the drivers. I should see if I can work it out later. Anyhow. Nothing special. All brass. So... ERA SPP'd and gutted. Here's the... front of the lock. That's what you might know what kind of lock this is. There we go. Five pinner. Rim cylinder. This is Alex. Thanks for watching. Have fun. Keep it legal.


Let's understand implementation of Scheduled Apex class. So in previous lesson, you understood how Scheduled Apex is scheduled through code and UI. So let's see a real example now. So I'm just creating a Scheduled Apex class. So I'm naming it as daily opportunity processor and using interface as schedule label. So I just implemented this schedule label interface. Now I'm going to define execute method. So public void execute schedule label context CTX. Then now I'm going to query some data. So list of opportunity. OPP list equals to select ID lead source from opportunity. Here lead source equals to null and I'm setting limit as 200. So after querying this data, I'm going to implement a loop. So this loop will be on opportunity list. So one by one, the records which are available under OPP list will be available in this OPP instance. And here I'm writing OPP.leadsource equals to VAP. So wherever lead source is null, those records will be queried automatically and their lead source will be set as VAP. And after that, I'm going to write update OPP list. And like I can write null check as well. So if not OPP list dot is empty and inside this, I can write this statement. So this way, this Scheduled Apex class is implemented. So now we can schedule this Apex class. So we have two options like we can go with code and we can go with UI as well. So let me just search for this Apex classes. So here we have Apex classes option and I can click on this schedule Apex button. And let's say I'm naming the job as run opportunity processor daily. And here I need to search for the Scheduled Apex class. So those classes where Schedule Apex interface is implemented, those class will reflect here automatically. So the class name is daily opportunity processor. So I'm selecting that. Then I am selecting weekly, Monday, and start date is today's date, 23, 1, 22 and end date will be 23, 2, FAP. So one month duration and before the time, let's say 12 a.m. So this data I provided and I clicked on Save. So as soon as I click on Save and I go to Apex job, so here you can see one Scheduled action is available here in this row and this is the information. So submitted date and here you can see the Apex class through which it will be executed and this is the job ID. So this way you can see like whenever you schedule any Apex Scheduled Apex. So this way the entry will be available in your Apex job list. But now after this I'm jumping to Developer Console again and now I'm going to implement its test class. So daily OPP processor test. So I will be implementing its test class so that we can see whether code is covered or not. Because whenever you will be deploying this Scheduled Apex to production, you need test class as well because their limit is 75% code coverage. So I am creating at the rate is test annotation and then I'm writing a method, public, static, void. Method name is test Scheduled Apex. So I created a variable OPP list of type, list of opportunity. And now I'm going to create some opportunity records. So I'm going to create 500 opportunity records. So if I is less than 250, so different set of opportunity records will be created. So OPP list.add the new opportunity, name equals to test plus I, stays name equals to prospecting, close date equals to system.today. So this way this part is implemented. Now inside else, I need to implement it false case. So I copy pasted this and here I'm going to provide lead source as well. So I'm providing lead source as web. So basically, so with the help of this loop to sorry, 500 records will be created, 250 will be having lead source as web and 250 won't be having any lead source, they will be blank. So as a daily opportunity processor queries those records where lead source are null. So that's why I created records in such a way. Now I'm writing insert OPP list. So all the opportunity records that we created will be inserted, then test.starttest and string job ID equals to, now here I'm writing system.schedule and here process opportunities. Now here I need to pass acronym for date and time where we want to execute this and then the instance of that scheduled apex class. So here I'm creating that string as 0, 0, 0, 15, P, question mark, 20, 22. And I'm passing that as a parameter here and new daily OPP processor. So this will be the instance of that scheduled apex class. Now after implementing this, I can call test.stoptest. It is saying variable doesn't exist, okay. So I just, I'm just creating it here. So now this error will be removed and for assertion, I'm going to create one more list, updated opportunity list. So here I will be querying the data. So select ID, lead source, form, opportunity, where. So now I need to apply the condition. So here in the condition, I'm writing lead source equals to web. Now here earlier I mentioned lead source as web. So here I'm putting other. So just jump into object manager and I'm going to open a opportunity object. Under fields and relationships, I'm going to search for lead source and in lead source, like we have these pick list values. So I'm choosing others here because what will happen like on these 250 records, like we have not provided any lead source. So after execution, they will be having lead source as web. And if I provide lead source web here as well, so a total number of records will be more. So out of these 500, like 250 will be having lead source as other and 250 is having nothing as lead source. Now, when I execute this code, when I execute this code, so this statement will be executing that scheduled apex and after execution, we need to make sure like we have some opportunity records where lead source is available, right?  So these two arguments will be compared. If they are equal, then this assert will be executed properly, otherwise not. So this way this test class is implemented and now we need to execute this test class so that we can see like whether the code is completely covered or not. So now if I run this test class, so here you can see this grown expression. So earlier I mistakenly said this has a chronem, so this is not a chronem, this is grown expression. So here for test class, like you can put a question mark and then a stress, a stress, a stress. So it will be executed like every midnight. So you can use this grown expression for test class. Now, just opening this tree and clicking on tests, run test. So it is executed successfully. No error is there. And if I go here and if I check the code coverage, so it is 100%. Every statement is covered with the help of this test class. So this way, like scheduled apics, I demonstrated with the help of this schedulable interface and I also demoed you like how you can implement its test class.


Hi, how's everybody doing today? I'm here with our very special guest, Yap Verbas, the CEO of Kavu Mining Corp. How are you doing today, Yap? I'm doing very well, thank you. Very excited to learn more about you and learn more about your company. I know our community is very excited about Copper and very excited about having you on the show. Now, the company's primary focus is Copper, which is great because there's a lot of excitement in our community about Copper right now. Can you tell us why Kavu chose Copper as its primary focus? Sure, that actually goes back to when we got the company started about a year, year and a half ago. And we saw that there was a lot of excitement in Gold. We felt that was maybe not the sector we wanted to be in for its ups and downs. And we were all kind of excited about Copper. Copper seemed to be somewhat of an underdog at the time. And so we got Kavu rolling as a Copper-focused explorer with, we're open-minded, of course, to other metals that will be used in the coming electrification of the world. But mainly we're focusing on Copper because Copper is used in anything that is electric, electric vehicles, of course, but also phones and other things, anything that you need, that you need wiring for needs Copper because it's such a good conductor. At the same time, there has been about a decade of underinvestment in exploration. And as the Copper price is now a lot higher than it was over the past few years, miners are rushing to get their Copper out of the ground, which means they eat their own supply. And so they need to increase their resource base. And that's really where Kavu comes in as an explorer. What we try to do is we try to find the next project that will be hopefully part of that resource base of an actual miner down the line. Fantastic. Now let's talk about the company's recent news highlights, which we've talked about here on Rich TV Live. Kavu has been releasing drill results on the current project in the Yukon both last week and this week. It looks like the market is responding quite well. Can you go through some of the news for us and break down for the viewers to better understand what these drill results mean? For sure, yeah. So what we've done and we're really happy with the results, of course, as you can imagine, what we've done is we took the project on in April or the last day of March, I think we closed the option agreement. And we planned our first drill program and so we're now seeing the fruits of that. We intersected 20 meters of 1.4% copper or 22.2 meters, I believe, of 1.4% copper, which was released last week. And that was the day that Kavu traded up, I think somewhere around 20% or so. So that was a great day for us. That really what that showed is that there's, and that was the longest high grade intercept to date on the project, the longest time 1% copper intersect on the project to date. And so we're really happy with that. What it shows is that our technical team knows how to get at the high grade zones in this area. It's a very large area, which we now call copper castle. There's a lot of copper mineralization there, but within that, of course, there's places where you wanna find the high grade and places where we know there is lower grade mineralization. And so this is really a vindication of that we know where to place our drill holes and taking these drill results together with some of the geophysics, which we've also put in our last release last week. It shows that there's a lot of potential for extending the high grade zone, where it's actually the lower grade area that seems to have been drilled more if we take that correlation with the geophysics to be correct. Today, we released results from our one hole in a new target area, which has hardly ever been drilled. And we also intersected 160 meters at 0.24 copper equivalent, which is in this type of area, this is a porphyry target. And so what we'd expect is longer intervals of lower grade, which is a little different than the copper castle area. But it shows that there are mineralized sections in that porphyry target, which are consistent with there being a mineralized intrusion, which it's a huge transformative drill hole for the company. Wow, congratulations. Yeah, thanks. And congratulations to the investors at home, because I know a lot of our investors are just gobbling up the stock. They love copper. Can you give the viewers that are watching an idea of how the recent drill results compared to historical Yukon properties? Sure, but you know what there's, the interesting thing is that the Yukon, the Yukon has some great copper projects, one that people know of well as probably the casino, there are others like Triumph Golds, Revenue and Nucleus area. What's important, but actually this copper belt that we have in Yukon, it continues into BC and Southern BC also has a lot of these copper projects. What's important to realize is that when you're looking at the resources of more developed companies, and of course, Kavu is an early stage explorer, so we've taken a leap in the right direction, but we're not, we don't have resources yet. But I prepared this, let me just bring up these numbers here. For example, in casino, the total measured and indicated resource is 0.2% copper. So if we're talking about a drill result, of where we have 100 meters at 0.2% copper, that's within that range. And so, yeah, that's great. It's great, it's on par essentially. And of course, it's now our job to show that the zone extends in all directions and to depth, et cetera. And we can't do that without more drilling, of course. So that's what we're planning to do. And it's the same going further to the South and to BC. These porphyry targets tend to be low grade, bulk tonnage projects, but somewhere in the range of 0.2 to 0.3% copper in the resources. So that's why we're so excited. Another thing that investors should know is that the age of the geological environment of the hopper, and we have a lot of experience with the geology of the Yukon, it's an area I did my PhD on and our vice president of exploration did his masters in the Yukon. That's how we met. He actually continued to do a PhD at Laurentian University, again on intrusion hosted polymetallic systems. The product is a great fit for us. Anyway, I digress. But the reason this is geologically so interesting to make that comparison between casinos that casino is the exact same age as the hopper project. And so we believe that we've extended the known copper region of the Yukon quite a ways to the South by this drill hole. Very good. Now your flagship hopper project, can you tell us why you selected this location? Sure, yeah, it was a long exercise essentially in what we did, and we tried to take the opposite approach from what most juniors would take normally, which is normally what you do is somebody comes to you with a project and you say, okay, there is some drilling here and there's some mineralization that's served or for sure we'll take a stab at it or not. But really what you wanna know is that you're in the right region and in the right district, et cetera. So what, but Luke and I, Luke is our vice president of exploration. What we did is we reviewed all the government and the available data from the Yukon and BC and try to figure out, okay, well, what do these good copper deposits and copper projects look like in the data? Where are the faults? Where are the magnetic highs, the magnetic lows? How does all the data fit together? It creates the type of signature for that and then try to look at where else can we find that? And that's our mantra throughout this process has sort of been we wanna work on something that has the potential to be world-class because life is too short to work on anything else. And that's what we've held up and we kept doing that and that's how we settled on the copper projects. Fantastic. Now I understand in the past, it's attracted attention from some of the majors and there were some big transactions like Rio Tinto Canada Inc. Investing 25.6 million Canadian, 21.2 million US to acquire roughly 8% stake in Western, copper and gold corp and a foothold in the exploration company's casino copper project in Canada's Yukon. Can you tell us what this means for the Yukon region and how Kavu compares to the casino copper project? Sure, yeah. So the, I mean, the majors get into these projects because they see the ability to develop a mind down the line, right? And that means that the jurisdiction is good enough, the permitting process is clear enough. The, there are no big jurisdictional risks that would stop the permitting of a large mine. And so if you get majors that come in that say, well, we see that this is an economically viable project and we see that, you know, this could be a mind down the line that is great news for the jurisdiction for the Yukon itself, as well as for the company that they invest in, of course. And so for us that tells us as a junior explorer, it shows that we're in the right district because that, you know, there are majors active there and it's, it is a Rio Tinto for the casino project, but there's also Zijin mining and I believe Newmont that have a stake in Triumph Gold Corp, which have a large porphyry project to the north of us. So that's, that type of interest is, it's a very big deal for a region. And it gives us a way to, you know, look at the future and see what may be possible if things go in the right direction for Kavu. How does Kavu compare? Well, as I said to the, to a project like casino, of course, we're an early stage explorer. So there is much less drilling on Kavu's project than on casino. So it's essentially, you know, where, where casino would have been a long, long time ago before they knew that they had resources, et cetera. And so, and the disclosure I should add is that we don't know if we'll get to a resource but if you are willing to, you know, trust that we know where to put the drill holes and that the project is as good as we think it is, then investors can follow us along that growth path. Can you give us an idea of how it's been to work up in the Yukon region and how Kavu has shown resilience? Sure, so I guess really what, you know, the Yukon is a great place to work but it's been challenging the plan remote exploration for any exploration really since the global pandemic, the COVID-19 pandemic that's made things fairly difficult. The Yukon had some border restrictions when we started drilling, which meant there was a lack of manpower in the Yukon. I had to isolate when I crossed the border into the Yukon in camp, for example, those things. And that makes it a little harder and the industry is incredibly hot right now. So there are not a lot of drill crews available, for example. But despite, you know, our short timeline because we acquired the project in, as I said, the last day of March, we were drilling by I believe the 10th of July or so. So just a few months later, we really, and not, you know, it was quick. But I think thanks to myself and Luke, we were able to really go through all the data in detail and pick good targets. And that's really what we're now seeing the results from in our drill results. And so yeah, drilling in July, we got the program started going properly, probably 10 days in or so. You know, there's always a bit of a startup when you have to get camp together and drill yourself to get used to the rocks and all these kinds of things. Then there was a fire about 300 meters from our exploration camp, maybe 400 meters. But that's where the fire started. So we had to evacuate. Wow. We got all the crews out. We made the decision to evacuate very quick because how close it was. And we were, you know, we're in contact with the RCMP on how the fire may have started on, and it ended up being just a camper. It's the downside of road access is that there's a lot of recreation along that road. And so people build campfires and they do that sometimes when it's too dry to build a campfire in the wrong spot. But regardless, we were drilling again, I believe two and a half days later when the fire crews were still mopping up the fire, we were thankfully in time for the fire crews to save our camp, et cetera. They held the line next to our camp while the fire raged another kilometer to the other side. So it was pretty exciting. I would say that's a bit of resilience there on, you know, from the entire team. And we finished our drill program. Wow. Yeah, so that was great. As far as the Yukon goes, otherwise, you know, it's, a lot of people think it's far into Canada's North and it's remote and it's in a difficult place to work. We've got road access. The road is mostly maintained by the government. There is power that goes over that road, 20 kilometers to the south. There's a hydroelectric dam there. So all these things are covered on our project. And you can fly into Whitehorse, which is, you know, the main city in Yukon and drive to our project with a standard truck in two and a half hours or so. Wow. Yeah, that's a lot of resilience and the fact that you guys were back to drilling just two days later, that shows that you guys are very serious about your success. Now, in addition to that, I thought this was pretty cool. There was an advisory board appointment of a First Nations board member. Why was this important to Kavu? And what does this mean for investors? Yeah, a good question. We've been, that's Alan Adirza is, I can't remember exactly when he became our advisory board member, but it's fairly recent where we've worked together with him on a couple of things now. There's a few things that are important there.  He's negotiated several, you know, big agreements between industry, government and First Nations. And so what he brings to us mostly is a First Nations perspective on the mining industry. And one thing that the mining industry has a bad reputation for is that, or used to have, I think a lot of that has changed. But, you know, what's happened in the past is mining exploration companies, mining companies would go into the traditional territories of First Nations and they would open up a mine, exploited, reap the benefits without giving anything back to the community in terms of employment, et cetera. So the people that live closest to that mine actually don't benefit from it. And that's wrong. That's unethical business and that's not the way we want to work. But we also realize that we don't, within our board and, or the board of directors and myself and there's no other First Nations member there. And so we thought we need another, we need a First Nations perspective within the company. And so he's been very helpful for that. The other thing that investors need to realize is that First Nations in Canada are the largest private landowner. And so when it comes to finding the best regions and districts that may host good projects, many of those will be on private land, which is not open for exploration unless you can come to some kind of agreement with First Nations or with the local First Nations. And Alan has the connections to to start talking about these things. That's two things. The other thing that it shows, I think from Kavus side is that we're willing to be held to the high standards because Alan has been very clear to us as well. He's like, you know, there's having me on your advisory report doesn't help you get away from having the tick of the environmental boxes and doing your exploration in a way that is as sustainable as possible, et cetera. So we're here, we want to do things right. And Alan is a part of that. Fantastic. And lastly, what do you think Kavus growth plan to success is? So we're of course, we're super excited by the Hopper project and we see the potential there for a big mineralized porphyry system as well as our copper castle success from this year. That is in itself, you know, there's a lot more drilling we can do there. We will be doing a bigger drill program next year. So you can expect much more results to come onto the market from the drilling. At the same time, we continue to look for other properties in Canada as well as elsewhere in the world. And that includes copper projects, but also we're looking at potential nickel PGE cobalt acquisitions. And so we're an explorer that is, you know, continually looking for great projects and at the same time has a good growth plan just with the Hopper project. Well, thank you so much for your time today. The CEO of Kavu Mining Corp, Yap Verbas. Thank you for joining us today, Yap. Thanks Rich, it was great. Always a pleasure. And I must remind you guys that are watching that Rich TV Live is strictly for information and educational purposes. Please do your due diligence, do your research before you invest in anything that we talk about or discuss here on Rich TV Live. Now in saying that, I do believe that copper is a very hot sector right now, especially with the whole world going into electric vehicles and a massive mandate by 2030. I think copper stocks are going to be in high demand. Put Kavu Mining Corp on your watch list, put it on your radar. Thank you guys for watching. If you're not winning, you're not watching. We bring you the winners and we bring them to you first. Thank you for watching everybody. Have a nice day.


March is women's his 30 month celebrating and recognizing others is a central part of wellness. It can increase feelings of well-being and help us to connect with others. The women of the high school community are valuable. They deserve recognition for their contributions to the community and society. As a woman, it is very empowering to see how the San Jose State University College of Professional and Global Education is led by two women, Interim Dean Namrata Shukla and Associated Dean for Academic Sandra Hirsch. As per the data from 2021 published by the Department of Professional Employees, about 83.2% of librarians are women. All the librarians as a profession have come a long way as documented by the American Library Association Archives. We have more to do to achieve salary equity, gender equality and health benefits for women. We can all do something from where we are. Join forces with library associations or your local student chapter. The high school has various student chapters. Check them out. I also invite you to visit the pages of the ALA committee on the status of women in librarianship. The association of research, college and research libraries, women and gender studies section, and the ALA's social responsibility round table, the feminist task force. And remember, we celebrate women every day.


I feel good. I feel good. Better, better, we got the win. Let's say I didn't swing at the best pitches tonight, but I had OK at bats. Any of that putting pressure on yourself to come back and produce right away? No, not really. I felt pretty calm. Just how the day goes. I think it'll take a little bit of time to get yourself comfortable at the plate. Um, I'm not sure. I think I had a good base coming in, so just tighten up the zone and be OK. I think that you made there. Did you think you had a shot at that? And I think there's a kid right there. You had to go around. Yeah, the wind is swirling out there, so I just thought I'd get to the wall and maybe we'll come back. Carl, a big cheer is when I announce your name in the pre-game and then a few boos after the first step out is just the par for the course here.


working as an assistant professor in Wolchen Institute of Technology, Sulapur. Today we are going to see matrix operations using SILAB, Learning Outcome. At the end of the session, students will be able to perform basic arithmetic and matrix operations using SILAB. So, these are the outline, basic arithmetic operations on matrices, basic matrix processing. So, let's see basic arithmetic operations. First operation, addition. Second, subtraction. Third, multiplication. Fourth, division. Let's see the first operation that is addition. Let's define 2 by 2 matrix, matrix A having 4 elements that is 2 rows and matrix B, 2 by 2 matrix A and 2 by 2 matrix B. For addition operation, the plus operator is used for the operation. Here we get the result as 3, 5, 7, 9 which is the addition of matrix A and matrix B. 1 plus 2 is 3, 2 plus 3 is 5, 3 plus 4 is 7 and 4 plus 5 is 9. Next operation, subtraction. For subtraction operation, we use minus sign. So, let's define matrix 2 by 2 matrix A and 2 by 2 matrix B. Here, we get the result as 1, 1, 1, 1 as the matrix A and matrix B are subtracted that is 2 minus 1, 4 minus 3, 5 minus 4 and 3 minus 2. So, the answer is a square matrix that is 1, 1, 1 and 1. Next operation that is multiplication. For this operation, a star operator is used. Let's define square matrix that is 2 by 2 matrix having elements 1, 2, 3 and 4 and second matrix having 2 rows, 2, 3 and second row 4, 5. Here the matrix multiplication results in 10, 13, 22 and 29 as the multiplication of A and matrix B is occurred. So, the main dimension of matrix is the basic matrix finding the dimension of matrix is very important. To find out the dimension of matrix, the operator size is used. Let's define a 3 by 3 matrix having elements 1st row 11, 12, 13, 2nd row 21, 22, 23, 3rd row 31, 32 and 33. So, for finding the dimension of a matrix a function size S, I, Z, D is used so that it determines 3 and 3 that is it has 3 rows and 3 columns. In the same way the diagonal elements of a matrix can be found out by using a diagonal operator that is D, I, A, G which is used to find out the diagonal elements of a matrix. Here the diagonal elements of a matrix are 11, 22 and 33. So, when a function D, I, A, G is given it shows the diagonal elements of a matrix. Next trace of a matrix can be found out trace of a matrix is nothing but addition of the diagonal elements when the diagonal elements are found out the addition of the diagonal elements is nothing but the trace of a matrix that is the answer is 66 here it is 11 plus 22 plus 33 that is 66 trace of matrix A is 66 when a vector is defined when a vector is defined with a random number of variables the minimum the element which is minimum can be found out by using function m, i, n that is when a vector x is defined as 5, 10, 15 and 20 so when a operator m, i, n is used then it gives us 5 because 5 is the minimum element defined in the vector. In the same way the maximum element in the vector can be found out by using a function m, a, x as we see here vector x is defined as 5, 10, 15 and 12 so when a vector m, a, x is used then it gives 15 that is 15 is the maximum element in the defined in a vector we can also find the mean of a vector mean is nothing but the average of all the elements that is when a vector x is defined as 5, 10, 15 and 12 the addition that is 5 plus 10 plus 15 plus 12 divide by 5 that gives 10.5 so in this way mean of a vector can also be found out so I just want you to pause the video for few seconds and list down few matrix operations you know let's see so this is the upper triangular matrix lower triangular matrix and transpose so what is lower triangular matrix a matrix which contains the diagonal elements and elements below the diagonal so let's see how to find out lower triangular matrix so a matrix A is defined as 3 by 3 matrix consisting of 11, 12, 13, 21, 22, 23, 31, 32 and 33 so when a function t, r, i, l is used diagonal elements and the elements which are below the diagonal in the same way we can found out upper triangular matrix upper triangular matrix is a matrix which has a diagonal elements and the elements above the diagonal when a matrix 3 by 3 is defined as 11, 12, 13 21, 22, 23, 31, 32 and 33 so when we use a function t, r, i, u of a matrix A then you see the output comes as upper triangular matrix that is diagonal elements and the elements above the diagonal so let's see a transpose transpose of a matrix is nothing but a row is converted into column and the column is converted into row either row or columns are converted vice versa so in this dash operator is used a 3 by 3 matrix is defined 11, 12, 13, 21, 22, 23, 31, 32, 33 so when a dash operator is used a dash operator is used it converts first row that is 11, 12, 13 as a first column 21, 22, 23 as a second column and 31, 32, 33 as a third column so transpose of a matrix can also be found out on the psi lab eigenvalues and eigenvectors can also be found out in psi lab by using psi lab so let's define a matrix 2 by 2 matrix that is 1, 2, 3, 4 the function spec is used for finding the eigenvalues that is we have found out that is as you see here the output for eigenvalues given here and the eigenvalues and eigenvalues after finding the eigenvalues eigenvectors are also found out as you see here so references are book, modeling and simulation in psi lab psi course by Stephen Campbell a book, psi lab by Hema Ramchandran and S. Nair thank you


Here's Betelgeuse in early 2019. Normally, the star expands and contracts, brightening and dimming on a 420-day cycle. However, in October 2019, the star dimmed dramatically. Hubble captured signs of dense, heated material moving through the star's atmosphere in September, October and November 2019. Then in December, several ground-based telescopes observed the star decreasing in brightness in its southern hemisphere. By mid-February 2020, the star had lost more than two-thirds of its luminosity. The ultraviolet observations by Hubble suggest that the unexpected dimming was probably caused by an immense amount of super-hot material ejected into space. The material cooled and formed a dust cloud and blocked the sunlight coming from about a quarter of Betelgeuse's surface as seen from our line of sight. By April 2020, the star returned to normal brightness. The giant star is destined to end its life in a supernova blast. Some astronomers think the sudden dimming may be a pre-supernova event.


From VOA Learning English, this is the Education Report. Reaction appears mixed to a recent United States Supreme Court decision on affirmative action in university admissions. Affirmative action in admissions means that schools give special consideration to some racial or ethnic minorities. The goal is to create a more diverse campus and to give more opportunities to groups that are underrepresented in higher education. The Supreme Court ruled that race can be one of many factors considered when a student applies to a college or university. The court said education benefits from having diverse student populations. Some legal experts thought the justices would strike down a 2003 Supreme Court ruling. That ruling let universities use race in admissions decisions, but as just one factor among others. In the new decision, the justices did not deal with the question of affirmative action itself. Instead, the justices sent the case back to a lower court for further consideration. A white woman who had been denied admission to the University of Texas at Austin brought the case. Abigail Fisher argued that it was wrong to reject her when minority students with similar grades and test scores were accepted because of affirmative action. Wade Henderson is president of the Leadership Conference on Civil and Human Rights. He said the new decision confirms that race can be a factor in admissions. Adam Aloy is with the non-profit American Council on Education. She says many schools do not generally give special consideration to race or ethnicity of applicants. For VOA Learning English, I'm Carolyn Presuti.