All right, thank you so much for coming, everyone. I think we'll go ahead and get started. Our talk today, as you can see on the screen, is streamlining FedRAM compliance with CNCF technologies. So we wanted to start out by doing just a quick poll of the audience. How many of you are currently going through a FedRAM precreditation process? OK, a lot, actually. That's great. OK, how many people are maybe familiar with FedRAM like thinking about getting into the process? OK, also a lot. And is there anyone who maybe has heard of FedRAM but doesn't really know anything else beyond that? OK, also a couple. OK, great. Well, we have some introductory material but to sort of explain what FedRAM is, what the process looks like. And then we're going to talk about some of the challenges, of course, that we faced and how we solved those. So hopefully there's stuff that's relevant to everyone. Before we dive into the content, we just wanted to do brief intros. Apologies to those of you who came to our talk on Tuesday, as you've already heard these, but we'll keep it brief. My name is Ali Manfri. I'm a senior architect of our federal government business at Palantir. Essentially what that means is I lead our cloud architecture and kind of our cloud-hosted deployments across our federal government portfolio. And I also lead business development for our Apollo product and FedStar program that we'll talk a little bit about later today. And four years ago, I actually led Palantir's initial efforts to become FedRAM and IL-5 accredited. So that's how I got really familiar with this space and then kind of built up our whole technical federal compliance practice that oversees all of our accreditations and all of our ATOs in the government today. Hello, folks. My name is Vlad. I'm a lead in the production infrastructure group. I lead all the teams that manage and deploy kates in all the places Palantir does deploy the software. So that's commercial cloud, high-side cloud, on-premise, and Edge as well. All right. So just a brief overview of our agenda. We did want to do a little bit of an overview of Palantir as a company for those of you who aren't familiar with us and talk a little bit about our journey getting into FedRAM and kind of some of the things that we faced as we initially started going through it. And then we're going to dive into some very specific sort of technical challenges. So as many of you know, there are many challenges associated with pursuing FedRAM accreditation. But we wanted to pull out a few that tend to be the trickiest. And we're certainly the trickiest for us that we'll talk about in terms of challenges we faced. And then Vlad's going to talk about the solutions and how we solved them. And hopefully we have plenty of time at the end for Q&A as well for any of you who have questions that you want to ask us after we're done. OK. So introducing Palantir just very briefly. Palantir was founded in 2003 after the events of 9-11 with the mission to help the federal government make better use and sense of its data while protecting privacy and civil liberties. So all of our first products were about data integration, data analysis, kind of operational use cases involving data. And we first began working in the Intel community. But as our products and our business has evolved over the course of the past 20 years, we've grown tremendously and expanded into many other parts of the federal government. Some of our clients you can see on the slide here expanded into DoD and also expanded into kind of federal health and the civilian government space as well. So you can imagine that FedRAMP and Impact Level Accreditation as our business started to grow was top of mind for many years, honestly, before we started or decided to really go for it. So for those of you who aren't super familiar with it, FedRAMP and Impact Level Accreditation are specifically accreditation's required if you want to sell your software specifically as a cloud-hosted SaaS to the federal government as opposed to on-prem or like a self-hosted, self-licensed model where the government manages everything. So for us as our business continued to grow and scale, delivering our software as a cloud-hosted SaaS was a super important thing because we don't have that many engineers and kind of needed to support a lot of environments. So that's what led us down the journey of thinking, all right, it's probably time to do FedRAMP and Impact Level Accreditation. So we made that decision. We had a couple of back and forth, a couple of false starts, but we made the decision to really go for it in the fall of 2018 and we spent all of 2019 achieving accreditation. So kind of at the tail end of 2019 is when it formally came through. And as we're going to talk a lot about today, our original FedRAMP and IL-5 accreditation did not include any Kubernetes or any cloud-native technologies. So we got through the accreditation process, but we ran into a lot of difficulties with efficiently managing and maintaining the system once we kind of achieved accreditation and that's ultimately what led us down the journey of moving more towards a case-based architecture. So once we made that switch, a lot of the aspects of the accreditation process became easier and we've actually been able to reduce our dedicated headcount by 80% just by standardizing our environment using Kubernetes and meeting a lot of the controls at the infrastructure level as opposed to the application level. So we're super excited to be talking to you all about that today, what we've learned, kind of what we've done and hopefully some of this content is useful for you all who are going through the process as well. Quick overview of the FedRAMP process at a high level for those who are maybe a little bit newer to this space. I'll say upfront, I mentioned FedRAMP and I also mentioned this thing called Impact Level as being the accreditation's required for cloud-hosted SaaS applications. FedRAMP is the accreditation framework that they have for the civilian government space. So if you wanna work in the civilian space, FedRAMP is the one that they use. The Impact Level Accreditation process is the one that the Department of Defense or DoD uses. The Impact Level process can actually inherit from the FedRAMP one though. So for example, if you pursue FedRAMP high and then you wanna pursue IL-5, the DoD will actually accept your FedRAMP high accreditation and then only assess the Impact Level 5 controls that are sort of layered on top or above and beyond what you've already done for FedRAMP. So I bring that up just to say we're talking specifically about FedRAMP today, title of the talk is FedRAMP, but all the controls we're talking about are also relevant for the Impact Level process. So for those of you who are specifically looking into DoD work, all of this content is gonna be relevant for you all as well. So to become FedRAMP accredited, there's a lot of steps you have to go through. As you can see on the slide, the slide is also just from fedRAMP.gov. So feel free to take a look at their website and you can get all this there too. But at a very high level, you need to identify a sponsor or be accepted by the JAB, the Joint Authorization Board, which is essentially your kind of entry point into entering the process. And then you need to document and implement hundreds of security controls. You have to have those controls validated by a third party assessment organization or 3PAO. And then you need to do a final review with your sponsor and with the FedRAMP program management office. So our talk today is not gonna focus on kind of the entirety of this process, but rather on some of the security controls that are particularly challenging to meet. And again, how we use CATES and CNCF tools to meet them more easily. So we will head into some of the challenges that we faced. With FedRAMP and Impact Level accreditation, there are many different scanning requirements that you have to meet. So you have to both run these scans and then appropriately remediate any issues that they flag. So you can see them here on the slide.  You have to do something called STIG scans. STIGs are, these are essentially compliance scans that check for appropriate configuration of specific pieces of your infrastructure. So for example, there are STIGs for operating systems and databases. And so you need to scan those and make sure that those are appropriately configured to government standards and secure. And then you also need to do web application scans. The vast majority of these also need to be done weekly or monthly and you kind of need to be consistently remediating and patching your infrastructure accordingly. So in a pre-Kubernetes world where not all of our infrastructure was uniform and using immutable AMIs and container images, this meant we were scanning every single piece of live infrastructure that we were using, which for Palantir was actually thousands of hosts. So we have a microservice architecture and there's hundreds of microservices for every kind of implementation or deployment of our software. And then we also had multiple different stacks for kind of all of our government agencies. So the scale of this was just pretty tremendous. A lot of these scans do affect the performance of your system. They're pretty CPU intensive and just it was very difficult to keep track of the results of all these scans, aggregate them appropriately and honestly just sort of efficiently managed from a vulnerability management standpoint. On a related note, patching for a very similar reason was also a nightmare. So rolling out all of the changes meant patching and rebooting every single one of these hosts that again, we had thousands of. So in addition to that just being a time consuming and sort of onerous process, a lot of our microservices have sort of service interdependencies and there are a lot of uptime requirements associated with FedRAMP and impact level environments as well. So kind of orchestrating this whole patch and reboot cycle in a way that wouldn't cause any downtime was also just a very complex kind of engineering problem. So we were spending again, just tons of dedicated engineering time and effort and humans figuring this out. The third challenge that I wanna talk about is FIPS encryption. For those of you who are familiar with this process, you know how painful FIPS encryption is. Palantir is certainly no exception. It's really difficult. For those who are unfamiliar with FIPS, this is a government standard for encryption and all of your data both in transit and at rest must use only FIPS validated cipher suites and crypto libraries. So this list is really quite small and it frequently takes a long time for new cipher suites to become FIPS validated even if they're FIPS compliant just because that formal accreditation process with the government can take a long time. So encryption at rest has become a bit easier in recent years with things like KMS but doing FIPS encryption in transit is still very difficult. And again, when you have hundreds of services and you're also dependent on a lot of open source tech like Palantir is, maintaining FIPS validated traffic between from service to service, basically between all of these services and enforcing in every single one of the libraries is a pretty insurmountable problem. And Vlad is gonna talk a lot more about what we've done to make that a little bit easier for ourselves. The final thing here, we just wanted to touch on a couple of additional things that became challenges when we started thinking about moving to Cates. So they weren't necessarily challenges before Kubernetes but when we started thinking about that architecture there were just a couple of additional considerations to take into account that we wanted to sort of share with you all so that you're aware as well. First one is ingress and egress. So how you're managing kind of your front door and your proxy. We were previously using Nginx in a pre-Kubernetes world but FIPS encryption for Nginx is only available with their paid Nginx Plus product and additionally not designed for container first environments. So as we first started kind of experimenting with Kubernetes, we ran into some performance challenges with that as well. So Vlad's gonna talk more about that and kind of how we solved for it. And the last one here is monitoring an instant response which of course is a hugely important set of controls that you have to meet to make sure that you're monitoring the environment and that it's secure. We were using OS Query prior again in a pre-Kates world which worked very well when all of our software ran as a unique process in the host Linux namespaces but with Cates when all the process names are the same OS Query was not enough for us to be able to kind of adequately distinguish between good actors and malicious actors. So this is something we needed to solve for as well and Vlad's going to go into a lot more detail about that. So those are all the challenges and I'll now hand it over to Vlad for the solutions. First I wanna talk about vulnerability and compliance canning. Gonna talk about the operating system. So as Ali mentioned, you need to stick all the software that you have in your FedRAM package and in this case like the operating system, major vendors have this sticks published for their OSs. Canonical has one for Ubuntu, Red Hat has one for REL. What you should expect here is like lag when the sticks actually get validated by this. For example like Ubuntu 20204 still doesn't have a stick and I think REL9 has a stick as of last month but was released some time ago. So you're gonna face challenges when you want to upgrade to a new OS and in most cases you actually won't be able to. The next thing that we did moving to Kate's is we started treating all the nodes the same and we decided to move to basically run an immutable machine image. This allowed us to actually apply all the compliance requirements in CI and actually scan for them. So our developers get like feedback faster if they do something that invalidates the compliance of the machine. Another big change that we decided to do in our Kate's based systems is that every machine is gonna live up to 72 hours. It's like we're gonna nuke it when it hits like the three day mark. We did this mostly from a security reason but it had a very nice side effect so when it related to patching. So patching for us means like just bumping up versions of software in our machine image and then we're rolling out production and in three days we have the certainty that the vulnerability was actually patched and this helped us to roll out things very fast. For example when the run CECV happened a couple of years ago we were able to like deploy it across the fleet in like three days and we didn't really suffer from it. Moving to container images here basically for vulnerability scanning is like we run, we have an internal golden image that all the products use. This golden image gets updated daily with latest patches from upstream and then all the downstream products that use this container image get built automatically. So we have like a waterfall model first you update the golden image and then automation triggers all the downstream builds. On top of this we decided to embed 3V in our software development lifecycle. So during CI we actually scan all the container images that go to production to catch any CVs that appeared after the golden image got updated. Next gonna talk about encryption and network security in the federal context. One of the checklist items in the stick checklist is running a FIPS validated kernel and crypto libraries. Here you have options like Ubuntu Pro, REL and others. What you'd expect is again long processing times for NIST to validate new kernels. We wanted to use some new features from like 5.1 kernel or like a newer kernel for like EBPF features and we couldn't because Ubuntu Pro serverized all the kernel and NIST did not validate it yet. And now moving up the stack for service to service communication. We run Cilium as like the CNI of choice in all our environments and we had to encrypt traffic in services using like FIPS validated suffer suites. And for this we decided to turn on IP second encryption in Cilium. You can do it with a value in the home chart and this actually works in the various routing modes of Cilium that we use. For example, in Amazon we use the ENI, direct routing mode and in Azure we use the overlay routing mode.  And for this we also decided to like use Cilium because it has like very powerful network policy primitives and we also run it in like a deny by default mode. The FIPS theme continues for like ingress and egress traffic. So this traffic needs also to be encrypted with FIPS validated suffer suites. And as Ali mentioned in the previous cloud architecture we were using engine X plus. We had to pay for it to use it here but also we ran into a bunch of performance problems with ephemeral ingresses that get mounted on the front door. So we decided to like look for an alternative and this is when we decided to use Envoy. It was actually designed for running in the container first world and Envoy uses boring SSL as it TLS provider. The nice thing with boring SSL is like NIST validated boring SSL and you can configure it and Envoy at build time just using a command line flag to turn it on. And currently we run Envoy both as like a forward and a reverse proxy as well. Another big thing in the FedJAMP checklist is host intrusion detection systems. We run OS query on all of our machines and OS query is basically an endpoint visibility tool. It exposes various information about the host in a SQL like database. So for example, you can run a SQL query and just ask which kernel modules is my system my system loaded and so on. The downside with this is that it doesn't have any gates integration. So when you have like multiple pods in the same node those pods basically run the same container image. The container image has the same entry point.  To solve for this, we decided to deploy Isovil and Tetragon, which is a tool that uses EVPF to collect host process information. And it also integrates very well with gates in Celiom and gets all the information from other sources. And this actually allows us to answer questions like a process is accessing a malicious endpoint to expel some data, which service account actually deployed that pod, what labels it has, what container image it's running, what network traffic is doing and so on. So this basically gave our InfoSync team somewhat like superpowers to reason about like what's happening in the environment. Next, Ad is gonna talk about some other ongoing challenges that we're still facing. Yes. So as Vlad mentioned, we'll switch to the other one. CNCF Tech has really done a lot for us as he talked about and we've been able to kind of meet a lot of these controls in a more effective way. But there are still a lot of other challenges with FedRAMP and IL controls that can't fully be solved by that essentially out of the box. So we also wanted to talk a little bit about other things that we've done and sort of built on top of Cates that have really helped us meet a number of the other controls as well. So we built a program called FedStart, which is powered by our Apollo product that essentially solves the rest of these challenges for Palantir and also for any other companies with containerized Kubernetes native applications where you want to become FedRAMP or IL accredited for federal government workflows. So we host containerized apps kind of in the product and they're able to seamlessly meet the majority of the rest of the controls and we have a few examples of that here. So the first is change management. A lot of the FedRAMP controls, again, as many of you know, if you've kind of dug into it, revolve around how you are managing changes and updates to the system. And validating that those are safe prior to rolling them out to production. So for example, changes must be tested in a representative environment before rolling out to a FedRAMP accredited environment and security relevant changes typically have to be approved by an authorized US person. So figuring out how to kind of fully automate your change management, you know, especially with the rise of things like GitOps and kind of other automation tools while still maintaining all these compliance checks is something that can be really challenging. And so Apollo and kind of Cates has helped solve this for us with essentially policy-based rollouts. So we're able to do CICD while still enforcing the right approvals, those US person checks where we need them, and also automating essentially that changes rollout to staging or any of our non-regulated production environments before they go to our FedRAMP accredited environments. The second one is there are also a lot of process oriented controls. So, you know, for those of you who are not familiar or for those of you who are, a lot of FedRAMP controls are actually not technical. They're oriented around policies and procedures and kind of building out processes that impose best security practices on your system. So for example, your SDLC or your incident monitoring policy and incident response processes and your contingently planned and all your disaster recovery steps. So our standardized infrastructure based on Cates has made it easier to essentially templatize a lot of these policies and procedures, such that a large part is actually consistent across all of the applications that we run in the environment. So for example, we have a standard way of storing backups for all applications that are running in the environment, in the underlying cloud storage, which makes it easier to enforce that all applications are able to restore from backups rather than needing to deal with kind of a bespoke backup and restore process for every single application that we run in the environment. And the third one, vulnerability management. We've been talking a lot about this one. Vlad talked about how we use Trivi for scans, but the next immediate question task is, okay, how are you going to deal with all the vulnerabilities that Trivi has now surfaced? Vlad mentioned this a little bit, but we essentially manage this by utilizing our own minimized images to limit our CVE exposure for our tech and for a lot of the open source tech that we rely on. And so all the applications that we host in the cluster are able to make use of those as well. So basically by doing that, we're able to really minimize the amount of CVEs that we have to deal with, which otherwise can be a really unruly problem. So overall kind of all these things that we've talked about has taken the accreditation process for any new application that we run in the environment to something that previously could take years to something that's essentially weeks to months instead whenever we wanna make updates or kind of add new applications into the environment. So it's been a really great accelerant for us as we talked about, and hopefully this was helpful for you all too. So that is all the content that we have. And so thank you for listening to our talk and super excited to open it up to any questions that you all have. Yeah, do you wanna use the mic that's right there? Okay, okay, I'll repeat then, that's fine. Yeah, the question was what was the role of vendor support and vendor liaisons in helping us manage and kind of get through this process given you typically have a lot of questions for them about FIPS encryption and other things. Do you wanna take that one? Yeah, I think what we did in our FEDM package, we actually inherit a bunch of controls from the underlying cloud provider. So for example, encryption at rest, we do it via KMS and EBS, S3 and KMS and so on. So I feel like it's basically going for each control and seeing at what level do you solve for it and can you inherit the provider you're running on top. We don't really deploy custom vendor software that handles the data I think in our environments. Yeah, I think that's right. So for example, we don't use a vendor elastic search or something like this to handle our data and then we need to go talk to them, what do you do for all the things you just mentioned, like FIPS encryption and so on. We have that in-house and it's done by our platform. Yeah, and I think a lot of time for hyperscalers, they now have a lot of public listings too of which products are FedRAMP accredited, which are moderate, which are high, so you can kind of look there and at least get a brief view before you have to go talk to a person too, which is helpful. Like for example, Amazon has a list of all the services, like even the FIPS encrypted endpoints that you need to use. So for example, like talking to KMS, you need to use a special endpoint, like S3 the same as on. Yeah, two pretty basic questions. The first one is we make dual use software and we kind of sell self-hosted Helm chart type things. So in cases where you're not the one operating the platform, but maybe you're selling to the government nor the program is operating the platform, who gets the FedRAMP? Like does everything have to go through or is the process different? Or is it just, hey, you don't have to worry about it, it's the person, it's the program that needs the thing yet. Yeah, that's a really good question. So yeah, all the FedRAMP and impact level stuff is pretty much only applicable if you're doing the traditional cloud hosted SaaS, where you are the ones who are managing and operating the platform. And that is because a lot of the controls are around how you do your encryption management, but also how you're storing secrets and tokens and all of those types of things, which you can't actually do if you don't have control over the underlying infrastructure. So we do have a lot of deployments where it's not a SaaS. We've had to deploy into a government managed cloud or on-prem or to an edge device or something like that in a lot of cases. And typically in those cases, you just go through an individual, what's called an RMF ATO, which you may or may not be familiar with, but so once you get these central accreditations, each government agency still has to grant you an ATO or like an authority to operate for that product being used at that agency. So if it's an installation again into a government cloud or something that's not a traditional SaaS, you typically just go through a separate ATO for your software at that agency in that environment, which is more work typically for the vendors because you can't take advantage of the inheritance of a cloud accreditation that you already have. So it's possible to do that, but not usually FedRAMP. And more of the controls are shared between you and the government typically when that happens too. I don't know if that answered your question. Yeah, no, that's a big help. The second question is, do you know if there is any effort or maybe there's already a way to get a vanilla-stigged Kubernetes setup for like just kind of smoke testing your work because it seems, it's kind of intimidating obviously. Yeah. I did not find anything that you can pick off the shelf. The closest answer I can give you is OpenShift, OpenShift container platform. They have a compliance operator that's able to apply and automatically remediate based on the disaster-stig that they have published, but just they need to do a bunch of manual checks in it. It doesn't have support to like fill up all the gaps. But I think that's like the closest one that I've seen. Thank you. Thanks. Hi. Hi, great talk. I had a question about your 72-hour rotation policy for your hosts. How do you kind of reconcile that with databases or things that have huge amounts of data? How do you like deal with the fact that you're rotating these every three days and transferring like terabytes of data between them? I'm not part of the database team, but all the products that's running to our environment need to comply with this policy. I can get more info for you if you go down to our booth or you can actually ask Greg over there in the back afterwards and we can answer this. Okay, got it. Thank you. Yeah, at a high level, maybe the only two things I'd add is we also do make use of some of the managed database services. So AWS RDS, right? Where it's not, they're managing the compliance and so we don't have to deal with the figuring out the role there. But for the databases, we do run in containers, figuring out kind of all that HA. Yeah, I'll defer to Greg, so. Thank you. Hi, is there anything you'll be doing differently with the upcoming Rev5 from what you've presented today in terms of the things you're looking at? Love that question. Yes, we recently basically switched all of our documentation over to using Rev5 so everything is following that. I would say for the most part, it's actually been pretty consistent. Most of the controls got renumbered or something but maybe the language got tweaked slightly but most of it is the same. So nothing has really changed about the way that we run our infrastructure. The primary kind of new control family that was introduced, which maybe you know but all of the supply chain risk and mitigation. So that's been a big one where internally at our company, we've been rolling out new processes to assess basically what are all the libraries we're taking advantage of? How can we actually trace those? How are we generating S-bombs? Like how are we kind of better managing our supply chain security? But that again is kind of baked into like our overall SDLC basically and how we kind of roll out the infrastructure and the application so that we can kind of standardize it everywhere and maintain sort of the same setup that we have today. So that's really the only major thing. Not sure if you had anything particular top of mind but for the most part, we haven't needed to tweak too much with Rev5. I mean, our main concern I think is around the package sending requirements for things like in terms of libraries that we're using or third party stuff and everything else seems pretty straightforward but we haven't cracked that one yet. Yeah, we can talk more about that if there's specific things and loop in other folks if that would be helpful too. Yeah, after, yeah. Hi, great talk. I want to make sure I understand I'm pretty new to these things about Selium, what you said about Selium. So let's say you have a Kubernetes cluster, you have a couple of applications, Java, Ruby, .NET, whatever. Is my understanding correct that you just disable encryption in those applications so that you don't have to worry about FIPS compliance and you make sure that's the Selium service mesh? That's the encryption, is that the case? Yeah, so the thing that we actually do is like we don't change the Cypher suites in the applications themselves. We turn on encryption via Selium and the interesting part is like we do not allow any application to be deployed as host network. So everything's like part of the pod network. So that's how we ensure that all the traffic that goes from service to service, like pod to pod or pod to any destination that needs to go goes through Selium itself. All right, great, thanks. Yeah. So you mentioned policy rollouts. Can you shed some more details on that? And around the deployment and the CI process, what do you guys have to do, any changes there? Sorry, what was the second part? Like CI and the deployment point of view, were there any changes that you guys had to do? Yeah, so policy-based rollouts, yeah. So there's basically a couple of things here. I touched on a few, but we basically have kind of like waves or we call them release channels for how things are actually rolled out across our entire fleet. And so because the government environments have these more stringent requirements needing to test things in representative environments first, that's one of the things we do is basically just like phase all of the rollouts. But then the other sort of policy things that are applied are things like, again, has this change been approved by the appropriate US person with the appropriate role, et cetera, in order to be rolled out, depending on what it is. Has this change existed in a representative environment and not caused any downtime? Like is it actually like a stable release before it gets pushed out to these environments? Basically enables us to define logic with how the changes are rolled out in a way that's automated. So it continues to be compliant, but doesn't need as many engineers to kind of babysit throughout the whole thing. But in terms of your question of how we change the ICD, I do think going for FedRAMP and Impact Level, you do have to change some of your processes because you have these additional requirements. So you can't kind of do the same thing where developer pushes a change and it rolls out to the environment. You do have to meet kind of additional controls and that's where we sort of built the automation that enables us to automate it, but also meets those controls, I would say. So one more question, like you guys mentioned about like Helm charts, sorry, the images and for the host, is there anything you guys had to do for Helm charts or any of the manifests, Kubernetes manifests? For the manifest themselves, no, but all the images that we use, we basically republish internally based on our golden image. We have like more questions, but we're out of time. We can like take them in the back. Can I just actually follow on to that? Are you sourcing the base images from a third party or are you managing them in-house? We are extracting the binaries from the images themselves and then repackaging those internally. Okay, thank you. Thank you. Thank you.


Welcome back to the independent investor channel as we monitor the landscape the volatility is flush Investors are running for the hills. These are the times of times where you want to make sure that you're being Aggressive on uncovering opportunities and no bigger opportunity than a stock that I cover on the channel I cover it very frequently because I feel like right now It's being That's up against a lot of headwind in the market in this video I'm gonna earmark 12 things that I think highly on must do to succeed and I believe that they will number one on the list is Achieve certification.  You want to make sure and visit highly on calm. They'll explain the system It's very very interesting how highly on is looking not to redefine the truck rather to focus on those areas That the truck needs to be improved upon and take our Technology into the next era of trucking as opposed to relying on what has worked Historically being relied upon in the fossil fuels They're looking to really leverage the opportunity with RNG and CNG and to achieve this Certification on their finalized iteration of the rx is going to be a key milestone for the company going forward We're going to want to monitor that progress As we evolve in the company as they look toward those Certification dates number two they need to continue to garner new orders. They've been a little dry on this front I think it's been I think there's fear that's been permeated through the Landscape in the stock market and I think it's affecting highly on and many other stocks out there Everybody's just selling everything which is the stupidest thing you can do when volatility kicks up It's amazing how nobody's coming on to social media and talking about being strong in the face of a stock market That's off 25 percent guys. That's normal Okay, you can talk about all the reasons that you want as to why this is or why you need to get out and wait For better days. It's all ill-advised. Okay, you need to make decisions. That's right for you and Historically these have been proven out to be opportunities to buy in the face of adversity highly on is no different Okay, they've been a little dry on this front And I'd like to see some improvement on continuing to solidify their order book right now sits at about 2,200 mix between reservations and orders backed by deposit But I think they will continue to build this out as we march toward more of a commercialized staged in phase two of the company as they get out of this Product verification and entering into more of a commercialization stage with the company number three They need to build out their current roster. That's what they're doing I cannot complain with the amount of hiring that highly on is doing bringing on that talent in Fields that are very very difficult in technology and engineering they get an A plus as far as I'm concerned This is exactly what we want to see we want to see a build out of the team We've acquired some of the talent from General Electric and the acquisition of the Carnot generator technology And I think that's going to be key to monitor highly on as they build out their team and go from Plus 200 to whatever it's going to build out to be as their footprint Grows as a company as they look to step into that mass commercialization All right number four is to continue to endure the pain that has been succumbed from the supply chain issues This is plagued highly on and not only the sentiment across the board as it's driven up a lot of things food Fuel a lot of things companies are unable to procure the parts Especially in the semiconductor space, but also more so some of the more simple parts that just are not readily available As they have been in past And I think I've seen soft spots where we may ease up a little bit on this and any ease up on what has been Encured over the last year and a half is going to be a welcome change To make sure that highly on can continue to requisition those parts with good faith And continue to get those in-house to make sure that they can fill those completed orders In the products that they look to deliver number five is to solidify Their process with the OEMs and I think if there was any criticism to be had with highly on it Is the fact that I think they need to be a little bit more transparent on this front I think the OEM highly on relationship is such a critical component But what highly on is doing where you make the bull case that they're not trying to reinvent the truck? Well, that's exactly what Peter built does and how are those two businesses going to come together highly on being a very very new Technology and Peter built being an established Company that has transcended the decades and so to really understand more about how they're going to draw this symbiotic Relationship between the two companies is still really in the onset of of its infancy And I'd like to understand a little bit more About those companies that have build slots that are already Reserved with Peter built and how if they wanted to augment their existing build slot with the highly on solution How that's going to play out in the real world now We have other things like incentives how that is going to couple into and and actually get that final product delivered With the assistance of Peter built we just need more clarity on this front And I believe that we will provide it be provided that in the coming months and years going forward We need to leverage existing Relationships and partnerships and and those partnerships that we have with Cummins Penske Ryder those companies out there those networks out there. It's super important That those networks are leveraged to make sure that highly on as a place in their goal of leveraging with those companies as opposed to Inventing a product that they're looking to sell to those companies And looking to more augment the trucking industry And I think it's going to be super important going forward for them to leverage those existing relationships And I believe that they will the next is to validate and substantiate Their total cost of ownership for the fleets This is very important and this is going to come more so in the form of once these fleets take delivery of these original orders Is it going to pay benefit to the bottom line for these companies? This is going to be a key driver in understanding look whoa I highly on boast this ability to provide TCO now Can they actually follow through with that and that follow through is not going to be from highly on to suggest? Hey, look at this TCO. It's going to rather be the reciprocation of their customers They're actual fleets that are putting these erx's into the rigor of over-the-road transport and then Communicating those wins back to the marketplace remember a lot of these companies are publicly held companies anyway And if they can demonstrate to their public that they are not only making this initiative shift to green That they are also providing bottom-line benefit by running alternative fuels and not being so Subjected to the diesel market that has been nothing but volatile over the last couple years It's going to be a net positive for both. So I think it's going to be incredibly important As these companies start to augment the fleets with these few initial orders to provide that bottom-line TCO and to actually prop provide that value proposition of the companies words will get out Return orders will will be forthcoming and highly on will be the benefactor for that by taking on a new client or Solidifying what they've always proposed to be extremely attractive metrics on the bottom line to provide these bottom line TCOs to the to the class 8 fleet that they serve Next is going to be to realize integration This is key when we're out there driving on the highways We are still in an environment here where the trucking industry is dominated by diesel guys This initiative is about moving away from diesel. I'm always one to take a more neutral approach to this We're not going to supplement for diesel at its in its entirety diesel will always be a powerful fuel that drives things But as we march toward a lot of even international initiatives 2050 seems to be that line in the sand that we're looking at to really look to move away from our Exclusive dependence on diesel and look to exploit some of the technology in hydrogen fuel cell using our renewables Using compressed natural gas and moving away from this Complete reliance on diesel to move our goods and so to realize this integration It's going to really unlock that value with the company right now That's being compressed on the stock side and that's fine the content the stock can continue to compress It doesn't mean that it's going to continue to compress until it breaks We may have that spring effect when this value really can be held no more in Secret and the grander audience knows my audience will benefit from having a Forward-looking type of perspective on this and understanding that you've had all kinds of time to look at this as a potential Watchlist stock or even better a potential Investment that you may want to make in the space of going green and moving toward a more alternative energy space Reducing our greenhouse gas emissions in the number one polluter Which is the trucking industry as a whole? We need to leverage those tax incentives. We know that there's incentives on the fuel side We know that there's a forty thousand dollar tax credit We know that there are group discounts as well on the fueling some exciting times for those fleets that run RNG C&G we just need to get that product into the hands of the fleet We're a little bit premature now to expect that we're looking at every other truck on the road being powered by compressed natural gas or renewable natural gas or Hydrogen those those fuels as we march into a more agnostic future and less dependent on diesel It is a ways away and we need to allow these fleets the ample time to enjoy some of these tax incentives and Augment some of that risk that they may be taking on on the onset and allowing some of those proof of concepts to really drive To the bottom line and we're on we're at the beginning stages of realizing just that but I think it's going to be super important to monitor The ACT and the AC of credits the mandates that have been placed on both the OEMs and the fleets alike to take a look at this And I think those are fair. I really do I think the government is saying look the time is now to look at these the technology really has bridged a gap in Efficiency and in some cases both a better performance than diesel now That's yet to be seen here as we're looking at the mass fleets enjoying these these solutions and putting them into the rigor of Over the over the road transport But it's yet to be seen whether or not that that value will be unlocked in the short term Or it'll take more of a medium and longer term perspective on this and number 10 We need to continue to pursue different income streams highly on boast acquisition of the Carnot generator We've already talked about leveraging those different income skews as well as augmenting the Trucking fleet with the service that is made possible by the on-board software that highly on post its proprietary It's more of a monitoring type of perspective and keep in mind they're not looking just to go under the hood and change the solution from a mechanical perspective they are looking to augment and Make a smarter truck and that way we can have preventative maintenance type of flags and allow the driver to and the fleets to have More visibility and the connection between their rigs that they're running and over the road transport And I'll just mention these couple too as a bonus here. We need to improve sentiment around the stock We really need to shift what has been a terrible stock market in 2022 really everything has been thrown out those companies that have Really enjoyed a robust growth cycle over the last 10 12 years We need to shift in sentiment right now because it's not one of those things to be expected that something's going to run To the moon in a market right now that no stock or no company is given favor no matter what they're doing And I think it's going to need a Systematic and a sentiment change here to really start to realize better days and move from a compression stage To more of an expansion stage and finally we'll keep our eyes open on any international and global front I believe Hylian is looking to make their mark here domestically which is smart and once these achievements are made on the Certification side you can bet to expect that there'll be more position to take those global Requests from the company and actually provide the solution on a global scale guys I appreciate you tuning in the totality of the message guys if you like the discussion points this week You can always catch my long video This is for those folks that actually are stressed on time and catch the highlights week over week and Understanding where I put the focus an area of emphasis on what I feel like is one of the greatest Investing opportunities that has come forth in the last 25 years in the market guys subscribe to the channel leave your comments at the bottom I'll catch you in the next video and good luck in your investment future


Just to remind you from last week, we finished talking about the performance of different performance metrics for computer networks, data communication systems, and we had a few examples on data rate and throughput, and we mentioned briefly bandwidth. So we're talking about ways that we can measure the performance of our communication system. How can we choose one technology which is better than another with respect to performance? Some measures, the range of frequencies that a system transmits or is allowed to transmit the bandwidth, we haven't really covered that in any depth. In the next topic, we'll define it and discuss it much more bandwidth. But two that we did cover with some examples, the data rate is the number of bits, a communications channel, think of a link, a channel or a link, or a network can transmit. So our example was when I connected two computers together via a LAN cable, the number of bits I can transmit per second in my example was 100 million bits per second. That was that data rate. It depends upon the medium and it depends upon the transmitter and receiver. For example, my LAN card, it's usually a characteristic of that technology. Think of that as some upper limit of a communication system that defines the upper limit at which we can transmit information across that link or network, a capacity sometimes it's called. But when we're transferring data across that communications link, although we may have some data rate, the way that the protocols normally operate is that when we're transmitting information, not all of that information is real data. Some of it is some extra headers that the protocols need to operate, generally we refer to as overhead. So we can distinguish between what we sent, the bits that we send across the link can consist of real data, data from the user's perspective and overhead, other information. In fact, sometimes we may not be transmitting anything at all, which is further overhead. Throughput is the measure of the rate at which we deliver the real data to the destination. So it only counts the data from the user's perspective, it doesn't count the overhead. That doesn't help the user much, although it's necessary, it doesn't help in terms of performance. So the rate at which the data is successfully delivered to the destination, although we haven't touched upon it, in some cases we can send data across a link, but there may be an error and it's not delivered to the destination. Throughput doesn't count that, it's only the data that gets delivered correctly to the destination. So we saw in an example I had a 100 megabit per second link between two computers, that was my data rate, 100 megabits per second, but when I downloaded a file I achieved a throughput of something like 90 or 88 megabits per second. So the capacity was 100, but the rate at which the real data was delivered was slightly less, in our case about 90 megabits per second because some overheads involved. And the last example last week was I used the Wi-Fi, the wireless LAN, where my data rate, the connection from laptop to the access point was 54 megabits per second, that was the capacity. When I downloaded a file I achieved a throughput of something like 17 megabits per second, much less than the capacity. So the user cares about the throughput, so that's one metric that we're interested in, but in practice it's hard to predict what the throughput will be, there are many factors that impact upon it. The data rate is usually a characteristic of the technology we use. So when you buy a technology often as part of a specification the data rate is given, but the throughput may vary. So there were two or three metrics that we've introduced, we've got one to go to finish this topic, delay. We won't cover packet delay variation in this course, just delay. The time it takes to get a message from one point to another is very simple. So I want to get, let's say, one message or a packet from one computer, the source computer to a destination computer, how long does it take to get that message from A to B, source to destination. That's what delay measures. Measured in the units of seconds, so now time we're interested in, not a rate. And generally the delay across a link or across a network, there are different factors that contribute to the delay, and we divide it into four different factors or components. Transmission, propagation, processing and queuing. So today what we want to do is explain those four and go through some examples to illustrate how they come together to cause a total delay in some network or link. We'll spend some time on each of them, especially the first two, but let's briefly explain them. Transmission delay is the time it takes to transmit the data out of the source computer. So for example, if I'm using my LAN card, I can transmit across the link at 100 megabits per second. So that's the speed at which I can transmit. If I have 100 megabits of data to send, how long will it take to transmit? Again? One second. If I have 100 megabits of data, that's the amount of data, and I can transmit at a rate of 100 megabits per second, then it will take one second to transmit that data, think of out of my computer. That's what we call the transmission delay. If I had 200 megabits of data to send using that same link, it would take two seconds to transmit. So the transmission delay is the time to transmit the data onto the link. Think of out of the computer. It depends upon the amount of data we want to send and the data rate that we have. Now when we transmit bits out of our computer, in fact what we're sending is some electromagnetic signal, some physical signal. In the case of my LAN card, when I plug the LAN cable in, the LAN cable contains some copper wires. And what we transmit across those copper wires is an electrical signal, so electricity. So think of back in physics when we think of electricity or any type of signal, in fact we can think of it as some waveform. We can often visualise it as some waveform. So when we transmit an electrical signal out of my computer, it takes time to go across the wire to reach the destination computer. The time to propagate across the wire. And that's what we term the propagation delay. It depends on the medium that we're sending a signal across, the type of signal and the distance, the length of that link that we have to send the signal. So it's time to send a signal representing, we think of a single bit from the source computer to travel across our link to reach the destination computer. We'll give some examples of that soon. We have computers communicating via a link. Of course the computers before they send something and once they receive the data often need to do a little bit of processing to check the data, maybe the protocols need to do some processing or we send via an intermediate device. I connect this laptop to one intermediate device then that connects to another destination computer. When I send my signal into the intermediate device it must process the signal and then send to the destination. So we have computers involved here and each of them must do some processing. How long does it take? Well that's our processing delay or processing time. It's the time for the device, the computer device to process the data. The source computer, the destination computer and any intermediate computers. We will see that the transmission and propagation delay we can calculate them in simple cases. How long does it take my computer to process a single packet? Anyone want to guess? Well it's very hard to know. How long does it take a computer to do a little bit of processing? It depends upon how much data we need to process, how fast my CPU is, what other applications are running on my computer, how fast maybe my memory is, how much memory I have to spare, maybe my hard drive speed. So it depends upon the hardware and also how that hardware is currently used. The processing time of a computer to process some data is usually very hard to calculate or predict what it will be. The good thing for us is that in most network systems, communication systems, the processing time incurred by computers is usually, when we compare it to the others, is usually very small because computers are fast today. We have gigahertz CPUs. Most computing devices, even if they happen to process a lot of data, usually the processing time is quite small compared to the others. So we'll see in some examples that it's either given or it's assumed to be zero. I would say a little bit more about that in the examples. The last delay is the time some data spends waiting for other data to be processed, waiting in a queue. Let's come back to that through an example a little bit later after we go through the first three. So we'll see that to get data from A to B, different things slow down that data transfer. Transmission, propagation, processing and queuing. We're going to go through each of them. And the total delay, if we know the delay caused by each of these components, the total delay is just the sum of each of them. So if we look at them separately, then we can determine the total delay by adding them up. Let's go through transmission and propagation first. We've got different examples today. So transmission delay, one example, we said 100 megabits of data to send at a data rate of 100 megabits per second will take one second of transmission delay. So transmission delay is really data size divided by data rate. What about propagation delay? How long does it take to get a signal across some medium? Well let's think of an example of a signal that we see all the time. The clock. Okay? Everyone watches the clock waiting for 4pm. The clock emits some light. Okay? You're sitting here in the class looking at the clock, maybe you're six metres away from the clock. The clock emits some light that light travels. Remember, light is just a signal. Think of a waveform for light. Light travels from the clock and it reaches your eyeballs, okay? How long does it take to reach your eyes? Give me a number. Give me a more precise number, less than something, greater than something, nice, but give me the answer. Or something, yes? How would you calculate that? Oh yeah, okay, but now give me the exact number. You're six metres away from the clock. Light speed, okay? The speed of light, okay? Light in this case is our signal. And light travels at a particular speed. So it's generated there and it travels through the medium, the air, and it reaches your eyes. How fast does it travel? Well, at the speed of light. Anyone remember? Speed of light? Okay, I think you're on the right track. And you may not remember, but you will after today. The speed of light, approximately, in fact it's a little bit less than this, people tell me, 300 million metres per second. It's actually slightly less, but for this course we can assume it's that. So the light that comes out of the clock and reaches your eyeballs is travelling at a speed of 300 million metres per second. The speed of light, or which is the same as 3 by 10 to the 8 metres per second. Distance from the clock to your eyes, for a simple example, six metres, okay? Someone sitting six metres away from the clock. So how long does it take to get there? Well, we've got something travelling some distance of six metres at a speed of 300 million metres per second. Then distance divided by speed or rate will give us the time. So in this case, the propagation delay, the time for that light signal to propagate across the medium from the source to the destination is our distance of six metres divided by our rate of 3 by 10 to the 8 metres per second, 2 by 10 to the minus 8 seconds. So there's our propagation delay in this simple example of light being our signal travelling across this six metre distance. Any questions on that? This is physics from many years ago. You've all studied it, but maybe we need to connect it to communication systems. Another example, I'm sending, I don't have the cable with me, but I plug the LAN cable from this laptop into this PC, maybe one metre in distance. And I transmit the bits and as the signal is generated at my laptop, an electrical signal, it passes through the copper wiring and then reaches this PC. How long does it take? What's the propagation delay? How are you going to calculate it? To send the signal from my laptop to PC, what do you need to know? The propagation delay, how are you going to calculate? Answers not there, answers on the board are very close. Distance divided by, is this a data rate? Is this bits per second? What is this? The speed of light, a speed, think of a speed in this case. It's the rate at which light travels, but for simplicity, let's call it a speed, the speed of light in this case. So our propagation delay is the distance, the physical distance divided by the speed at which we're sending a signal. But now the case is a one metre cable between laptop and PC sending an electrical signal. Well, distance, say a one metre cable, what's the speed at which electricity flows through the copper wire? Anyone want to have a guess? Speed of electricity through my copper wire. Approximate. Is it bigger than the speed of light? No, nothing is. And let's say it's, so you don't know. It depends upon the material which the electricity is flowing through. So copper in some case, if we dealt with another material like sending light through optical fibres and have a different speed. But they're all in the range of between about two by ten to the power of eight and slightly less than the speed of light. So I don't know the value. You'd have to look up the exact structure of the material which it flows through. But it's approximately or slightly less than the speed of light. And depending upon the material, maybe two by ten to the power of eight, two point five by ten to the power of eight, let's say, let's give it a number. So instead of 300 million metres per second, let's say it's slightly slower. 200 million metres per second. So if we know the speed, we can calculate the propagation delay. Our one metre divided by the speed, which is five nanoseconds in this case. So same concept, just have different values. The distance divided by the speed. So in real communication systems, what is the speed? Well, it depends upon the material. Usually in the order of two to three by ten to the power of eight metres per second. In this course, unless I tell you the exact values, I won't require you to remember the exact value for different materials. Unless I tell you, then you can assume it's the speed of light. So if I say, in this exam question, you're using copper wires, the speed of light, the speed of transmission is two point five by ten to the power of eight metres per second. Then use that value. But if I don't tell you the speed, then use the speed of light. Because they're very close. We'll see they'll have only small impact upon the end answer in the end. So distinguish between the time to transmit the data, the bits, and the time for the signal representing a bit to travel across the link, the propagation delay. And both of them we can calculate, at least in simple cases. Let's go through one example. This you have in your lecture notes. If you flip through a few pages, you'll see this one on performance examples. And it just gives a very simple calculation. So case one. In fact, in this case, in this example, I'm going to assume the transmission speed two point eight by ten to the power of eight metres per second. Where did this number come from? I looked it up on some website to find out for a particular material what the speed was approximately. And the one I looked at was two point eight by ten to the eight metres per second. We want to calculate the total delay. I'll denote as D being delay of some path or some link. In the case one, we have two devices connected via a single link. A connected to B. So just one link in this case, a very simple system. The data rate of this link is one megabit per second. The length of the link is 10 kilometres. And we want to send one message, one packet containing 100 bytes. How long does it take? Well, we'd normally consider the four components of delay. Transmission, propagation, processing and queuing. We've got a helpful hint at the start saying, for this case, let's assume the processing and queuing delay are very small. Because in practice, they often are in some such simple cases. So very small, let's say they're zero. That means the total delay is really just the processing and propagation delay added together. So we can calculate them separately. Transmission delay, we take the data size, how much data we need to send, divided by the data rate. So I think computer A wants to send 100 bytes to B. It has that 100 bytes of data. What it does is think it transmits one bit at a time. It transmits the first bit onto the link as some signal, then the second bit, the third bit and so on. And it's doing so at a speed of one million bits per second. So in this case, we have our 100 bytes sent at one million bits per second. And we can get our answer for our transmission delay. And be careful of our units and prefixes. Bites, bits, convert one into the other. So we have common units. So 100 bytes is the same as 800 bits, divided by one by 10 to the power of six, mega, 10 to the power of six, bits per second, 800 watt. What's our prefix and units here? 800 minutes, seconds, milliseconds, no, 800 watt. Nano is 10 to the power of minus nine. Someone said milli, someone said nano. Micro, 800 divided by one is 800. And then one divided by 10 to the power of six is 10 to the power of minus six. 10 to the power of minus six, you need to remember your prefixes. Some of you have taken the online lesson. If you haven't already, you can do it after today. Because in the examples, in the exams, I'll expect you to be able to calculate these quite quickly. 10 to the power of minus six, 10 to the power of minus three is milli, 10 to the power of minus six is micro, 10 to the power of minus nine is nano. So 10 to the power of minus six, micro.  Microseconds, in the handout, I've given the answer in milliseconds. It's the same, 0.8 milliseconds or 800 microseconds. Questions, propagation delay is the other component of our total delay. So this is the time to get all 800 bits out of computer A. But when a bit comes out of computer A, it's some signal that propagates across the link. How long does it take to propagate across the link? It depends upon, so what's the propagation delay? It depends upon the length of the link, the distance, and the speed of our signal. How long is our link? 10 kilometers. What's the speed of our signal? In this question, transmission speed, the speed at which we transmit a signal, 2.8 by 10 to the 8 meters per second. And I need my calculator. What was the answer? Maybe I can remember it from yesterday. You can check. 36 microseconds. So our signal takes some time, or our data takes some time to be transmitted, and also each bit that is transmitted takes 36 microseconds to propagate to the other side across that link. If we start transmitting at time zero, at what time has B received all the data? What's the total delay from start to end in this case? This is the propagation delay. This is the transmission delay. What's the total time? It is, in fact, the sum of these two, 836 microseconds. I'll show you another example of a more detailed explanation of why we just simply add the two in a moment. But note, the total delay, and it turns out the same with the other components, is just the summation of each of the components. So if you can determine the propagation delay, the transmission delay. In this case, the processing and queuing delay was zero, but if they were non-zero, if they were given to you, you just add them all up, and you get the total delay. I think the answers I went through on the board are the same as up here, except I use milliseconds. So 0.8 milliseconds, 0.036 milliseconds, total delay is 0.836 milliseconds, or 836 microseconds. There are two more examples in this handout. Case two, you can go through in your own time. We'll go through case three shortly. But let's skip to a different example. This is an example that you don't have. But these slides and some of the pictures in here, they are available on the website. I didn't include them in the handouts. I forgot, but they are on the website. It's a very simple example, no harder than the one before. So don't worry about copying everything down here, but solve the problem. Spend two minutes to find the answer of this case. And to get you started, so we have five bits of information. The data size is five bits to send from A to B. We have a link from A to B is 4.5 kilometers long. The data rate at which A transmits is 500 kilobits per second. What's the total delay? We're delivering that one message of five bits from A to B. And in this question, I don't specify the transmission speed. So when I don't specify the transmission speed, use this value, the speed of light, 300 million meters per second. Just try and quickly solve it. Don't worry about copying down the question too much. I prefer to see the answer. Draw a picture, maybe, is the best way to get started, like the one I've drawn on the board. Capture that information. In the exams, you're allowed to have a calculator. And therefore, it's useful to have one.  So think of the components of delay and then calculate them individually and add them up. Read the question carefully. Be careful of the units. So probably the hardest thing is to make sure you're careful with the units and the prefixes. Check your units in both calculations. In this case, since I haven't given the speed, you can use the speed of light. That's what I used in the answer. So that would be OK, but just to get the same answer as me. OK, so calculate the answer and you're there. Any answers? Final answer? Is that your answer? It's wrong. What went wrong? What's the question say? Five bits, not five bytes. I see most people calculating in the right approach. There's no bytes in this question. Everything's in bits. OK, probably close enough. At least in my answer, I assumed the speed of light. Instead of 2.8, I assumed 3. But that's OK. I mean, there's no problem there. So I think your answer in that case is correct. Anyone want to tell me an answer? Final answer? 36. Maybe, but one thing, I used 3. 3, but that's OK. In any case, the one thing you've got me wrong, you say five bytes, I say five bits. It has five bits. But other than that, I think it's correct. 1, 2, 5, very close.  You just add them together. Just add. Add two numbers. How hard can that be? Sounds good. I think most people are there. No, there's no bytes to convert to. There's five bits, 500 kilobits per second, 4.5 kilometers. And when we go through the answer, I use this as the speed of light or the speed of transmission, not 2.8, as was in the previous question. But in an exam again, if I don't tell you, use the speed of light. But when you need to make an assumption like this, I assume the speed of light, then in an exam at least, you can write it down. If you say, I assume the speed of transmission is 2.8 by 10 to the power of 8 meters per second, I will mark your answer correct if you state that. If you assume 3 by 10 to the power of 8, also correct. But just make it clear which value you chose. Unless I tell you otherwise, you can assume the speed of light. Now, some people are having trouble adding two numbers together, but that's just an issue of making sure you're using the right units and the right prefixes. And you'll see in what I go through. Let's check. We'll go through the long way. Remember, there are four components of delay. In the question, in this question, I say nothing about processing or queuing delay. So that's a hint to you when you're answering this question. Let's assume they are zero. Because we'll see in a simple case like this, they are most likely very small. So we need to make some assumption because we cannot calculate processing or queuing delay, not in this course. So assuming the processing and queuing delays are very small, zero. Therefore, we just have two components to consider. Let's consider them separately. Transmission delay. Now, what is the transmission delay? Well, I'm going to go through the long way and try and illustrate what we mean by transmission and propagation delay. Here's my pointer. You can calculate them. I see everyone calculating of transmission, data size divided by data rate, and propagation length divided by speed or distance divided by speed. I'm sure you can do that. But why do we simply just add them together to get the total delay? And maybe this will help in the explanation. What I'm going to do is draw a diagram that shows what happens at the transmitter A and when B the receiver receives the data, let's say there's a link between them, and show what happens over time. So what this diagram shows at the top, let's say we start our stopwatch at time zero, and we'll draw things on here that show what happens as we increase the time. And these numbers are measured in microseconds, just to save space, to make it clear I've omitted the unit. So at time zero we do something, and after one microsecond something's happened, and after two we'll draw on this diagram. Try and follow, again this is on the website if you want the details. So we have, recall, five bits to send. Just five bits to get out of my computer. So think my transmitting device transmits one bit at a time. The first bit, the second bit, third, fourth, fifth. One after another. How long does it take to transmit one bit? How long, how much time does it take to transmit one bit? Not quite. The rate was 500 kilobits per second. So we know how many, we know the rate it was given. The data rate was 500 kilobits per second, or 500,000 bits per second. We know that, that's how fast I can send. What my question is, how long does it take to send one bit? Okay, so we have a rate to get the time, take the inverse. This is how many bits in one second. We wanna know how many seconds for one bit. This is the number of bits per second, 500,000. One divided by 500,000 is 0.2 by 10, what have we got? If you, 0.2 by 10 to the minus five seconds, which is two microseconds. You can do the calculation. The inverse, here we have bits per second. Here we have seconds for one bit. Two microseconds in here. So one bit takes two microseconds to get out of my computer. Let's draw that. And I'll draw it as, right, sorry, this is transmission time of one bit, two microseconds. Let's try and draw that as this gray box, this rectangle. Because we start transmitting at time zero to transmit that bit, the signal representing the bit out of my computer, it takes two microseconds. So I'd finish at time two. And then I'd start transmitting the second bit and the third bit, fourth bit and fifth bit. And that's what I've tried to show here is these five gray boxes of the time to transmit the first bit, finishes at time two and then immediately start transmitting the second bit. Takes another two microseconds, finish at time four, third, fourth, the fifth bit is finished at time 10 microseconds. Five bits, two microseconds per bit, 10 microseconds to transmit. In fact, I think, well, that's what you calculated as the transmission delay. Just the data size, five bits divided by the data rate of 500 kilobits per second. Well, what's the other component? So transmission delay is 10 microseconds. Propagation delay, how can we visualize that? Well, again, when I transmit, we say we're transmitting a bit, as soon as we start transmitting, some signal comes out of my computer along the cable, some electrical signal. How long does it take a signal to propagate from A to B? Well, I think everyone calculated this or close to, the distance from A to B, 4.5 kilometers, the speed of our signal transmission, the speed of light, 4.5 kilometers divided by 300 million meters per second is 15 microseconds. So as the signal comes out of my computer, it takes 15 microseconds to get to the other computer. Let's try and visualize that. If I start transmitting at time zero, the signal comes out and starts propagating across the link. It takes 15 microseconds to get to the other endpoint of the link, that is to B. So if it starts propagating at time zero, it will arrive at B at time 15. So from B's perspective, it will start receiving the signal that represents the first bit at time 15. That is 15 microseconds after A started transmitting. But in fact, A is transmitting a signal for a continuous period here. A is transmitting the signal out of the computer at time zero through to time two. That signal represents a bit one. So it's always transmitting a signal. Therefore, when it finishes transmitting that last part of bit one, the last signal, at time two, you can think that will arrive at B, again, 15 microseconds later, at time 17. This is the signal propagating across the link. So at this time, B has received the entire first bit. While that signal is propagating from A to B, A is in fact transmitting the second bit and then the third bit, fourth bit and fifth bit. And if we draw them all, we see that as we're transmitting, and the signals representing those bits are propagating across the link. We finished computer A finishes transmitting at time 10. So that signal that comes out of computer A at time 10 is propagating across the link. It's taking its time to get there, and it eventually arrives 15 microseconds later at time 25. So if we finish transmitting at time 10, it will eventually arrive at time 25. And that gives us our total delay. It's the time from when A starts until B receives the entire set of data, the five bits in this case, which is mathematically here the transmission time 10 plus the propagation time 15, giving us the answer of 25 microseconds. So there's two parts here that we're trying to cover, or multiple parts. Transmission delay, data size divided by data rate, propagation delay, distance or length divided by speed. Total delay is the summation of the components. Why? Why do we just add the propagation and transmission delay? Well, this diagram tries to show that we're transmitting at the same time some of those signals are propagating. The total time is the time it takes to transmit all bits plus the last signal to get to B. And that's just the summation of the two and gives us our total delay of 25 microseconds. Got some more examples. Before we move on, what about this one? Any questions? Again, you can download those slides from the website to see the details of that picture rather than having to draw it. Here's a hint, if you don't understand this, at least remember you add the two, you add the delay components together. If you can calculate transmission and propagation for a link, the total delay is the summation. This tries to explain why it's the addition of those two. OK? Easy. So far. The maths is easy. Maybe just be careful. I see people calculating and trying to add up numbers like... What do you have? Trying to add numbers like this, I see people. So not as obvious as taking... So try and use the same multipliers or prefixes here and then the addition is easy. It's just 10 plus 15 by 10 to the minus 6. So try and make your life easier by using appropriate prefixes and units. For example, in this case, I converted everything to microseconds and I ended up just adding microseconds, 10 plus 15. So you can make your life easier by using appropriate prefixes. One more calculation example, then I'll have an example on the computer, a quick demo and we'll finish for today. And the calculations from this performance example, so you have it already. Case two was we extended the link length from 10 kilometres to 1,000 kilometres. We won't go through the calculation, but everything's the same here, but now we have 1,000 kilometres. Transmission delay will be the same because the data size and data rate are the same. Propagation delay, the length has increased from 10 kilometres up to 1,000 kilometres. 100 times further. Our signal must propagate 100 times further in case two. Therefore, our propagation delay will be 100 times greater. Instead of 36 microseconds, it will be 3,600 microseconds. I hope that's the case. Something looks wrong in that calculation. 136.8, I think in this handout this value looks wrong. 357.1, I think it should be 3.6 in this case. We went from 0.036 times by 100, yes. This should be 3.6, not 3.571. I don't know where that comes from. I must have used the wrong number somewhere. And hence, this would be 4.4 milliseconds. The longer the distance, the longer the propagation delay. That's all that one shows. Read through case three. The calculation's not hard. I know you have the answers in front of you, but try and think about how to solve that one. Try and draw a picture in the same way that I drew a picture of the link up there. We have a satellite communication system. We have a satellite in a geostationary orbit. That is, in this case, about 36,000 kilometers above the Earth. And that's in such an orbit so that when the Earth spins, the satellite is orbiting. And it's as if the satellite is always above us. It's fixed because the Earth is spinning at a rate and the satellite is orbiting at a rate such that it doesn't move relative to some location on the Earth. It's a common orbit for satellites for communication systems. And the way the satellite system works is that we have some station on the ground that transmits a signal up to the satellite. The satellite, in this case, takes that signal or takes the message and then sends that message down to some other ground station. So we have the distance from Earth to the satellite. When we transmit a signal up and down, we have the speed of transmission at the speed of light, in this case. The link data rate up and also down is the same, one megabit per second. And the satellite operates in a mode such that one ground station sends up a message. The satellite receives it. In this case, the satellite processes that message, the packet. The satellite has a CPU on board, a computer. It takes some time to process. It's an old satellite. It takes four milliseconds. I just made up that number for this question. So we cannot calculate the processing time. In some questions, I may give you the processing time. How long does it take to send a 1,000-byte packet from one ground station to another? Here's our network. We have a ground station. So something on Earth, say in Thailand, with an antenna. And it transmits a signal, some wireless signal, up to a satellite. The satellite receives the message. In this case, the message contains 1,000 bytes. So we start with 1,000 bytes. Transmits a 1,000-byte packet up to the satellite. When the satellite receives that packet, it simply takes the packet and transmits it down to another ground station or Earth station. Say this source A is in Thailand and B is in the US somewhere. So we transmit up the satellite down to some other location. How long does it take to get the message from A to B? Well, we try and record the information that we have distance of this link up, 36,000 kilometers. And the data rate of this link, 1 megabit per second. Transmission speed for this link, the speed of light, 3 by 10 to the 8 meters per second. So that's for this first link. In this case, we have a network. We have two links. And we send a message up to the satellite. The satellite then sends a message down. So we need to calculate the delay across both links. And again, the additive, the total delay will be the time to send up to the satellite plus the time for the satellite to send down to B. What's the distance of this link? What's the distance of the second link? It's the same. In reality, there may be slight differences, but 36,000 kilometers about, it may be tens of kilometers different, but it won't make much difference. So we consider the link separately. Distance, same data rate in this example. It doesn't have to be, but just keep it simple. Same speed of transmission in the second link. And in fact, it'll be the same size message because we send the message up to the satellite. The satellite just processes it and sends it down. Let's consider link one that's going up. Remember, we have four components of delay. And think about them for each link. Is there any processing delay at computer A? Question doesn't say it. Let's assume no. Let's assume any processing that happens at A is very small. There may be a processing delay. So I could say that at computer A, there's a processing delay of two milliseconds. But in this case, I haven't said there's a delay. Therefore, we assume it's zero. How long does it take to transmit the data? Well, we can calculate that. Data size, 1,000 bytes, data rate, one megabit per second, 8,000 bits is 8,000 microseconds. So we can calculate the transmission delay for the first link. How long does it take a signal representing one bit to propagate all the way from the Earth to the satellite? Our distance, 36 million meters, divided by our speed of 300 million meters per second. You can use your calculator, 120 microseconds. And queuing delay, in this case, there's no queuing delay. We haven't even mentioned queuing delay. So let's assume it's zero. We'll say something about that at the end. So let's record them. There's zero processing delay. There's a delay of transmission of 8,000 to propagate another 120 microseconds. The packet is received by the satellite. In this question, we say that the satellite takes four milliseconds to process. What have I done wrong? Yeah, the prefix is here is wrong. The propagation delay is 120 milliseconds. I was a factor of 1,000 out. So 8,000 microseconds is 8 milliseconds. Here I've made a common mistake using the wrong prefix. Transmission delay, 8,000 microseconds, or in the red here, 8 milliseconds. Propagation delay, 120 milliseconds, 120 here. So let's record in red the milliseconds as the prefix in unit. The satellite takes four milliseconds to process. So I'll just note here four milliseconds at the satellite. Then the satellite transmits the same packet down. What's the transmission delay does transmit down? It's eight again. It's the same, same data size, same data rate, same transmission delay. Eight to transmit down. Propagation delay, same distance, same speed of light, therefore same propagation delay in this case, another 120. There's no processing delay at B. There's no mention of queuing delay. What's the total delay? Add them up. It's just the summation of all the components. 260 milliseconds. So now we have two links. And the way to consider them is that the delay is additive. We can treat the link separately, determine the delay across each link and then add up to calculate the total delay. Link one, link two. Add them all together and we get the total delay in this case of transmission plus propagation plus the four of processing at the satellite. So always remember delay is additive. Across 10 links you just add up the delay for each link. And even the way that we calculate transmission, transmission, propagation, processing, queuing, we just add them up. Almost out of time for the day. That's the examples we've gone through for calculations. We've seen transmission propagation and a simple example of processing. Again, I will not require you to calculate the processing delay. We don't have enough knowledge in this course to do that. I would maybe give it to you in a question like in this case. The processing delay is X seconds. It's the time it takes the computing device to process the data. What's queuing delay? There's a fourth component we haven't seen in the examples. Queuing delay, the simple concept is the time it takes a message to wait in some queue. Usually waiting for other messages to be processed. And the example I commonly use is we go down to the cafeteria at lunchtime to order food and everyone's gone at lunchtime and you're at the end of the queue. There's 10 people in front of you. The time you spend in the queue waiting to place your order, think of that as the queuing delay, you spend a minute waiting for everyone else to order. So we're in a queue for some time. That's the time we wait for other people to be processed. The same can happen with our packets. Maybe not the best example. But there are other ground stations, C and D. They all transmit up to the satellite at the same time. Three packets. The satellite needs to transmit them down to B. But it can only send one at a time. So three packets arrive at the satellite. It needs to transmit them one after another to B. While the first packet is being sent, the other two are waiting in a queue to be sent at the satellite. So they incur some queuing delay. Then the second packet is sent. So the third one is still waiting in the queue. That's some extra queuing delay. And then it is sent. So queuing delay usually happens at intermediate devices, especially when there's other people trying to send. We'll see that when we go through the structure of the internet, we'll see that queuing delay can be quite significant. For now, queuing delay, the time our data waits in a queue to be transmitted. Again, we don't have the knowledge to calculate that in this course. I would give it to you for a particular question. But again, you just add it up. If I said in this question the queuing delay at the satellite was another 10 milliseconds, then the answer would be 270. If the queuing delay was 10, we just add that onto the total. Let's finish with a quick example. Some of you, when we spoke about online games, one of the measures of online games is ping, or ping is in fact a program that we can use to send a message from one computer to another. So I'm going to send a message from my laptop to the ICT server. And I use the program called ping on my computer. And what it does is my computer sends a message, a short one to the ICT server, and the ICT server sends back a reply. And this program, when it receives a reply, prints the time it takes to get there and back, the ping time, or the round trip time. So the first message, the delay from when I sent it, to get to ICT server, which is in fact downstairs, and come back to my laptop, the first time it took 27.9 milliseconds, this program just keeps sending messages and keeps measuring six, eight milliseconds, 22, it varies in this case. Because this message is going across the wireless network, the access point, down through some cables to the ICT server, and then the ICT server sends a message back. The messages are about 64 bytes. You can't see the six there, 64 bytes. And this is just the delay to get there and back. In our questions, we calculated the delay to get a message just from one point to another. This is giving delay one point to another and back. In the order of milliseconds in this case, we'll see some other examples of delay and how it impacts on our applications through this course. It gives some average, about 14 milliseconds on average, in this case. Let's stop there. We'll continue tomorrow morning and on the next topic of data transmission.


Welcome to the Crimson Engine. My name is Rubidium. Today we are looking at big sources. You might notice that the framing today is wider than usual, taller than usual, and to get that I need a big source. If you've caught any of the Masterclass videos, these have sort of become the gold standard for two camera lighting. You know, Verna Herzog one I'm going to review in a couple of weeks. The Ron Howard one I've watched which is excellent. And if you see the BTS of these, they have a six by six frame with lights coming through it that gives the talent this beautiful big soft source that's either bounced or offset in some other way. Now, there are of course, six by six frames that you can go out and get from people like Matthews. They're incredibly expensive. They're incredibly heavy. They take two people to set up. A lot of people, including myself, have done our own DIY version of these six by sixes with PVC and piping. You get these from Home Depot and sort of bash them together. But the problem is that they are still really large to transport. If you don't build them to collapse, they're still six foot long, so they won't fit in a lot of cars. They come apart when the wind blows or something goes wrong. Even if they fall over, it's very hard to mount them. There's no natural mounting points. The PVC is a lot weaker than any clamp or grip that you put on them. And they really just end up looking terrible if you're in front of a client or just not really working. So Intellitech, whose LC 120 are often used as a key, have got into the frames business. They've introduced these awesome new products called the fast frames, which are collapsible aluminum frames that come in a high quality nylon bag, very minimal assembly. They pop out into a frame the size that you want. This one is a six by 5.6 foot frame. Comes with this diffusion fabric. It also comes, which I've never seen before, this huge egg crate, which lets you take the spill out of such a huge light source and direct it onto your talent without getting it all over the background. If six by five and a half feet is too big for you still, they also sell a five by 3.2 feet version, which is even more convenient, packs up even smaller as you see here. And you actually leave either the silver bounce or the diffusion on the frame as you pack it up. So you don't need to mess around with the Velcro if you know what you want.  Right here I have the 6.56 basically just sitting on the floor. As you can see behind, I have it mounted to the same C-stand as the lights. I have three one by ones here pushing through it. It gives this wonderful diffused focused light on your subject that's big enough for me to stand up in if I had enough room to do that or illuminate two or three or four people all still controlled by one C-stand. So I don't have to, I don't have to have it on different stands and move it around separately. It all works from one stand, all powered out of the wall. And if you crank this up, I can get a really punchy light from it while still being really huge. That is the IntelliTech Fast Frames 6.56 and 5.32 frames here as you see here. I'll do a few more tests with them outside but they're a really great affordable product for a filmmaker on a budget to get a really professional result. Thanks very much for watching guys. Thank you to IntelliTech for the frames. Keep watching for more reviews and I will see you next time.