How do you know when to pick on them and when not, and that seems to me what you're the master of is the timing of when you try and fix something. Well, I try to do it when that cow gives you the opportunity, and it doesn't matter whether it's a fast cow or a slow cow.   So you've got to let that horse feel its way. It's got to figure it out, too. Not every horse can do it the same way. You've got to figure out what they can do best.  And, you know, if it's a fast cow, you've got to just chip away, not pull, you know, you don't have to pull very hard and just let that cow drag you around. If it's a slower cow, or it's out off you, you get more time. You get more time to do it.  If that cow is hitting you hard, you're not going to be able to stop him and running backwards and turn with that cow. If you do, you're going to scare your horse. It's not going to sink in because the horse is not comfortable with it. So it all comes back to whatever that horse is comfortable with. Right, so if it's got to be out off you or if it's got to be slow for it to handle it, some horses that are more mature or do it easier, you can fix them when it's fast, but not all horses.


But an ambulance is what the bombs were said. Convince that we'll resend the accomplishment when pieces are prerogative. Let's get on top of it and on to it. Let's get on top of it and on to it. My name's Abeth, and I'm here at the Meg Perry Center preparing for the Sensory Circus art show, which is going to be opening this first Friday, February 1st. And as the curator of the show, I determined which artists would be in the show, came up with just the general concept, and then once I decided the artists who I wanted to be in the show, I went through the process of trying to make sure they were all just kind of like staying on task and getting stuff done, and I've done a lot of promotion for the show, and then just kind of just organizing everything and getting the show up on the walls, which I had helped with from some of the artists. It's been two months that I've had to put this whole show together from general concept all the way up till the finished product, which is going to be in a couple of days. So yeah, it's been a very intensive process that's gotten more intensive as it's gone along. Thank you, I'm Abeth. This is Aaron. Cool, nice to meet you. To be a curator, it takes having an overall vision and then having kind of the persistence and organization skills and like, I guess social skills and patience to put it together. And once again, having people to help you really, really helps. There's a certain type of art that people come to expect to see on first Fridays, and there's always like new interesting stuff going on, but I don't think that anything like this has really happened before in Portland. So I feel like I have a feeling that people are gonna come in and be kind of scared to touch the art, scared to smell the art, scared to taste the art, because that's something that's, you know, you go into a museum or you go into a normal gallery and people are saying, no, get two feet away from the art. And that's something that I always, when I was younger and just like going to museums and galleries for the first time, I just, I'd always get yelled at for going really close. Like I always wanted to touch stuff so badly. And I remember thinking, when I grow up, I wanna have an art show where people can touch the art and can interact with the art. So I think there's gonna be a lot of me and the other artists walking around, being like, it's okay, you can interact with it. You can completely like let it and develop all your senses and don't be afraid to do that. I want them to leave just being almost like in a state of shock at how overwhelming the show was. And I want them to leave saying, this is like nothing I've ever experienced before. And I want them to need like a week to kind of process everything. And I want them to go away just having to like call people they know or contact people they know to just say, that show is so crazy. So I want it to be very, just a very new experience and something that's just so completely, that's something that feels like people just stepped onto another planet, something just completely different. This is like the most amazing community of artists I've ever experienced. And it's like more than I ever dreamed of being a part of, like I always wanted to kind of find that group of artists that just are super driven and passionate and willing to do stuff and make great things and who are just like wonderful, interesting people. And I feel like the art community in Portland is exactly that and is getting better by the minute.


So, finally it was done and we had a really good time at Ruzcon for the rest of the community. I'm really glad that he's back here in Paikliu and I hope there's more use for you to come back to Paikliu. And just by your brief introduction, Sanu has worked at, where he's been doing Netflix, has she called for, has he, and also contributed or contributed to contribute. And I would sort of guess that he was very passionate about writing about his work and so, as for the people who come in might find papers and there's a book in the Paikliu in which maybe we'll talk about it some point. And I think what needs to be done today is to talk about this paper that's going to get published and I think over to you Vikram, thanks for doing this. Thank you. All right, let's do this. So this is, I've never done this talk before and I hope like it all works out. So usually I do speaker notes and prepare myself and think what I'm going to speak ahead of time but not this time, so we'll see how this goes. So going to be talking about cluster schedulers today and especially like what are the patterns for building cluster schedulers, right? What are the patterns that are important for cluster scheduler developers and for operators when they are evaluating a cluster scheduler, right? The last one or two years, actually more than that, like there has been a lot of movement in the cluster scheduling work. I remember like three years back when I was doing cluster schedulers at Netflix or maybe four years now, when I was doing cluster schedulers for Netflix, Kubernetes just came out, right? And there was, Mesos was like the big dog in the industry. Twitter was using Mesos for a long time and even before Twitter, like those engineers like who wrote Mesos, like they were at Google doing Borg and there has been a lot of movement in the last few years on cluster schedulers in general and like today the conversation is around, okay, like which cluster scheduler should I be using? It's not so much like, okay, should I use the cluster scheduler or not? I think we are past that phase, right? Really the conversation is around, should I use Nomad or should I use Kubernetes or should I use Mesos or should I even use Docker Swarm? And a lot of those conversations that I see happen are around, oh, I use this and this has worked for me and so on and this is what someone else uses and we are in production on this many nodes but the conversation that I feel like we should be having is how does cluster schedulers make your life easy as an operations person or as an operator or like as a service owner, if you're running a service like how does cluster schedulers make your life easy? How does it, what does it bring onto the table, right? So, I want to talk about the first principles of like the problems that you're going to face or problem that anyone is going to face when writing a new cluster scheduler or when running a new cluster scheduler in an organization and through that, we're going to be talking about the patterns that cluster schedulers should incorporate to make you sleep through the night. So the software delivery pipeline, what? Highly available cluster schedulers. Okay, available to applies to that. Yeah, yeah, yeah, and also like by that, it also applies to services. What it means is that if you're running something on a cluster scheduler and if the cluster scheduler is itself not available, there will be like other problems in your infrastructure where like the, where your service might go down because your cluster scheduler is not doing what it's supposed to be doing. And I'll touch on that later, like why that matters. So the typical software delivery pipeline in the last decade look like this, right?  And the deployment automation orchestration like has been like the heart of like the DevOps movement.  We are not manually deploying anything. So the conversations was always about a configuration management, right? What runs on a server? And like how do you deploy software, right? Like that was the biggest problem right in the last decade because people were trying to find it hard to release software. And like most of the tools was around, okay, how do I make a release? How do I make sure like the release that I'm making is consistently getting deployed and putting into production. But deployment in my deployment orchestration and deployment in general, I feel like are only like 10% of the life of a software. You have deployed fine, but then what happens after that? Those, the answers to those problems were not really answered by tools like Chef or Puppet or M Collective and so on, right? Like service management was left to, for example, to supervisors. Like if a service crashed, if a process crashed, you would have something like any D or like system D or something like that or pick your favorite supervisor to like restart your service and so on. Or like it didn't even have runtime hooks with the application, right? If your application is performing poorly, there was no deployment automation tool like which was going to like scale you up. So like obviously like on public cloud, there were like other things like auto scaling groups and so on which had hooks with the runtime via metrics. So the application then like emitted metrics and then like other things came into the picture and then did stuff, right? And also the most important thing was that it had a static view of your cluster and your data center, right? Someone somewhere said that you had this X number of machines and now you would always deploy onto those X number of machines. That means like it always had the idea of like a subset of machines which would never change. Now performance or like your traffic characteristics changes over time, right? And then like it would basically be up to like a human being to understand like how things are changing, how the application is changing and then translate that to like your cluster topology, right? And also when things failed, right?  Like then it was, then like what happens, right? Your application crashes or whatever and then your supervisor tries to bring it up again and then it again crashes. Ultimately, those kind of resolutions, those kind of remediation actions was left to people, right, human beings. And what happens with that is that doesn't scale. The reason why it doesn't scale is that if you have one service, it scales well. You can have five people doing on-call rotation and fix those problems and always have a pager attached to them, right? Now as your organization grows and as you're doing things like microservices and so on, right, like the number of services is going to grow like over time. And the root problem of like having people doing pagers is that you can hire at the rate at which your business grows because the amount of people, the amount of talent you have in the market is going to be not sufficient to like what you would need to continue that practice of like people solving the people doing the remediation actions or people running the remediation actions. And that's where the dynamic cluster scheduling comes into the picture, right? With the dynamic cluster scheduler, what happens is you sort of want software to do the work that people were doing, right? You want your cluster scheduler to be in charge of all the hardware you have. You want your cluster scheduler to understand the services that you have in your, that you need to run in your data center. You want your cluster scheduler to take care of like simpler problems like, okay, there is a node failing. I need to move the service somewhere else. And those kind of things which can be automated, right?  And that's where cluster schedulers come into the picture, right? And as I was saying, service management, like service management needs to understand like the topology of the cluster in a more dynamic manner, right? That's the crux of the problem, right? Like instead of like statically giving feedback to people, you want like software to understand the state of the cluster and do those remediation actions. So what are the things that cluster scheduler should provide, right? Cluster scheduler should provide the self-healing capabilities, right? Like if you want five shards of your application to be running, it needs to make sure that five shards are running. It needs to provide APIs to operators. Like for example, if a machine is failing or like you don't want to run machine services in US East 1A or like a particular zone, because you know there are some problems in that zone, you need the cluster scheduler to give you API so that you can get out of that zone. You can not schedule anymore services on that zone. This is like very important to remember and perhaps I should have had a slide about this, is people think about cluster schedulers providing an API to service owners. The whole work around or the PR around Docker and Kubernetes has been around making developers faster. That's half of the story. The other half of the story I believe is like making operators operate the machines that you have, right? Say for example, you had Heartbleed or like the thing that is going on right now, the KPTI problem that is happening in Linux right now. Say you have like unpatched servers and patch servers. Your service owners doesn't care. They want like X number of shards of their application running, right? But it's up to like the reliability people. It's up to the security people to make sure no services are running on unpatched machines, right? So then your cluster scheduler needs to provide APIs to your operators, to your reliability engineers, right? To drain nodes or to drain clusters and to make sure services are only running on patched machines and so on. The other thing is it needs to, go ahead. The other thing is quality of service guarantees. I'm going to talk about multi-tenants in a little bit, but if you're in a multi-tenant world, right? Cluster scheduler needs to provide the quality of service guarantees where like and service doesn't, should use like the amount of resources that it is supposed to be using. And this is kind of interesting, right? Like all this like, this whole movement around all this stuff started with Docker. We actually like invented things like from the bottom up rather than from going from the top, right? So if for example, if you're using like Kubernetes or like Nomad or anything like that, you would probably be using like some tool like Docker or LXC or something to provide quality of service guarantees. In that case, like the cluster scheduler has to understand when an application is violating the quality of service that has been, that it should, or the resources that it has, it is supposed to be consuming when it consumes more or when it exceeds the quota. So cluster schedulers needs to be aware of the underlying resources and so on. And the last part is that cluster schedulers need to provide APIs to like higher level services like DCOS or Cloud Foundry, right? Cluster schedulers are fairly low level. Your application developers probably need like a higher level API so that, which can understand the concept of a service and the concept of things like racks and so on. Yeah, go ahead. Yeah. Sure. So, for example, there should not be a lot of speakingness of the application on that particular partner. If it has too much data, if it has too much of post dependencies in any form or shape, right? And the second thing is that the application needs to be designed to work with... Sure, just saying, if you have a question, let's talk about that. But if you have a comment, let's do this after the talk. So I think that's an orthogonal question altogether, right? Like if you want to run a database, right? Like if you want to run like whatever, right? Like going to your example, right? You're saying that because, you know, like people did not understand state very well and they had state everywhere and now people are doing like stateless and stateful services, you can run cluster schedulers. I think, I don't think like I would agree with that. I think if you want to run stateful services on a scheduler, you can run stateful services on a scheduler. Provided you have a scheduler which understands state. Provided you have schedulers which understand the concept of a persistent volume. Provided the scheduler understands that the lifecycle of a process and the lifecycle of the persistent volume are decoupled with each other. The fact that we struggle to run stateful services on cluster schedulers today is because the cluster schedulers were not designed for them, right? And as you pointed out, cluster schedulers have existed for the last 40 years, but they have existed in the HPC world, right? In the high performance computing world, there was sun grid engine and so on. I think what catapulted the use of cluster scheduler is that the kind of things that Yahoo or Google was doing in the last two decades, more people are trying to do that. And to do that with like, as I was saying, if you want to not linearly scale as your business grows and as your infrastructure grows with the number of people you have, you have to use something like cluster schedulers. I think the architecture of the services that we run has for sure, to your point, has pushed us towards using cluster schedulers, but I would not 100% agree that it's only because people are doing state and stateful services differently today. Like it's more cluster schedulers are more, what do you call, more approachable, right? If that makes sense. But yeah, let's talk about it more afterwards. So to provide us all these things that we need from cluster schedulers or dynamic service management systems, we have cluster schedulers today, right? Mesos, Kubernetes, Nomad, these are all good. If I didn't include like the logo of your favorite cluster scheduler, that's only because the slide, I had limitations of how big the slide can be, but insert your favorite scheduler here. But schedulers are not the silver bullet, right? That we want them to be, right? Like schedulers fail all the time. I have been on call when I was at Netflix for one and a half year running the scheduler that I wrote. I used to get page like every other day, right? Because something or the other would fail, right? And it's not like, you know, we would fail for the same reason tomorrow. We would fix the reason why we fail today and there would be like some other problem crop up in our infrastructure, which would cause failures. So what remains constant though is like we had to plan for failures. We had to assume that our scheduler is going to fail, right? Say for example, to give you an example, like to the point that you raised earlier was when you talk about highly available scheduler, are you talking about why do you, like are you actually talking about the availability of the schedulers or the availability of the service? I would say that they're related. Say for example, at 7 p.m., you have a video on demand application service and at 7 p.m. is like your peak time, right? People come from work and they want to watch Black Mirror or whatever and you can't have your service go down, right? Now let me throw an example of like a hypothetical failure that and actually like we actually saw it happen. Say for example, your cluster scheduler depends on a data store like ZooKeeper, right? And for some reason ZooKeeper isn't working anymore and now your cluster scheduler has lost the state of like your cluster. And at 7 p.m. when you have peak traffic, you want to auto-scale, you want to have more API servers because you are seeing like more API requests for starting new videos. And what happens when, and also let's say that your API servers are using something like Tomcat which is a threaded server. So now since you can auto-scale because your cluster scheduler is not using, sorry, not working, all of a sudden you will see like more number of users trying to hit the same fixed number of Tomcat API servers that you had. And now most of the threads are going to be busy doing existing requests. And so you will see like high CPU usage and once you see high CPU usage, all your API servers are going to be unresponsive and now you have a failure. So what started as a failure in your cluster scheduler now cascaded into your API. And once that failure has cascaded into API like your service is down pretty much, right? So I think like availability of cluster scheduler or availability of any service that you depend that another service depends on like is the key. Like understanding the relationship is the key. So I'm going to talk about failures in cluster schedulers and their remediation strategies at like three level. The first is like the node levels like where we were going to talk about the failures that happen at the machine level at a node level. And second, failures that happen at the cluster level. And third, failures that happen at the control plane at the schedulers itself. So node level failures, right? Capacity planning. So today like when you're running today when you're running a cluster scheduler like Kubernetes or like Mesos or whatever you are doing, you are not only just running your applications in a container but you are probably running like some kind of logging agent or you're running some kind of sidecar and so on. Most people, they obviously like they put a quota and limitation of resource usages on their containers but they often don't realize that there are some system services as well, right? The system services has to be treated the same way the applications are being treated. They have to be put under C groups. They have to be put under namespaces and so on so that they don't exceed their resource usage. Because once they exceed their resource usage since the scheduler doesn't control them or the scheduler is not imposing like resource constraints on them, they will impact the quality of service of the services running the actual services running, right? So it's very important to measure the quality the overhead of something like a sidecar or like a logging agent or even like your Docker demon, right? If you're using file systems like ZFS understand like how the file system cache works, right? The reason why this is important is today like in C groups V1, the mechanism for controlling IOPS of system read and write is very much broken. So two different containers can run on the same machine and there are very fairly bad ways of like how you can restrict the IOPS. So what it means is that if you for example have a two GB limited the file system cache to two GB and one container is doing a lot of IO it's going to exhaust all your ZFS cache, dark cache. So understand like how your file system caching works and so on. I had an outage back in the day where I didn't limit the ZFS arc size and one fine day I saw like applications are not able to malloc anymore and when I did, when I saw what's happening I saw like ZFS was using like half the memory of all the machine. Even though like it was supposed to not use more than like say one or two gigs that's because I didn't put a constraint there, right? The last is like put garbage collection properties or logic of things like log rotation things like that which understand the what are the units of the underlying resources? You doing log rotation after seven days doesn't mean anything if like the disk is a fixed size. So do log rotation and things like that of say like of the same unit as the underlying resources because seven days of log doesn't say much, right? Your unit at the disk layer is like you're measuring in terms of bytes, number of bytes and not days, right? Oops. Oom killer. The Oom killer in Linux is fairly complex and it's very few people understand how the Oom killer works. Over the time of a process like the kernel keeps score like which is called the Oom score and whenever like the kernel is under stress like it starts randomly killing processes, right? So if for example you have a sidecar which is using all the memory and because of that there is like an Oom situation the kernel might kill like a process which did not cause that. So what I have seen and what we have done in most of our cluster schedulers is we make sure that we can kill process in the user space because when we kill process in the user space using Oom notifications and so on we have a control and we have a deterministic way of knowing like which process we have to kill rather than the kernel deciding like we can the cluster scheduler agent can decide that. This is, this is, this I think like is a key like if you're doing a lot of packing or like if you have a lot of density on a single machine and I think the last thing that I wrote here is that you know like of course put everything under a C group right, a memory C group. This is not my favorite topic and I think this is a topic that people can't do much is that software like Docker are traditionally bad are like traditionally unreliable, right? If you go to like Docker's website because of the pace at which like the project moves like they add a lot of regressions as well. Like I think like six or seven months back you know I had an outage where Docker was leaking the AUFS layers and so on and you know like who would plan for that, right? Like you don't plan for things like that unless like that outage happens. And so we figured out that like like we have to plan for like a failures of like the Docker daemon itself. So it's very important to understand like how the Docker daemon is doing by defining metrics like how much CPU it is using, how much disk it is using, how much disk it is using at the number of actual containers which is running and when something goes south the remediation actions could simply be the scheduler drains that node or like drains that pool of node with that version of Docker, right? And so on. And optimize for like and most importantly like optimize for like cluster level efficiency while at the node like we talk about the number of CPU cores which are available, the number of RAM which is available but people amount of memory which is available people often forget that especially in public cloud that a lot of resources are bound by the network IO because like things like block storage and so on like are actually like on the network, right? Or like if you have if maybe like your network card can you fingerprint the network card and you see that it's like a hundred gig network, right? Like a network card, but the actual link layer might only be like 10 GB or like even less like 5 GB, right? So like expose all the all the properties of the network up to the scheduler as schedulable resource, right? So even if you have like CPU cores which are not being used don't oversubscribe the machine, right? Don't oversubscribe this machine in such a way that the network is saturated. So that like overall your application performs well at the cluster level. As I was saying schedulers provide QoS which is nice when you hear about it or in paper when people make promises that okay I'm going to let you do like, you know have 50 megahertz of like CPU cores, but that's not true. What happens is multi-tenancy in Linux is like horribly broken today. Have you anyone programmed on using SIMD instructions like or AVX 512 instructions on Intel? So these are like vector instructions, right? So what happens with vector instructions is like they need a lot of power, right? And say you are running like non vector instructions which need less power. The Intel what Intel would do is it will reduce the base frequency so that the SIMD instructions or the vector instructions don't consume as much power. As like, say for example, like if your peak CPUs performance is like, say three gigahertz like if you run vector instructions like you'll see like a dropdown to like two gigahertz or something, right? So say for example, you're running like an open SSL or like a heavy crypto library, right? Open SSL or Chacha or something like that which uses vector instructions and then you're running like non vector instructions like normal stuff, right? Like, I don't know, like whatever like something which takes JSON and writes to the database and so on which is like most of the workload today, right? So now you'll see all of a sudden like your normal workload is suffering because like something else is using open SSL which is using vector instructions. So on Linux, unfortunately multi-tenancy is not a solved problem, right? So what you do in that situation is you isolate workloads to like a clusters, right? You tell your scheduler, tag your nodes or tag your clusters to say that run applications which are more IO sensitive in this cluster, run applications which are more which are doing vector instructions on other other clusters and so on. That's like one way of solving it, right? Let's go to cluster level failures. Most often cluster level failures happen because of bad software, period, right? The software doesn't only mean like application software it also means configuration. Go to like the outages of like Amazon, Google or any cloud provider. The last few outages you will see or most of the outages you'll see is because of bad configuration, right? It's because like someone has pushed a bad configuration and now the whole thing is getting impacted. So never ever release software to the entire population or to all the nodes, always do rolling upgrades, see like how the metrics are and make sure like there is a feedback control loop and like the scheduler or like the deployment system understand the metrics that the scheduler is providing. If for example, after doing a new push the scheduler sees a lot of crash, schedulers should like stop deploying, right? And so on. We did something similar in Nomad recently where Nomad uses the state from console and like figures out like whether a cluster is healthy or not. System software failure, as I was saying like deeply scrutinize like the system software that are running on a machine and if for example it doesn't work well anything doesn't work well like just roll back to like an older version. So the most effective way I have done this in the past is by having like really long staging period, right? Like try to run like a very stable version. If you have to like update the version make sure like it's actually running in production on a very smaller percentage of the node for quite some time, see the metrics, compare the metrics and then like make sure like it gets deployed. For security vulnerabilities, you must be thinking like how can I run an older version of the software? I mean most people like who are responsible, responsible software engineers they have a security vulnerability in their code like they would do like some backward, they would back port those patches into like an older version as well. So the staging times of systems of software should be like much larger than say something like an application.  The remediation step could be the cluster scheduler or the orchestration system brings back like more nodes in other zones or in other places. But remember that there are global limits like for example the number of API calls you can make. Or the number of nodes you can even bring up like in a given timeframe. By bringing, by being very aggressive about remediation you could deplete those global resources and even dig yourself in a bigger hole. Control flame plane failures, I think this is the hardest part of like the entire story. That's because it needs a lot of theoretical knowledge, a lot of knowledge about distributed systems. What I mean by control state cluster, control plane failures in general is what happens when there is a failure in the scheduler itself, right? And to understand like failures or to debug or to plan for failures in schedulers, in the control plane of the schedulers, that you have to understand like what is the underlying data source it is using, right? Or what is the scheduling mechanism for example? Like let's take some example, right? Say for example, your cluster scheduler uses zookeeper, right? In the case of Mesos or in the case of Kubernetes it uses HCD and same in Nomad like we use something called raft, right? Which under the hood HCD is also using. All these things are highly consistent, right? Like strongly consistent rather, right? Strongly consistent systems because the reason why they are strongly consistent is because the cluster scheduler wants a view of the cluster topology so that like it doesn't oversubscribe without knowing. It can oversubscribe if it decides that it can oversubscribe. But it doesn't want to oversubscribe just because it is unaware of the cluster state, right? Again like to our earlier conversation about persistent volumes, right? For example, if you're doing persistent volumes and if it's a schedulable resource if you don't use a strongly consistent system you might be asking or you might allow two different process to use the same consistent volumes, right? So if you use something like an AP database, right? Like things don't work well, right? So most cluster schedulers uses a CP data store but in general we want our cluster schedulers to be highly available. So that's the tension, right? From an operator perspective the operator never wants the cluster scheduler to go down. Even if some parts of the cluster scheduler goes down the operator would want as much it can have from the cluster scheduler. So there is like a tension there, right? So what it means is that the schedulers we need to build them in such a way that they can reconcile from data loss, right? What it means, right? For example, you lose Zookeeper or you lose, I don't know, like HCD or whatever, right? Like in your favorite scheduler. Can your scheduler build a state from the running agents that are there in the cluster? In Mesos, it's possible in part. Mesos has something called a task registry where like the framework can send a message and like the scheduler and the agents, the Mesos agents responds back with like the tasks which are running. But then there is no upper limit of like when the cluster is going to reconcile, right? So in Nomad we took a different approach, right? In Nomad we said that if you lose all the scheduler nodes, like there is no way of you can like get back to like a healthy state without rerunning all the job files again, right? So resubmit all your jobs, your cluster state will reconcile. Maybe in the future we'll do like things like backups and all that. But this is a fairly complex topic, right? Reconciling state from failed data from running nodes is like a fairly complex topic. And this is something like I think operators needs to plan for and needs to prepare for basically. The other thing is like the scheduler mechanism itself. Say for example, you have a time limit that I need to be scaling up my services within like say 20 minutes or like 10 minutes at peak. When like traffic hits the roof, I want to get like things as fast as possible. You also have to understand like how is the scheduler working? Is it even driven or is it like level triggered? Level triggered scheduling basically means the scheduler is running in a loop and then it's looking for the tasks which are not running, right? It's basically comparing the goal state and the current state and then it's basically reconciling the cluster state. What it means is that there is some basic like minimum time limit for the scheduler to take an action, right?  He might have thrown like a job, bad job, which has 10,000 units of work, whereas my stuff is more like important. It's like five nodes, five shards of an application. But if the scheduler is working on all the things together, it might have head of line blocking where the scheduler might be spending CPU cycles in scheduling the batch workload. I'm not really working on like the, what is it? The service workload. So in that case, like event-driven schedulers perform much better because in event-driven schedulers, the scheduler is invoked. The moment like a new event happens that event could be like a node going down or someone submitting a job and so on. We did event-driven scheduling in Nomad. If you want to learn more about event-driven scheduling, the Omega paper is good. There is another paper called the pharma man paper which is written by Malte who did the Omega too. He writes like some good stuff about how do you do event-driven scheduling? Mesos is also sort of event-driven scheduling.  Second thing is like implement quotas, right? Bad days are going to happen. Amazon is going to have outage. Your data center is going to have outage. There might be power failures and so on. You are going to have resource crunch for sure, right? Like you are going to have, at some stage, you are going to have resource crunches. When you have resource crunches, when you have resource crunches and when people are contending for resources, quotas are what saves the day. With quotas you can make sure like the business critical services are running and the services like map reduce and so on which can happen much later are like backlogged, right? And in some cases quotas are also useful for the quality of services guarantee on the local agent because based on that, the agents which is actually running the containers can determine like what to prefer when there are problems on the local node itself. So in the end, I want you to take home this message where plan to reboot your data center, plan whichever, no matter which scheduler you are using, which deployment automation you are using, prepare for failure of that software itself and be ready to know like how the organization behaves when the cluster scheduler fails. If your cluster scheduler fails when you don't have to scale out or when there is a period when you don't need to deploy anything or your hardware is not failing, then no one knows what has happened, right? Behind the scenes. But if your cluster scheduler has failed at the same time, when your hardware has failed or like during your peak time, that's when like you need to understand how the organization is behaving, who is calling whom, like what kind of commotion it is happening at like a very large scale, like we see very interesting thing happening when like schedulers fail. Like a lot of people ask the same questions. So instead of like working on solving the problem that has happened on the cluster scheduler, like we are often like talking to our service owners and telling them, informing them what is happening. So like make sure the incident management workflow, the incident management system is capable of like handling such large scale catastrophic failures. So that's pretty much it. And these are some of the papers that I think are good and goes into this topic that we discussed this evening. Yeah, so capacity planning is not something that you do like when something bad has happened, right? Capacity planning has to be done from day one, right? So I think being very conservative is the key, right? Be as conservative as you want to be when it comes to capacity planning. Everything that runs needs to be put under like a micro, like a lens, right? Like don't even consider like any process which is running on the machine to be like, to be like, you know, to be whitelisted because failure like things can go south like from anywhere. So I think like understand like how things are running like at the node level from the very beginning, keep things monitored and then like put reasonable constraints, right? Let's start like start with higher constraints, right? Be conservative and as you understand the software more as you have more experience then like tune them further down. So scheduler, I mean, it depends like, I mean it's a, it depends answer, right? Like are we talking about the scheduler? It depends on the scheduler control plane and the scheduler agent. I've seen people do that as well. I would never run schedulers on, in a container. I would always treat schedulers to be like a system software that is has the right amount of privileges and so on. Something needs to like at the end of the day like the turtle needs to like end somewhere, right? Like scheduler is like the scheduler agent is at that level, right? I would not run that as in a container. What happens when that fails? What happens when Docker has a bug, right? Now because Docker has the most reliable thing at the end of the day is your kernel, right? Is your distro, right? Everything else like everything else is like stacked on top of it, right? If your scheduler also has the same dependency as your application, right? When your application fails and there is a bug in like your container software, like how is your like your scheduler is going to fail at the same time. The when incidents happen, what the best thing that I have seen happen when incident happen is have as little dependencies between incidents, right? Like if something fails and also something else fails which you used to deploy the thing that has failed, like thing, like it doesn't really work well, right? Like in my opinion, and yeah, I mean. I don't want to do what people are doing about like code or like your VST, right? Everything here, something goes but it's always our expectation Yeah, but sure, that works like if you have 100 servers. Now you have like say 50,000 servers or 10,000 servers, like yeah, at scale, like I mean, sure, like if you have 10 servers, yeah, do that, yeah. That is the second value change, like how would you end up? So it depends, I mean, bin packing has been like the primary technique for deploying software but I think, not I think, I know for sure that bin packing is not the only answer, right? For example, like I am implementing right now in Nomad. I mean, it's already running in production. I need to upstream it like a new ranker which basically like spreads applications across horizontally rather than bin pack. For example, some of the problems that you will see is if you're running GPU software which is using GPU, if you do bin packing, what would happen is your data center, part of your data center, you're going to be creating a hotspot. So when you create hotspot in part of your data center, like then the thermal effects will be like really bad and some hardware is going to be like deteriorating faster than like other hardware. So what do you want in that case is like, you want a very uniform thermal outcome, right? Across the data center where things are getting, consuming the same amount of power throughout so that the cooling is more uniform, right? So then like in that case, like you can't do bin packing, right? But there are some cases in which bin packing is better. Like if you have like jobs which can finish, which doesn't have a SLA and they can finish, like whenever they need to finish, right? Like just do bin packing in that case. I think there is a case for both. Yeah. Yeah, so I have always done like node pools, right? I've always done node pools where like, you have certain nodes where we do bin packing in certain nodes where we do like spread, we apply the spread algorithm or anti-affinity where like things are getting spread evenly. Can we choose half? Yeah, absolutely. Yeah, you should. Like these are the things that, this is where the conversation should be. Like when you choose a scheduler or write a new scheduler is that those kind of capabilities which impact, right? The data center performance, not only just application performance has to be incorporated back up into the scheduler, right? Absolutely. I don't have a good answer for that. The, I don't have a silver bullet answer for that, right? Like in the past, as a scheduler developer, I would roll out, I would roll like a new node. So schedulers, like usually with schedulers, right? Like you do rolling deploys, right? Again, like it depends whether we are talking about the scheduler control plane or the scheduler agent. The scheduler agent is easier, right? On the scheduler control plane, like I have always deployed like a single node, observed the metrics, right? And in a lot of cases, I had simulators, right? I had basically like given the scheduler like a static view of the cluster and seen like how the scheduler is performing, right? In some cases I would run benchmarks and so on against the scheduler and see how the scheduler is performing. If I have a change in the ranking algorithm and so on. There are no benchmarks, there are traces though, right? There are publicly available traces. Like I think the Quincy paper like points out to a publicly available trace where like you can have like a trace of your cluster and run your, run your scheduler against it. I mean, of course, like you have to now make sure your scheduler can consume the trace. You know the game's properties, right? Yeah. So I need to meet those traces and kind of fire out. That's what I'm saying, like.  I mean, yeah, the scheduler needs to do that, right? But you can't do that in production, right? Like in production, the only way to like test whether something is working or not is metrics. No, but services are similar to the available, right? Like, I have to tell something a couple of days not yet, but then I'll be like, whatever it is available, you can go Yeah. So we had written one for Mesos, like for our scheduler on top of Mesos. I think someone started work on this for Nomad as well. We can easily write like a simulator for Nomad as well because the scheduler is just a library. So I can like easily, yeah, exactly. So I can write a simulator pretty easily. And I don't contribute to Kubernetes. So I don't know what Kubernetes is. Yeah. So those, I think you can do easily. Like if you have three schedulers, like three different schedulers, like every scheduler team has done a benchmark. So in 2016, I think we did a benchmark in Nomad. We can run a billion containers, not a billion, a million containers under five minutes. And on like, we did it on 15,000 machines. And I think like on Kubernetes, the max you could do like 100 machines or 1,000 machines. Yeah, the scalability of Kubernetes is pretty low compared to like other schedulers. That's because they didn't prioritize that. Whereas like in Nomad, like we, you know, like we, from the get go, like we made sure our performance was like at the peak. I know people run like 100,000 containers like on a daily basis using Nomad. Some finance companies, investment banking companies. Mesa's, I think they have similar benchmarks too. Yeah, absolutely. So Mesa's marathon, again, like a lot of people, like, sure, like, I think like he was saying that you get the benefits of deploying like the new scheduler, right? If you run it on top of a scheduler, I would not do that. I mean, so I think in that case, right, like if you want to have like a fair discussion, right, like about based on just merits and demerits, you can talk about what happens when this marathon goes down, right? You can talk about how does marathon reconcile state, right? They don't want to share this node with another who's not going to be spending money. Sure. Yeah. That's a shortcoming of marathon. Exactly. So what's the right way to deal with these kind of enterprise issues where somebody says these nodes belong to me. Previously, you would allocate just physical servers and say, you know, I give you access to your developers and do the whatever they want. Yeah. But now, you know, finance wants to come and say, no, you have to bring back, you keep coming and asking the server if it belongs. Yeah, absolutely. Yeah. Supposedly the solution. Yeah. But what approach would you suggest? I can tell you like what we did in the past, right? And we did exactly the same thing, right? We had quotas. We implemented quotas. So with quotas, we said that every namespace or every organization gets a fixed amount of quota, right? And within that quota, you have like also like your priorities, right? So say for example, you are like a BU and you have like your quota is like 50, you are paying for 50,000 nodes. So the scheduler understand that quota is present and it will allocate only like 50,000 cores, right? If the scheduler cannot or doesn't have the idea or notion of quota, that's when like the problems that you are saying happens. So if it was up to me, I would not use a scheduler which doesn't understand quotas. So is Nomad, from that perspective, a better choice for multi-usiness? We recently implemented namespaces and with namespaces, we implemented quotas. So I'll let you answer that question as well but to my knowledge, I've done a lot, I've done mesos for a long time. So mesos has the concept of a quota and it has the concept of a role, right? So in the mesos master or you can basically say that this role, the framework which has registered for this role gets this many resources. So one option for you could be, I don't know, I have not kept up with like how mesos has evolved over the years, is run different frameworks, right? Like you can configure the framework name for example and create a role for that framework name and say that this framework with this role gets only this much quota. So then mesos was built to be like multiple frameworks, right? Run each marathon thing as like its own, I don't know if it's possible, but run them as like a scheduler with roles defined. It just seems like, you know, something that is bolted onto it rather than something that should natively be doing for the whole case. What am I looking at? The architecture seems to be not meant for doing something like that. We just figured out this is one way of doing it, but not necessarily the best way. Having highly availability and having 100,000 containers and all is fine, but then if you enter this in somebody else's servers, it's no fun. Check out the concept of like roles in mesos. In mesos master, not in, and you should be able to, I think configure marathon to do that. Marathon has a lot of other problems, I don't know how to go there, but... Is it because you CFS? Yeah, yeah, yeah. I mean, yeah, I have no comments there. On the way you're saying you're in this plaster orchestration platform and you never implemented scaling, you just ran something wherever you wanted it. Right. Yeah. Any other questions? By the way, did I answer your previous question or do we need... That's a longer debate, but there are more dependencies. Yeah. Sure. Sure. Sure. I mean, if you're talking about like how much time it takes to like recover from failure, right? Like at the cluster scheduler level, the way we have done it in the past is always by using chaos, right?  And see like how long it takes to takes it for you to like even bring a scheduler up, right? Or even like understand like what is the queue length of like the number of jobs that has been submitted but hasn't been scheduled yet, right? These are metrics like has that has to be that has to be like observed very closely if you're a scheduler developer or a scheduler operator. In Nomad, like we basically even let people put decide like how many batch schedulers they want to run and how many service schedulers they want to run. Because like it's even driven like say for example, if you have two batch schedulers running and if you have someone doing a lot of bad jobs, obviously like your batch scheduler is going to be like be lagging behind. We even like expose things like timer. Like we just we tell you like if you have this many number of nodes like how many, how much time did like the scheduler spend to make one allocation, right? So obviously like this the scheduler software itself like needs to be monitored and seen like all those things like understand like how the scheduler is performing and then provision resources to the schedulers accordingly, right? Observability is again the key. I mean I I'm not I am pretty sure like there are like more methodological approaches for doing this, but I have always used metrics and used observability to figure out like the amount of resources that has to be provisioned. Yeah. So there are lots of stateful services like database. Yeah. Most of them it is in the case of COS and so it seems that the vendor, the scheduler vendor, they are the ones providing the framework for running HDFS or Kaka and so on. The open source software vendors themselves don't seem to be providing any of these whatever kind of help or the universe package or what is it that runs. So from that perspective which scheduler is popular amongst project owners themselves that they would like to support I just don't see anybody out there doing that. I mean this is a very political question. Yeah. Absolutely. Absolutely. Yeah. Absolutely. Yeah. Absolutely. I it's a very political. The answer to that is like it involves a lot of politics behind the scenes, a lot of handshakes between corporations and people, right? So there is no like logical reason why you like vendor vendors use this like. The stupidest thing I can say is for example it ships a Mongo without authentication. Sure. If you use the app. Yeah. And then Tengen probably does like yeah.  I can talk about it but in let's do talk about it offline. It's a it's a it's more than just like merits and limits. Which one do you think is most likely to be favored by open source projects? Because of the of the of the of various dynamics that are going on right now Kubernetes. Because of the the dynamics of everything that is happening around even though I don't contribute. So like I mean I'm very impartial to this. Yeah. Yeah. Absolutely. There is a paper I I didn't I ran out of time to add this search for Harkillis or something. Or so I can pronounce like Harkillis like it's a Google paper. So if you go to like Google's research publications and see like the the distributed systems column like you'll see like a paper where they use deep learning to figure out which workload to run along with which and they're saving a lot of power. They're improving on performance and so on. Absolutely. This is the future. No one in open source is doing it yet. But you know like it's it's obviously going to come like an open source sometime soon. The the reason I think why no one has done it yet is because the reason like for example like Kubernetes is so popular because people don't need that much scale. Right. If people needed that much scale like people are talking about this stuff that I just talked about for the last half an hour. People don't talk about all this stuff. People are like OK what is my friend using or what is someone X using not for bad reasons but because they don't need a lot of these things right like you would start needing this like if power is your constraint right if you're not constrained by power right if you're not constrained by the number of machines you can add because the government won't give you as much power. Why do you care so much about improving performance right and by improving power consumption. Right. So if you're constrained by power if you're constrained constrained by all other resources I think that's when like you do deep learning and so on and only like very few companies are like doing this stuff. Yeah. Yeah. Sure. Yeah. They're doing a six. Yeah absolutely. Like people are using deep learning like across the board now to reduce improved performance but not at like 10 node scale like there is no use at that scale. Yeah. Maybe not. I think you just I think this is the thing right like there is there is I mean I think this is the thing right like like all the side cars and all this stuff right like these are these are these are failures that are waiting to happen right you need them sure but like at what scale do you need them and why do you need them right like for me I think like if your notion is to keep the business running like you want to sleep well at night like keep your dependencies to the minimum right make sure like you know like how this recovers right instead of like 10 different running 10 different things which fail in 10 different ways right you're just increasing the permutations of the number of ways you are going to fail. And everything is mounted on the LFS. So they are like oh my LFS will never fail and it happened right. So I mean the point is for most people they seem to think that you know using a scheduler suddenly solves infrastructure problems. Unless the underlying infrastructure itself is ID available it doesn't matter what you do you still tend to treat the entire system as an ID available. I mean I would like make a small correction there right the underlying infrastructure is never going to be highly available right like the cluster scheduler has to understand that the topology or the failures that are happening. They don't know that. See the guys who are operating the cluster are very different from the side ops. They don't know that but they seem to think that oh everything is magically working at the back end. But see that knowledge right that knowledge that the data center people have needs to be exposed as a failure domain as labels. The worst ones when it comes to not necessarily our understanding of how infrastructure needs to be managed to run something like resources that we are not very much we are the rack and stand guys. So it's at least here in India I don't know how it's in the west where it's you know public occupation much smarter but here it's when shit hits the fan you cannot port and they are sharing the same switch or so on and so forth. Here a long way out. Yeah and I think this is where like educating people about this first principles are important. Cool thanks everyone. Yeah.


What is going on guys welcome back to the channel critical overload here. So our creeper Mystery witch hunt, whatever you want to call it the hunt for the new creeper actor may be over with this new discovery That I have come across or just new assumption that I've come to I'll just say this new conclusion that I've come to Based off the fact that the cast members that we've already talked about follow this individual on social media So it looks like this actor who I'm about to talk about in a second Could be one of the ones to consider as it relates to playing the creeper in the film There's nothing on his Instagram page that suggests that he's in the movie, but he is followed by Timo I believe Timo also follows him Sydney Craven follows him some other some other people that were involved with the film follow him I believe Gabriel Freilich actually follows him to Gabriel. We know plays Sam Sydney Craven plays Lane, but the actor I'm referring to is an actor named Jiru, I believe is how you pronounce his first name from our pronouncing wrong. I'm sorry Jiru or Jiru Benjamin this individual you see on your screen here He appears to be the most likely person that we're gonna have playing the creeper now The reason I'm saying that is because not only are Not only because of the people that who we know already participating in the film following him in it Indicating that he's in this movie But the other thing is me bringing up these face prosthetics again these face castings that I've shown in these videos More than once I believe but as you see here now your screen after taking a look at him Look at these face prosthetics and these face castings and these face moldings. You cannot tell me that he does not Fit the he does not fit the closest thing to what you see here This looks just like his face or his head shape I'll just say always what they're trying to go for when it relates to the new creeper Now that doesn't mean that he's the only creeper because again I've speculated that there could be many creepers in the film But I feel that what they are trying to do with this whole Jeepers creepers reborn because we see at the end of that second film the creepers basically He needs to regenerate his his strength. He needs to regenerate and grow up his muscle mass again So I've speculated about the film Progressing in a way that has the creeper over time with the victims he consumes He'll start to build up that muscle mass to be more resembling as to what Jonathan Breck looked like in the original two films I'm not gonna even say the original three films. I'm just gonna say the original two but uh I've speculated about that and in Jeru Benjamin He could fill in for how the creeper starts out for his first couple of days in this feeding cycle as he's trying to Regenerate his muscle mass and regenerate all these other things That's of course assuming that if everything goes well with Jeepers creepers 4 Then in Jeepers creepers 5 you get your Jonathan Breck back or you get somebody else back or like I said before Jeru Benjamin just just could just be the creeper through and through and we could have a slimmed a Slimmed persona of the creeper. I'm not opposed to that. I mean they would have to explain why He's why he's not regenerating his muscle mass this time around I don't think that'll be explained It'll just be something that we're supposed to overlook as part of the movie magic this Dispending or suspending our disbelief as it pertains to being consumed that this is how the creeper actually looks now But yeah, Jeru Benjamin if you're the creeper actor Congratulations to you again that face casting has me convinced that face casting everyone following you Indicating that you're in the movie in some capacity. I believe at one point He did have images up on his page Related to Jeepers creepers were born, but he seems to have taken them down to could be mistaken about that, too But I'm pretty confident that Jeru Benjamin if he's not the creeper like the main creeper He's playing one of these interpretations of the creeper made whether that be cosplay or something else, but The most the most likely thing here is that he's playing the creeper Full front and center the main villain of this of this series as we know and these actors that are following him along with Cindy Craven Teemo Following him as well. He's following Teemo like come on There they're all Jeepers creepers reborn actors. I'm not saying they haven't worked on anything in the past I'm just saying it's it's it's seeming more and more likely that Jaru Benjamin whatever his role may be in Jeepers we're born if he has one. It's gonna be for some type of Representation pertaining to the creeper. So I would like to know what you guys think about this down in the comment section This would of course confirm that Jonathan break is not necessarily not back But if they're not taking the route of multiple creepers, then yes, this is confirmation that Jonathan break is not back We won't know anything officially from the studios or from anything Concrete until it's actually stated from Screen media or from someone else, but the way the movie has been Lacking with its marketing. This is all we can do. We all we can do is find these little bitty things and talk about them and Speculate on what we may or may not believe to be true I think that he is going to be the creeper Jaru Benjamin that being I think he will be the one filling in the role of Jonathan Brick can't wait to see what unique spin he'll bring on it again Assuming that he is in fact the creeper can't wait to see the unique spin. He brings to the character Can't wait to see how he brings it to life and I'm just ready to dive back into the world of The creeper rather than be we're in Poho County still or we're somewhere else I'm just ready to see how they make or break this franchise even further Again, I'm not someone who's overly excited for this movie at this point Given how they've handled it and the stuff that we're learned about it It's not to say that the movie will be bad But you know, I don't think there's nothing that's come out that should really get us overly excited at this point in the game We also just sit back Want to see something that's at least decent because it honestly looks like it's gonna be a blend of Hellfest and Jeepers Creepers if we're being honest looks like it'll be a blend of Hellfest if you saw that movie Hellfest mixed with the original Jeepers Creepers movies So we'll see how that all messes well together. The other thing I did want to talk about though was regarding Gina Phillips Gina Phillips if she is in fact in the film They are doing a great job at hiding that I Don't believe she's in it But if she does end up being in the film They've definitely kept that hidden because her participation in the third film wasn't necessarily hidden more so than it was Not confirmed until we all sat down and saw the film So we haven't had any real rumblings about her being on set We did actually see set images of her for Jeepers Creepers 3 So whether or not she's in Jeepers Creepers 4 or not, I don't think she is but I know a lot of us are still hoping that There's a chance she'll be in it. I wouldn't really hold on to that Don't don't hold on to that Just hope this something will happen where she might return in future entries if this fourth of them is a success But let me know what you guys think about this information down in the comment section below Do you think it's true? Do you think this is the new Creeper actor? If you haven't already, make sure you subscribe turn on post notifications I missed a video in the description now have links to all my social media accounts I'm on Facebook, Twitter and Instagram. You can message me there Of course, there's any movies news or reviews you'd like me to cover in the future name with all that in mind Guys, I will see you in the next video


Welcome back to World Hearing Facts. I'm Susanna Love. You ever heard the expression, it was so quiet you could hear a pin drop? Well, as it turns out, a pin drop one meter away is only 15 dB. Today we're headed to the other end of the spectrum where I'll take you on a short journey of unlistensibly loud levels, some of the loudest sounds in the world. Our actual pain threshold for sound is around 130 dB. At 140 to 145, sound exposure is extremely damaging to our hearing, no matter how short of a time we listen to the sound. Our whole body will start to vibrate intensely, making our noses itch and our vision blurry. We'll also start to feel nauseous after a short period of time. At 163 dB, glass might break from the sound pressure alone and a human eardrum can burst. This is also the sound level inside a large airplane jet engine. At 170 dB, we start to talk more about the pressure coming from a sound wave than the actual loudness itself. This pressure becomes extremely damaging for humans, but also causes severe damage to buildings and surroundings. At 190 dB, we start to look towards earthquakes, large thunder strikes, bombs, hurricanes, or volcanic eruptions. The shock waves from the sounds above this level are fatal to humans. If you're wondering about the loudest sound ever recorded, we have to go back to the 1883 Krakatoa volcanic eruption in Indonesia, measuring in at an incredible 310 dB. For reference, it was heard almost 5,000 kilometers away, and the sound was estimated to have traveled around the earth seven times. So that's it for some of the loudest sounds you never want to hear. Thank you for listening.


Maine Coon vs. Quirat Cat. What are the differences between these two cat breeds? A Maine Coon is a big, rugged cat with a smooth, shaggy coat who looks as if they could put in a full-day mousing on a farm in all weather conditions. Indeed, they were built for just such work in the harsh Maine climate, and their breed standard reflects their heritage, calling for a medium-sized to large cat with a well-proportioned body that is muscular and broad-chested. A Maine Coon has substantial, medium-length legs and large, round paws, well-tufted with fur, to serve as snowshoes during winter. A heavy coat is shorter on the shoulders, longer on the stomach and bridges, long fur on the upper hind legs, with a rough in front and a long, furry tail waving a greeting. A medium-width head is slightly longer than it is wide and has a squarish muzzle. Large, well-tufted ears are wide at the base, tapering to a point, and large, expressive eyes are green, gold, greenish gold, or copper. White or bi-colored Maine Coons may have blue or odd eyes. The brown-tabby pattern is so common in this breed that many people don't know Maine Coons can come in any other colors or patterns. They might be surprised to learn that Maine Coons are found in solid colors that include black, red, or white, all-tabby colors and patterns, by color such as blue and white or red and white, and patterns such as tortoise shell and calico. With his silver-tipped blue coat and huge green eyes, as sparkling as the dew drops on a lotus leaf the Corot is one of Thailand's most beautiful exports. He is noted as well for his heart-shaped head, large ears, and alert expression. A Corot's eyes are blue at birth. As he matures, the eyes turn to amber, the pupil surrounded by a fringe of the green. By the time the cat is two to four years old, the eyes have become the brilliant green for which the breed is known.  Unlike some breeds, the coat has its silver-blue color from the time kittens are born, although kittens may have what are known as ghost-tabby markings. These should disappear with maturity. Hello. This video is sponsored by Beemix Pets. Are you looking for high-quality cat collars at an affordable cost? Check out BeemixPets.com. Use coupon code KittenLife to get 20% off. The good-natured and affable Maine Coon adapts well to many lifestyles and personalities. They like being with people and have the habit of following them around, but they aren't needy. They're happy to receive attention when you direct it their way, but if you're busy, they're satisfied to just supervise your doings. Close a door on them and they will wait patiently for you to realize the error of your ways and let them in. They're not typically lapping cats, but they do like to be near you. No rodents will be safe in a home where a Maine Coon resides. Even if you don't have any mice for them to chase, they'll keep their skills sharp by chasing toys and grabbing them with their big paws.  They can climb as well as any cat but usually prefer to stay on ground level. That's where their work is, after all. They're also very smart and will happily learn tricks or play with puzzle toys that challenge their brain. Maine Coons usually enjoy a Kittenish level of play well into adulthood. Males, especially, are prone to silly behavior. Females are more dignified, but they aren't above a good game of chase. Not especially vocal, they make any requests in a soft chirp or trill. The smart and opinionated Corot is possessive of his people. He likes to stay close by and won't desert them for visitors. He gives his heart to one or two people whose company he prefers, or with whom he spends the most time, but he's certainly willing to accept affection from others as well. Be aware of this propensity before you get a Corot, just in case having a cat follow you around all the time would drive you crazy. A Corot is not a loner. He does best with companionship, whether that is someone who works at home or another animal. There's a reason, it seems, that traditionally they were always given in pairs. A Corot who is frequently left alone or ignored may develop behavior problems such as aggression or separation anxiety. That's not to say that adult Corots can't switch their affections. Cats placed in new homes quickly adapt and bond closely with their new family.  It's easy to teach household rules to the Corot if you reward him with petting, a happy good cat or a treat. Limit corrections to a loud no. Or hand clap. If you have multiple cats, be sure you have plenty of toys to go around. The Corot did not learn to share in the kitty garden, and he can be stubborn about giving up toys or other objects that he views as his. Although he can be bold with definite likes and dislikes, the Corot is generally a quiet cat who likes a quiet environment. Although he's not known for being talkative, he is capable of making many different sounds, from a chirp to a scream, when he wants to get his point across. Choose the Corot if you enjoy having a lap cat. He will be pleased to fulfill this desire any time you like. Despite the length of the main coon's coat, it has a silky texture that doesn't matte easily, if you groom it regularly. It is easily cared for with twice-weekly combing to remove dead hair and distribute skin oils. Useful grooming tools include a stainless steel comb for removing tangles and what's called a grooming rake to pull out the dead undercoat, which is what causes tangles when it's not removed. Use it gently, especially in the stomach area and on the tail. Main coons are patient, but they don't like having their hair pulled any more than you do. Check the tail for bits of poop stuck to the fur and clean it off with a baby wipe. They the main coon is needed, which can range from every few weeks to every few months. If their coat feels greasy or their fur looks stringy, they need a bath. The Corot's short single coat requires little grooming. Comb it weekly to remove any dead hairs. A bath is rarely necessary. Brush the teeth to prevent periodontal disease. Daily dental hygiene is best, but weekly brushing is better than nothing. Trim the nails every couple of weeks. Wipe the corners of the eyes with a soft, damp cloth to remove any discharge. Use a separate area of the cloth for each eye so you don't run the risk of spreading any infection. Check the ears weekly. If they look dirty, wipe them out with a cotton ball or soft damp cloth moistened with a 50 to 50 mixture of cider vinegar and warm water. Avoid using cotton swabs, which can damage the interior of the ear. Keep their litter box spotlessly clean. Cats are very particular about bathroom hygiene, and a clean litter box will help to keep the coat clean as well. It's a good idea to keep them as indoor only cats to protect them from diseases spread by other cats, attacks by dogs or coyotes, and the other dangers that face cats who go outdoors, such as being hit by a car. Cats who go outdoors also run the risk of being stolen by someone who would like to have such a beautiful cat without paying for it. The friendly, laid-back Maine Coon is a perfect choice for families with children and cat-friendly dogs. They love the attention they receive from children who treat them politely and with respect, and they don't mind playing dress up or going for a ride in a baby buggy. Carrots will appreciate the attention of a child who treats them respectfully, and they enjoy playing and learning tricks. With proper supervision, they can be a good companion for children. Like many cats that originated in Southeast Asia, carrots tend to prefer other carrots. They can get along with other cats, and with dogs, but they expect to have pride of place. This may or may not go over well with other animals. The Corot likes to have company, however, and if he spends a lot of time with another cat or dog, they will likely become close friends. They're happy to live with cat-friendly dogs, too, thanks to their amiable disposition. Introduce pets slowly and in controlled circumstances to ensure that they learn to get along together. If you enjoyed this video, kindly press the like button. Also don't forget to subscribe with notifications on, so that you don't miss out on videos like this. Thank you for watching.


In the last class we have seen how ISP and non-dimensional thrust depend on efficiency as well as ? B and ? 0 okay in this class we will go further and find out what happens can we get a ramjet which can start below mark number one is that possible or a subs subsonic ramjets are they possible and then we will also look at whether ramjets are self starting we know for sure ramjets are not self starting whether our equations will bring it out is what we are going to see fine and we will also look at what happens to thrust per unit mass flow rate and other things as we go along in this class now if you remember we had derived expression and said that 1 plus ? – 1 by 2 m 4 square must be equal to ? into okay this was the expression that we had derived in the last class now if you put ? is equal to 1 that is ideal case if we look at an ideal case okay what happens here we get this relationship that m 4 must be equal to m 0 does it mean that at the exit mark number is the same as the inlet mark number then it won't produce any thrust is that the case what do you think will happen we are looking at an ideal case and this case exit and inlet mark numbers are the same so do you think it will produce thrust or not produce thrust yeah you are right if you look at mark number mark numbers might be the same what we are interested in us exit velocity and inlet velocity okay so mark number being the same doesn't mean anything because if you know that at the exit of the nozzle temperatures can be 500 to 1000 Kelvin greater than inlet so if you have the flow through the nozzle wherein the temperatures are higher and the speed of sound at that location will be higher and therefore you will be able to still produce thrust if efficiencies are 1 now we derived expression for non-dimensional thrust as okay this was our non-dimensional thrust equation now in this if we put ? is equal to 1 this simplifies to okay so for efficiencies being all 1 unity ideal system you get this expression for non-dimensional thrust and similarly one can get an expression for ISP now if you look at this expression for non-dimensional thrust what you see here is if ? B increases what happens to the non-dimensional thrust ? B remember is under the designers control that is you can choose what is the exit temperature at the exit of the combustor by burning suitable amounts of fuel there is an upper limit that is if you are using if you are using kerosene air there is an upper limit of 2300 Kelvin which is this stoichiometric combustion temperature but other than that you can vary the air fuel ratio and get different temperatures this number is under your control right and one it is very obvious that if you increase ? B you get a larger F by m.a a not now what this value F by m.a not indicates is that you will see as this number is higher the size of the ramjet becomes smaller so larger value of means smaller size of which is desirable because your drag will then be smaller okay so you need a larger value of this and if ? B increases you will find that as a consequence F by m.a a not also increases okay now when we were discussing ramjets earlier in the introductory classes I had made a point that ramjets are not self starting that is they need something to take them to a slightly higher Mach number and then they will start from their own let us see if we can bring that out from this equation if we put m.0 equal to 0 here what happens m.0 is the Mach number at the inlet if we put that to 0 that is if you are holding the vehicle stationary what happens to the thrust this goes to 0 so not self starting or in other words static thrust is 0 so if you put the ramjet on a thrust stand and you do not do you do not give the flow that is you do not induce the flow yourself then it would not be able to produce any thrust even if you switch on the fuel flow rate okay we know now that it does not produce any static thrust is there any value of Mach number at which it will start producing some thrust that is our next exercise we know that static thrust is 0 here let us now find out what happens at what Mach number can we get some meaningful thrust okay now we know that efficiencies if you remember efficiencies will always be less than 1 and when we multiply all of them the product range between product that is ? range between 0.84 and 0.97 right so efficiencies will always be less than 1 so if you incorporate it and try and see what happens at what Mach number will we get some thrust okay to derive that we need to look at this expression here okay this is the expression and we know that if it has to produce positive thrust this number should be greater than 0 right so if it has to be greater than 0 then obviously the product of the first two numbers must be greater than 1 or if you look at the terms in the bracket this should be greater than 1 so we will put that down I will also include the 1 plus f term here the remember we had neglected this term for our convenience okay so for positive thrust 1 plus f should be greater than 1 okay now we can square both sides and cross multiply and we will get this condition that should be greater than ? V okay even though f is smaller here this quantity can be slightly larger therefore I have taken that into account in this equation okay now this is a slightly cumbersome equation to solve and bring out what should be the value of Mach number at which it will give positive thrust so the easier way is you plot a graph and then try and find out where it leads you okay and that is what is done in this plot here what is plotted as non dimensional thrust variation with flight Mach number that is as you increase m0 what happens to f by m.a0 you notice that there are four lines here each corresponding to a different value of efficiency this is for ? is equal to 1 so you have it starting from 0 itself okay whereas all the other lines are clubbed somewhere close to 1 where efficiencies are around 0.86 okay so if you have a non unity efficiency that is for real systems you notice that it is very difficult to have a subsonic ramjet okay whatever be the ? B that you can go up to right ? B is the ratio of combustion exit temperature combustor exit temperature to the inlet temperature even if you add more heat even if you keep on adding more heat it does not matter we bring very ? B from 6 to 10 almost by a factor of 2 even if you add more heat it does not matter you still cannot have something like a subsonic ramjet okay this is purely determined by efficiencies for non unity efficiencies you cannot have subsonic ramjets and what you will notice here is that all these systems have their thrust to or the non dimensional thrust is maximum as somewhere between 2 to 3 okay so it is a maxima for f by a Mach number range of 2 to 3 we need to take this result a little more carefully what we have looked at in this analysis is this is only the thrust produced by the ramjet we have not accounted for the net thrust that is thrust- the drag right there is a drag component also that determines whether the vehicle will move forward or not and that will make it go even further right if you look at this graph in this graph at this Mach number f by m.a0 is this much there will be drag right so that drag will bring down this value and probably you will start producing net thrust somewhere at a slightly higher Mach number right so typically you will not find any subsonic ramjets that is the underlying message from this graph okay when we consider net thrust that is thrust- the drag portion then the starting Mach number will be higher we cannot have subsonic ramjets for efficiencies less than 1 okay now in this graph we see that f by m.a0 varies in this fashion and if I were to look at ISP variation remember ISP by a0 is nothing but m0 into okay now ISP what would be a preferable thing having a larger value of ISP or a smaller value of ISP if you remember SFC we need a smaller value and ISP being 1 over SFC we need a larger value of ISP if you notice here you have ?B appearing here as well as here right in two places in this expression and here it is under root sign and here it is not under root sign okay so what do you expect to happen if ?B increases what happens to ISP ISP should decrease okay and what should happen with efficiencies if efficiencies are less than 1 what should happen to ISPs it should also again decrease and the same thing is plotted here in this graph what you see here is ISP on the y-axis versus Mach number the flight Mach number for an efficiency of 0.86 with different ?Bs as ?B is increased from 6 to 10 you see that the ISPs are lower okay so which means SFCs will be higher or fuel consumption will be more which is not a desirable feature so you would like to operate such that ?B is lower so that your fuel consumption is less but then if you go back to the previous curve you will find that if ?B is less your F by M.AA0 will also decrease or the thrust will also decrease so you should design such that this is a large quantity so that your size becomes smaller okay and then the other thing will automatically get fixed okay now we looked at how the non-dimensional thrust varies with ?B let us look at what happens with M0 we have already seen that in graph let us try and bring out if we can do some analysis and find out what happens with Mach number Mach number if you notice here it appears this is the expression that we are looking for it express it you find Mach number in M0 and ?0 it appears in both places so it is not obvious as ?B is we noted that with the increase in ?B it is this becomes smaller which is what we found in the curves but Mach number is not such a straightforward relationship let us try and find out what happens there that is what we are trying to find out us is there an optimal Mach number at which if we fly it seen that it should lie somewhere between 2 and 3 can we bring that out through some analysis here so what do we do we take a derivative with respect to M0 so firstly we will assume ? to be 1 so that we do not end up with a large or a cumbersome equation so if you look at ? is equal to 1 the expression for F by M0 a0 would be M0 into under root ?B by ?0 minus 1 right so now if we take a derivative of this with respect to M0 let me also include 1 plus F now if we take a derivative we will get 1 into the rest of the things 1 plus F by ?0 minus 1 minus half M0 into 1 plus ?B ?B does not vary with M0 so ?B does not get changed here so ?0 to the power of 3 by 2 into ? minus 1 M0 okay and for a maxima this must be equal to 0 so if we equate this to 0 then both these 2 must be equal we will get 1 plus F this must be equal to 0 under root ?B by ?0 minus half into ? minus 1 M0 square okay what is this quantity here what is the definition of ?0 ?0 is so what you have here is ?0 minus 1 so if you put that you will get 1 plus F ?B minus ?0 into and do the simplification that you will get this ?0 minus 1 divided by this must be equal to 1 or ?B by ?0 into this becomes ?0 minus ?0 plus 1 so ?0 cancels out you get 1 by ?0 is equal to 1 ?0 to the power of 3 by 2 must be equal to okay this is the expression that we get for maximum value of F by M.A0 occurs when ?0 is in this this is the value of ?0 that we have now you plug in some typical values we will find out what we had discovered earlier that it ranges somewhere between 2.52 so if we take TT3 to be 2300 Kelvin which is what you will get as the adiabatic flame temperature if you use kerosene air system at stoichiometric condition and I will take T0 to be 230 Kelvin that is as you go higher in altitude temperature drops so at some particular attitude you will get this temperature and therefore my ?B will be 10 and if I use 7 okay you will find that ?0 you will get as somewhere between 2.25 to 2.15 this depends on what value of F you consider and correspondingly this will also change a little okay and therefore M0 to be somewhere between 2.42 to 0.5 so you will notice that most systems most real systems although all this analysis we have carried out with ? to be 1 even if you put in the efficiencies we have seen in the graphs that Mach number range for high value of F by M.AA not ranges between 2 to 3 which is where you will find most operating systems most systems would want to go to that condition and then fly in that Mach number range so that you have a larger value of F by M.AA not okay this finishes our discussions on ramjets now let us move on to the next engine that is the turbojet okay turbojet has a slightly involved system it has a compressor and a turbine so we need to account for that here okay now when we look at turbojets there are two things that we can look at one is when the nozzle is choked and the other is when the nozzle when the flow through the nozzle is optimally expanded firstly we will consider the case wherein it is the flow through the nozzle is optimally expanded and we will try to find out what derive what equations we will get now turbojet similar to a ramjet will have an intake and then we will have a compressor which is connected to a turbine to have a combustion chamber in between and then you have a jet pipe or an afterburner and then a convergent nozzle okay so let me again call these stations as 1 2 3 4 5 6 and 7 this is the 0 to 2 is the intake 2 to 3 is compressor 3 to 4 is combustor this is the turbine this is the afterburner and then the convergent nozzle as I said earlier we do not use typically CD nozzle the only aircraft or a real system that has a turbojet which uses a convergent divergent nozzle is the what is the engine Olympus engine right on what is that air on quad aircraft okay so other than that typically only a convergent nozzle is used because the pressure at the exit of the turbine is very low and it would not be useful if you have a convergent divergent nozzle and therefore only a convergent nozzle is used now here we will take up the case where P7 is equal to P0 okay that is optimally expanded flow notice here that you have compressor extra and the turbine extra so we need to define certain other parameters that is we will define compressor pressure ratio I will call it by C I see is nothing but Pt3 by Pt2 and T again here indicates stagnation conditions from this we can define Tc that is nothing but Tt3 by Tt2 which is I see to the power of ? – 1 by ? okay and similarly I can define a turbine pressure ratio so from this I can define Tt which is nothing but Tt5 by Tt4 so now with this and we know that from our previous calculation ?0 is nothing but Tt0 by T0 that is 1 plus ? – 1 M0 square fine and based on this I can get M0 is equal to under root 2 by ? – 1 ? 0 – 1 the other parameter that we need to define is ? B in this case I will define ? B is Tt4 by T0 okay so ? B is nothing but Tt4 by T0 which I can rewrite as Tt4 by Tt3 into Tt3 by Tt2 into Tt2 by Tt0 Tt0 by T0 what is Tt4 by Tt3 this I will call it as Tb similar to what we had done earlier I will call this as Tb and Tt3 by Tt2 again we have it here it is ?c and Tc sorry and what is Tt0 Tt2 by Tt0 if we assume isentropic processes this will be 1 this is flow through this is flow through intake and just like in the previous case if the process is isentropic we can get this to be 1 and lastly this is nothing but ? 0 okay so I get my expression for ? B or Tb I can write it as now we want to derive expressions for thrust so the thrust equation is f by f is equal to m dot e into in this case the exit velocity is at v7 okay and intake is at 0 so you get v7 into okay we had assumed p7 is equal to p0 and therefore this goes to 0 and we will also make the other assumption that f is very much less than 1 this is more true in a RAM in a turbojet compared to a ram jet because in the main combustor it will be much lower than 0.067 because you are worried about the turbine inlet temperature so you wanted to be much lower than these stoichiometric condition so f is less than 1 so I can neglect this part and I get f is equal to m dot a v7 minus v0 and we will do the similar procedure as we did last time so I can write this as m dot a a0 m0 into m7 by m0 into under root T7 by T0-1 again we have used the relationship for speed of sound here okay and we have again made the assumption that ? and R are the same for exhaust gases as well as incoming air so assuming ? and R to be same for gases and air okay so we get this relationship now again we need to look at these two ratios okay or we can write the non-dimensional thrust as we can write the expression for non-dimensional thrust as m0 into m7 by m0 so we are again left with the task of trying to find these two ratios again we will follow a similar procedure of cascading temperatures and cascading pressures right now what I want you to think about is all the while I have been telling you that you are looking at flow through intake and I said we are looking at isentropic conditions the previous case that we took up ramjet we looked at all the temperature ratios and efficiency is never figured in that place right why does efficiency only figure when we are looking at pressures and why does not it figure here now in the previous case also we looked at a realistic system right so we cannot look at realistic systems and say the flow through the intake is isentropic so what really is the crux there why are we taking this is one and why do we take the other thing wherein when we look at pressures we are looking at efficiencies here okay we will discuss this in the next class okay thank you very much.