the 32nd lecture in the course Design and Engineering of Computer Systems. In this lecture, we are going to understand a little bit more about how to analyze the performance of your computer system. So what is the workflow in building computer systems that we have seen in the course so far? You will first design and develop your system and you will put all the components together, you will run a load test and you will measure performance. So we have seen what this means in the previous lecture, what do we mean by measuring performance? You will vary certain input parameters, vary the incoming load into your system and you will measure various metrics like throughput, response time, errors, utilizations and so on. Now the next step is you want to understand if the performance is reasonable or if it can be improved. So you have to first look at these performance numbers and you know analyze them and understand them to you know see does this performance make sense, is it justified, is it some bug in my performance measurement or is this how it is supposed to be. So you have to kind of you know do some back of the envelope calculations to convince yourself that this performance measurement is correct. And then once you know that okay this is my performance measurement but I expect lot more load into the system then you will go ahead tune your system and you will repeat this process again. In this lecture we are going to see how you do performance analysis. What performance measurements do we expect from the system? We will use simple back of the envelope calculations. What does this mean? Simple rough calculations that you do on a rough paper to see that okay I am getting 100 requests per second is it correct, is it okay, is it not okay, you know that kind of rough estimates how do you do that on your performance that is what we are going to study in this lecture. And once these estimates match what you are seeing suppose you estimate to get a you know performance of 100 requests per second in your system because each query is taking 10 millisecond but you are seeing only a performance of 10 requests per second, a capacity of 10 requests per second, then you know something is wrong in your measurement setup that you have to fix right. So these back of the envelope calculations are very important to get a rough sense of is your performance measurement correct, is it roughly in the same ballpark range that you expect and so on okay. So in this lecture also once again I would like to clarify that I will only cover the high level concepts and I will try to give you only an intuitive feel for performance analysis but actually doing performance analysis involves a lot of math and notation and theory has to be introduced that we do not have the time for in this course. If you are interested in this you should take a course on you know queuing theory that is the area of computer science that actually studies you know how these queues build up due to performance bottlenecks, what are the throughput response times you get all of those are studied in detail in queuing theory. In this lecture I will not go into a lot of math or you know write scary equations I will just try to explain it in simple intuitive terms which is enough for most cases of doing a performance analysis in real systems. So now let us see what performance numbers we expect in an open loop load test okay let us begin with an open loop load test. Suppose you have a system with a capacity of C requests per second where is this capacity coming from at the bottleneck component the service demand is roughly 1 by C you know roughly every request is taking 10 milliseconds to process at the database therefore your database is able to handle 100 requests per second right we have seen this in the previous lecture. So now to this system with a capacity of C requests per second you send a stream of requests at varying rates you know suppose the rate of requests into the system is R requests per second say you know 10 requests per second, 20 requests per second, 100 requests per second and so on. So this is your open loop load test. Now what is the throughput how will the throughput look like so queuing theory tells us the following not just queuing theory even common sense will tell you this which is you know this is the value of C and this is rate is varying from you know some small value C beyond C and so on. Then the throughput that you will measure will look as follows. Initially the throughput will be equal to R okay if your input load is 10 requests per second your throughput will also be 10 input load is 20 throughput will also be 20. So your throughput will initially be linear will be equal to the offered load incoming load into the system until you reach capacity okay and once you reach capacity as your incoming rate exceeds the capacity your throughput will flatten out. This is intuitive you all understand why this happens right this is the measured throughput. What about the response time? So initially the response time as you vary the load into your system and this is your capacity initially your response time is low because there is no queuing all components are free whatever request comes it is quickly processed right. But for R less than C the response time is low as R approaches C your response time increases exponentially you know your graph will look something like this and as R is much much greater than C your response time almost goes to infinity you know if you have an infinite amount of load coming into your system your response time drastically increases it goes to very very high values and at some point you know queues build up queues overflow requests fail errors crashes all of these will happen. So your response time starts slowly then increases increasing as you reach capacity and as you exceed capacity your response time just rapidly increases okay. And what about the utilization of the bottleneck component utilization also initially if you know your below capacity your utilization will be approximately the incoming load divided by capacity you know utilization if you see on a scale of 0 to 1 initially it will be like proportional to the load and at some point your utilization will reach 100% or will reach if it is fraction it will reach a value of 1. And this will be of course the utilization of some hardware component if your work is mostly on the CPU this will be CPU utilization if your work is mostly on the disk this will be disk utilization whatever is your bottleneck resource that utilization will reach 100% as you reach capacity okay. These are all intuitive your common sense also will tell you this but you can use you know the theory in queuing theory the equations to derive similar values. So when you run an open loop load test this is what you should expect. Now what about closed loop systems you know you have once again let us consider a system with a capacity of C request per second and now in a closed loop system you are varying the number of concurrent users this is how you vary the load you are no longer saying send 10 requests per second into my system you are saying have 10 concurrent users to my system. And what are these concurrent users doing each user is you know sending a request getting a response and then thinking for some time this is called the think time you know this is why this think time this is how real users behave you know if you want to measure the performance of your system with when there are 1000 users connected to it you want to kind of be as close to real user behavior as possible real users are not just doing request request request they send a request you see a web page then you think for some time then you click on something so this think time kind of emulates real users. So the think time is between you get a response you make the next request again that is called your think time. So every user has a certain what is called turn around time of the user that is if I am a user I will what is the gap between my successive request is the time the response time of a system I send a request I get a response time plus my think time. So it takes for example 2 seconds for the system to respond and I will think for another 8 seconds then you know I have sent a request in 2 seconds response comes another 8 seconds to think so 2 plus 8 10 seconds is my turn around time of a user that is the time between successive request from a user will be this turn around time. So these are some of the parameters in a closed loop load test. Now let us see what happens if the number of concurrent users is very small like just like for open loop load test we have seen what happens if you vary the request rate here also let us see what happens for as you vary the number of concurrent users into your system. So suppose you have very low number of concurrent users you have this big system and you have only you know 1 or 2 users concurrently connected to it. Then what happens if there is no think time if each user is quickly, quickly sending request you know response comes again, again, again quickly send a request you are just bombarding with you know no other work in mind you are just continuously loading a system. Then even for a low number of users you can still generate enough load to saturate your system for example a response comes back in 1 millisecond immediately next millisecond I send a request again a response comes back again, again. So you know small number of users can also fully load a system but if you have non-zero think time if you want to be more realistic then what will happen if you have very small number of users then your bottleneck component will not be fully utilized your system will not be at maximum capacity because it could so happen that all these users are thinking you know suppose every user once he gets a response back things for you know 10 seconds before sending the next request. Then what will happen this user has got a response this user has got a response and both these users are now thinking and this system has no work to do you know. So it can so happen that if the number of users is very low all these users have you know gotten a response and are thinking have not yet come back have not yet turned around to the system again then your system will be underutilized will be poorly utilized your throughput will be low. So therefore when you are running a load test with a lot of think time between requests and all of that you need to have good enough value of n you cannot use a very low value of n ok. Now then what happens for large values of n you know if there are a large number of users into the system then your system will be fully utilized you know even if some fraction of those users are thinking there will be other users who are sending request they will all be at different phases right. So one user was sending a request waiting for response the other user is thinking. So once you have large enough number of users somebody or the other will not be thinking and will be making a request into the system. Therefore you will have enough work to fully utilize your bottleneck component and your system throughput. So as you that is why as you increase the value of n once again your system throughput will initially be low for low values of number of users but eventually it will flatten out and it will be your bottleneck will be fully utilized. And what happens to response time? Response time also as you increase the number of users it will be low initially and then it will increase but note that the increase in response time is somewhat linear with n ok. So if you look at response time versus n initially it will be low it will be low and then it will increase somewhat linearly. Why? Because what is your queuing due to your queuing is due to the extra users. Suppose your system has you know 10000 users you know you will have 10000 maximum 10000 users waiting in front of you in the queue and therefore your response time does not blow up the way it does with open loop systems but it is somewhat linear in n it increases somewhat slowly because there are only so many users into the system right you do not have unlimited load coming into the system. You have a finite number of users who can only generate so much load into the system. So with closed loop per system the response time also increases obviously as you increase load response time will always increase but it will increase not so drastically like in open loop systems ok. So basically the summary of all of this is if you have two low values of n you are not loading the system if you have two high values of n your throughput has flattened out and your response time will keep on increasing. Why? Because all of suppose you need only 10 users to keep the bottleneck busy and you have 20 users in your system the other people are just queuing up in front of the bottleneck ok. So the question then comes up what is the optimum number you know is there an n star you know optimum number of concurrent users which will which is just enough to load the system to you know let it reach maximum throughput but without too much queuing you know just enough number of users to fully load the system what is this value of n star you might ask. So let us see how to you know intuitively compute this n star of course there are lot of math and theory behind this but I will just try to try explain it in simple terms ok. So suppose you have a system with a capacity 100 requests per second as we have been seeing so far what does this mean? This means that the bottleneck takes 0.01 seconds to service each request ok. And now suppose the turnaround time of your users in the system is 10 seconds that is the user makes a request gets a response back by before he makes the next request this gap between request is 10 seconds ok. So then what is happening if you look at the bottleneck the bottleneck has you know handled a request for 0.01 seconds from one user then there is a gap of 10 seconds before this user comes once again to the bottleneck and consumes 0.01 seconds at the bottleneck right. So can you all visualize this here is our user 1 he came to the bottleneck the bottleneck serviced his request in 0.01 seconds then the turnaround time is 10 seconds you know the response time plus think time everything is 10 seconds after 10 seconds the user has come back again and the bottleneck is busy for 0.01 seconds again. If there was only one user in the system all of this gap you know this 10 second minus whatever the small value all of this gap is idle for the bottleneck. So how many such users do you need you know to keep this bottleneck fully occupied if each user is consuming 0.01 seconds out of this 10 seconds at the bottleneck you will need this 10 divided by 0.01 right turnaround time divided by service demand the turnaround time divided by service demand if you had that many users then this bottleneck will be fully utilized and your system will be running at full capacity. Can you all see this this bottleneck every user takes a small slice of the bottleneck and that user comes back again after a turnaround time. So how many such small slices do you need this turnaround time divided by the size of the service demand of each user. These many users if you have you know this 10 divided by 0.01 is if you had thousand users then the bottleneck will be doing the work of all of these thousand users before this first user comes back again this will ensure that the bottleneck is fully utilized and you are getting the maximum throughput maximum possible throughput from your system okay. So this is a rough formula to calculate the optimum value of N star in your load test if the number of concurrent users is less than this optimum value your system will be underutilized your throughput will be below the capacity and you are not you know correctly measuring the capacity of your system if the number of users is much more than N star of course your throughput flattens out but your response times will unnecessarily increase right. So if you want to measure at the optimum point what is the throughput and response time of my system you will basically in your load generator you will set this value of N star according to this formula okay. So this intuition about closed systems is actually very powerful you know seeing how to calculate the optimum number of users to keep the bottleneck busy. This intuition is actually very powerful and it can be used in many other scenarios. I will give you a couple of examples okay. So for example let us consider a completely different scenario okay we have seen this concept of a thread pool before there is a master thread and it is giving work it is putting various requests in a queue and there are several worker threads that will take these requests from the queue and service them right. We have seen this example before this design before of a multi-threaded server you know this multi-threaded TCP server it getting many requests from many new clients are connecting to it it will keep all of these requests in a queue and each worker thread will take a client handle the client's request send a response back and so on. So that the main master thread is just focusing on accepting new requests right. So now this worker threads can also block multiple times you know the client has requested something the worker thread will read the you know read the client request then you know do some processing on it then make some disk IO to read the file that the client has requested it will block and then it will once again run on the CPU and send a response back right. So your thread could be doing this it could be waiting for a long time for the client blocking for the client then doing some more work then maybe multiple disk IO's multiple times blocking. So each thread is using the CPU for some time blocking using a CPU for some time blocking.  So then question comes up how many threads do you need in your thread pool to fully utilize your CPU. So this is a very important question when you are building this multi threaded system with thread pools you have to decide what is the size of my thread pool how many threads do I want in my thread pool. So how do you go about deciding this here is the intuition. Suppose each thread performs 0.01 seconds of work on the CPU it does some computation on the CPU and then it waits for a long time one second and then again for the next request it will do you know 0.01 seconds here and then it will wait for one second here ok. So this is how a thread in a thread pool behaves. So note that now can you see you can map this to actually this is the service demand 0.01 seconds is the service demand on the CPU and this one second is simply the turnaround time ok. Thread is working at the bottleneck at the bottleneck resource at the CPU for 0.01 seconds then coming back again after one second 0.01 seconds come back again after one second. So in this scenario one thread of course is not enough to fully keep the CPU core busy why because the CPU core is doing some work for 0.01 second and then for the next one second there is nothing to do. So how many such threads do you need to fully occupy this CPU core the answer is once again turnaround time divided by service demand which is 100 in this case you know which is 1 divided by 0.01 that is 100. So if you had 100 threads each thread is doing work for 0.01 seconds then blocking for one second and so on then these 100 threads together will fully keep your CPU core occupied ok. So we have used the same intuition that we used for deriving the number of concurrent users in a load test we use the same intuition here to derive how many threads do you need to have in a thread pool right this is also a closed system the thread pool is also a closed system. So this analysis is very powerful and every time you have a thread pool you should actually do this analysis each thread is doing so much work and it is waiting so much time for IO therefore how many threads should I have in order to fully utilize my CPU ok. So another example I will give you another scenario where the same thinking can be applied which is in the case of sliding window protocols right. If you remember a few weeks back we have seen networking transport protocols uses sliding window packets right. So they if you just send one packet the packet reaches the receiver receiver will send back an acknowledgement then you send the next packet you are wasting a lot of time waiting for acknowledgements right. So this is your sender this is your receiver and you send data you get an act back and suppose all of this takes a long time then your sender is just sitting idle all your network links are idle while you wait that is not optimum. So such protocols stop and wait protocols are not optimal. So real life transport protocols uses sliding window packets that is you will send a window of packets and then you will wait and then when an act comes back for this first packet you will send the next packet when an act comes back you will send the next packet and so on right. So the question comes up what is the optimum number of packets in a window. If I have too few packets in a window what is happening I am unnecessarily waiting these packets have gone out I have no other work to do and I am still waiting for acts. If I have too many packets what is happening if I just dump you know million packets into the network some queue somewhere will overflow you know at the router at the NIC somewhere the queue will overflow packets will get dropped and TCP will once again reduce its congestion window slow down all sorts of bad things will happen we do not want that right. So what is the question comes up what is the optimum number of packets in the window. So back in the networking part of the course we have seen that the optimum number of packets is the bandwidth delay product. So now we will try and see a reasoning for why is this the answer okay. So in a computer system what is the bottleneck the bottleneck is the slowest link okay if you have multiple links in your computer system each with different rates the slowest link is where the queue will build up okay suppose this link can send 100 packets per second this can send 200 packets per second and this can send only 10 packets per second and this can send you know again 100 packets per second then packets flow quickly but they will build up here at this router they will build up you know at the beginning of this slow link is where they will build up because so many packets are coming but this router is only able to send one packet every one tenth of a second at the rate of you know 10 packets per second you are only able to send so much. So packets will build up here. So if your bandwidth of the bottleneck link is B packets per second each packet is taking 1 by B seconds you know if your bottleneck is bottleneck links rate is 10 packets per second each packet is taking one tenth of a second to be transmitted. So in some sense you can think of this as the service demand okay. So if you look at your bottleneck link it is taking 1 by B time to send a packet then 1 by B time to send the next packet to send the next packet and so on okay and once it transmits a packet this packet will reach the receiver and acknowledgement will come back and the next packet from the sender will come only after RTT okay. So the turnaround time is basically RTT if I the bottleneck link forwards a packet the packet will reach the receiver AC will come back the sender will send the next packet again this entire loop to complete when will this particular you know slot in the window come back again it will come back again after RTT okay. So therefore you have again you can map it to the same it is like a closed loop system you know how many such packets in a window do you need to ensure that while this bottleneck link is waiting for an acknowledgement it is fully utilized how many such packets do you need your turnaround time is RTT divided by your service demand is 1 by B. So this works out to RTT into the bandwidth delay product right. So basically your bandwidth delay product is nothing but the number of concurrent packets you need to have in order to ensure that your bottleneck link is fully utilized if you have fewer packets than this your bottleneck link will have some gaps you know why because all of these packets have been sent yet the RTT time is not done. So the next set of packets from the window have not come your bottleneck link is idle if you send more packets than this what will happen only so much your bottleneck link can forward you know more packets than this they will all be just piling up in the queue at the bottleneck router. So once again the same intuition of closed loop systems is useful to derive the size of a sliding window also okay. So now that we have seen how to estimate you know how many packets will be queued up and all of that let us understand a little bit more on queues also in any system say if you take any open loop system or anything how do you estimate how queues build up you know how many packets or how many requests are queued up at any component how do you go about estimating that. So there is a law in open loop systems which is called the little's law okay which lets us estimate the size of queues between various components okay. So this component is sending some request to this component it is sending some request to this component so between two components at what rate will this queue build up that is specified by the little's law. Note that for closed loop systems is easy you only have you know 100 concurrent users you know the maximum size of this queue can be 100 because there are only so many people who are in the system but with open loop systems you do not know how many requests are there in the system so you use little's law. So little's law tells you that n equals r into w this is a very famous law this is very popular widely applicable no matter what is your traffic arrival characteristics your service demand characteristics distributions it always applies you know it is a very beautiful law and what it says is the number of requests that are in your system either being queued or being served whatever it is the total in your system the total number of requests is equal to the rate at which requests arrive into your system and multiplied by the average time request spend in the system okay if every request spends on an average you know w amount of time in the system and the request arrive at the rate of r into your system then the number of requests in your system at any point of time is r into w right this is very intuitive for example requests arrive at the rate of 100 requests per second you know 100 requests per second are coming in and each request is taking you know 2 seconds in the system okay so over a period of 2 seconds 200 requests have come in and of course by the end of 2 seconds most of these requests start to leave so therefore at any point of time if you see there will be 200 requests you know this 100 into 2 200 requests queued up in your system why because the request that came in this second the request that came in the previous second they are all still being processed you know before that the request came in they would have left anyways by now so therefore this little's law gives you an intuitive way to calculate how many requests do I expect to be lying around in my system and this is used for many things you know if you want to suppose you measure amount of time your system is taking to process request then you can find you can calculate what should be the queue size you know there is a shared buffer between different threads in a pipeline or you know different processes in a pipeline there is a shared buffer what should the size of this buffer be I will see how many requests are coming in how long a request spending in the system therefore I know that there are so many requests at any point of time in the system I will make that my queue size right. So, given the waiting time in the system you can calculate queue size given the queue size you can also estimate the waiting time if this is my queue size and this is the rate of request coming in this is what I expect my waiting time to be and if the waiting time is more than that then you will think why is the waiting time so high. So, this is just a way for you to you know connect up many different metrics in your system and see if they all add up together or not right. So, little's law is very powerful it is very intuitive it is widely applicable in real life if you look around many places you know like people waiting at a counter for tickets or in any queue you know the rate at which people are coming in how long they are spending in the queue you multiply both of them you will roughly be able to estimate how many people are there in the queue right. So, this is a very general formula. So, finally we come to the summary of what all we have seen in this lecture any time you run a load test you have to do some simple back of the envelope calculations to ensure that the results of your load test they are all reasonable and from basic queuing theory this is what you expect your throughput graph should basically increase linearly with increasing load and should flatten out and the utilization of your hardware resource should increase with increasing load and then it should reach 100% at saturation capacity. Your response times will be low initially but they will start to increase as you reach capacity and go beyond capacity. This increases much more rapid for open loop systems and much more you know controllable for closed loop systems and your queues will build up at various components and anytime you see some queue building up between components measure the queue size and see if this queue size can be justified using Little's law and you know if you do not have enough of a buffer space to handle all the expected queuing you should increase your buffer space. So, use Little's law to check all the queue sizes and then use then see if the response time is roughly equal to the processing time plus queuing delays you know you know what the queuing delay should be from Little's law and you know what the processing time should be from your application is the sum of these two equal to response time or is my time getting wasted at some other place that I do not know about all of these things you should check. Then you should check that there are no failures when the system is under capacity when you are operating below capacity all request should be satisfied there is no reason for failures and after overload after you cross the capacity of the system you should see queue building up at the bottleneck component and errors occurring due to this queue build up. If you see errors occurring some other component that is not fully utilized then you cannot say that error is due to overload. So, just because a server crashes does not mean it is due to overload you should see is the crash due to this excessive queue build up at the bottleneck component or not. So, all of these are sort of some of the sanity checks that you can do on your load test results and once you do these sanity checks you can also tweak your system configuration a little bit if you see that something does not make sense. For example, at saturation you will expect that some hardware resource is the bottleneck you know some hardware resource is fully utilized and therefore that is the reason why you cannot do any more work at your bottleneck. For example, if a processing request takes 10 millisecond you know that your database cannot handle more than 100 requests per second and you know expecting it to get a throughput of 200 requests per second is not justified. But if your throughput is flattening your database you know you measure its throughput its throughput is only flattening at 50 requests per second then you know that and the CPU is also not fully utilized then you know that something is wrong you know this is not a correct behavior. This could be happening for many reasons for example you do not have enough threads in your thread pool we have seen this right if there are no enough threads in your thread pool all threads are somehow waiting for IO your CPU idle. In such cases your bottleneck CPU utilization will be low your throughput will be low and that is not the correct capacity you are measuring you should increase the number of threads you should you know increase various buffer sizes you should increase various queue sizes in accordance with little's law we have derived all of these things. So, you should increase all of these system resources such that you are fully utilizing your hardware. If some software resource like max file descriptors or something else is exhausted increase that limit and if threads are waiting for lock C if you can reduce unnecessary locks. So, all of these things are system level changes software changes that you can make so that your system performance can improve. So, you should always make these changes first and ensure that the final bottleneck is some hardware resource. If your CPU is fully utilized or some hardware resource is fully utilized then you can say fine I have extracted the maximum performance possible from my system I cannot do anything more, but if your system performance is low due to you know not having enough threads or not having enough file descriptors then these are trivial issues right you should simply increase that software resource and then your as more threads come in your CPU will be fully utilized. So, that is why use insights from queuing theory to see is my performance numbers making sense or my queue sizes correct or the number of threads in my thread pool correct or the number of file descriptors are there enough file descriptors to handle all the waiting requests in my queue. So, all of these you can somehow connect it up one way or the other to little's law and to ensure that all of these things are sized correctly. So, that at the end some hardware resources fully utilized and your system has reached a performance bottleneck. So, this is all I have for this lecture. In this lecture I have told you quite a few ways of doing a back of the envelope simple calculations estimates to understand your performance measurements to see if they make sense or not and some simple ways to tune some system parameters like threads in a thread pool buffer sizes queue sizes in order to optimize your system performance right. So, as a practical exercise if you have tried out running a load test with a patchy jmeter and a web server you should use some of the techniques we have studied in this lecture for example, to make sense of the performance measurements that you have seen. So, thank you all that is all I have for this lecture we will continue on this topic of performance in the next lecture. Thanks.


Hi, I'm Jonathan Zitron. I teach on law and computer science at Harvard University, and I'm a director of its Berkman Klein Center for Internet and Society. And in this video, I just want to get some terms straight around contact tracing. The World Health Organization defines contact tracing as identifying, assessing, and managing people who've been exposed to a disease to prevent onward transmission. I realize that word managing might sound a little ominous, but really what it's talking about is having people be in a position to know that they are infected and could be contagious, even if they're not yet showing symptoms, so they wouldn't naturally maybe self-isolate. And if it turns out you've tested positive, the ability to know that soon and to be able to find out who you've been in touch with during the window in which you might yourself have been contagious. And once you do that, that contact tracing allows those people that you've been in touch with to themselves be notified that they could be exposed and to let them quarantine so that they're not further exposing others as they wait to see whether in fact they've come down with the illness that you might well have shared with them. Contact tracing in its traditional forms involves interviews. And this also might be why you've seen in the United States news of the standing up of, according to a Johns Hopkins study, up to 100,000 new workers who will be contact tracers working for states, counties, and cities, their health departments doing these sorts of interviews. Now is it necessary to do this? You might be about to find out. If you look at any of the plans for reopening the United States in the spring of 2020, these plans all contemplate testing, tracing, and quarantine as a key pillar. And the White House plan for reopening has as one of its three sets of core state preparedness responsibilities, testing, and tracing. Now the traditional interviews that I was just mentioning, they rely on imperfect human recollection in order to figure out where somebody's been and who they've been in touch with. And those interviews also involve really specialized work and handling sensitive data. And right now, it's hard to scale up all of the contact tracers we would need, able to handle that data sensitively to figure out the right survey instruments and how to offer the kinds of services that they can. And that's why we also now start hearing about digital contact tracing, a subset of case management tools. Case management tools can be something as basic and boring as the software that a contact tracing professional might use to keep track of all the people they're calling, what those people are telling them, who needs to be called next, where the follow-ups are. And there are contracts out by many of the states and municipalities engaging in contact tracing to have that kind of software at hand. There's a second form of digital contact tracing assistance tools that involve possibly using your smart phone in some way in order to be able to say that data that this phone is gathering as you walk around in the world could really help either by some lights, substitute for, and by many others, simply be a helpful input to a compliment to the kind of interviewing that we expect to happen when digital contact tracing happens. And a big question, definitionally here, is to what extent will the data on that phone be used as GPS or geolocation, absolute location data? If the data on the phone can tell you where you have been at various times during the day, during the past few weeks or something, that's the kind of thing that would really help a contact tracer help you jog your memory. Oh yeah, I went to the store on Wednesday, not Thursday. Or, oh, I remember I was on the highway at that time and so anybody I was near, no problem because I was in the car, I was inside, I was outside. These are all things that can affect the transmission of COVID-19 as a disease and it might be material. Now there's a catch because a lot of the contact tracing apps that we've seen made available to people, some of them seek to use geolocation data, others don't. And one reason is because Apple and Google have come up with a framework. A framework that they are wanting apps to be able to tap into on Android phones or iPhones that will use a neat, clever trick to figure out who has been near whom without needing to know where anybody has been. And the parlor trick, the rabbit in the hat, is more or less something called BLE, Bluetooth Low Energy. And this is part of newer iPhones and Android phones that has the phone able to send out a small beacon, a kind of RSSI, a received signal strength indicator from one Bluetooth beacon to another that can say, oh yeah, I've been within 6 feet or 12 feet or something of another beacon, another phone for example, whether or not I know the person who has that phone or whether or not our phones have talked to one another. And the idea is that apps could be written to tap into that Bluetooth Low Energy so that you would know when your phone has been near another or more important, your phone would know. And should you test positive and be able to certify as much to an app on your phone with the assistance of the Public Health Authority, that phone would now be able to send a cascade of notifications out to people meeting that certain threshold for thinking that their phone has been near your phone within a particular period of time. Now the catch is that for privacy reasons, Google and Apple's framework does not contemplate the use of any location data. So it'll tell you that you have been near another phone and tell the owner of that phone without telling you who it is that your phone has been near their phone and they don't get told who you are either. They then have a chance to call their health department and say I think I've been exposed. But no other data other than that proximity is used to do it and the database itself is basically distributed among all the phones. Now that's great from a privacy perspective. It does tend to make for trouble if what you want is the more fulsome data that a contact tracer doing an interview would use to say, oh, I see you've been proximate to this other person, but that's because you're an apartment building and they're on the floor above you or below you. So that's no problem. You're not sharing any air between you and that shouldn't count as a contact. So these are some of the issues we'll see as we look at different app makers looking to make apps that can be helpful in tracing or an exposure notification. They're going to have to choose whether to use the Apple Google framework, which will only do this kind of cool proximity, or if they want to try to kind of freelance it on their own and make apps that might make use of location or other data on the phone, thereby though precluding them from using the special framework that Apple and Google have come up with. There's lots of other issues too, ranging from battery life on the technical side of things. If your phone is trying to figure out where you are all the time, that can lead to a lot of trouble in just using the phone for its normal purposes. And in the broader perspective, it leads to some issues around opt-in and voluntariness. For these sorts of apps to work to be linked to one another, even if the people don't know who one another are, it's going to be important for those apps to be installed on a lot of phones. And right now we're contemplating people going and downloading the right app and doing that. It might be that we need as many as 60 or 70% of the population to be using these apps, and not only that, but to have them installed and running days or a week or two before they're notified that they might be testing positive or have themselves been exposed and then wanting to use the data. Figuring out these sorts of issues, distributed versus centralized databases, the privacy dimensions, and trade-offs around what kind of data gets used and how it gets shared and how labeled it is, and how these apps are or aren't meant to integrate or able to be integrated with the traditional, interview-based, social work-based contact tracing kinds of activities that we see from the public health departments. These will be the subjects of the next video.


yu yu tu yun za huli, bati na uzhikia nalimia inu. We talikia nissu, kwa zime Yuzei kwa kainia medi, yun niime, nii hatia uzimia. Yuzei uzimia, naikuru naikuru, naikuru naikuru naikuru naikuru naikuru, naikuru naikuru naikuru naikuru naikuru naikuru naikuru naikuru naikuru naikuru. Bale, ilikunito, Provincial General Hospital, alafum, nikaguruwa bado ko uko, Mtaingini dikona ito Railways Tukona isi na Grandmother, so Grandmother liko anak Apu Railways Namokoro liko na wakbali na umzaya wakua area So mi nikuwa na nini Mtu tuwa niya anya, liko na ito mtu tuwa niya anya So ukona niya kagro Na Grandmother liko mtu Music Sound liko wana imba church kwaia Na nii ni So mi niki grow up nikuwa na mcheki villi Ile time akenda tizi ya kwaia nikuwa na iya apu Skiza mazen na mizik mazen diyo Indio ile kitu men I joined the school kwaia When I was in class six Lakin ni bada nikuwa chopi Nikuwa chopi, niya na shule Shule ni bada likuwa niya maana Ile time likuwa niya Afro National Provincial School Meningai High School Na iyo meningai skulungu egi akama likuwa mitum chesu So I can say that mizik ini Ini Effective osana He later on released a few songs Enjoying the musical competition that was well known in East Africa and beyond I learnt guitar when I was 18 That's when I learnt how to play the guitar And then Ion ni rhythm guitar I can also play the keyboard La na nikuwa na mcheki villi I have kablai yo Nikuwa kwa proses ya kwi lan kabisa Ni kajoen eno es Kajoen national youth service Kwa gilgil kenu tu kakimbia Ika fuka time nikuwa na Eh, mi misi inu I really wanted to become a soldier Kwa na kanikuwa jeshi ani Tenba gena buna Nikuwa na punta moviza rambu Na chakno orisana Na shozneiga So nikuwa na kanikuwa jeshi amo Soldier ani Ani kengia pali eno es Nikuwa niya zeyo Nikuwa na ambiwa kengia eno es Ni raistisana kengia Jeshi amo tu kengia pali na kachia wo Kirwinei m Nikuwa yeh Nikuwa niiya Nikuwa ka n Box Nikiya yunghere baki meru Nikiya khenya k criminal rendering leaves I thought the same thing Sat in July four years today I expected him to become a K-23 You know Work for them Wa appreciate your growth The experience learnt from the competition played a big role in shaping his musical career Weraapa Was environmentwarвидt selling sickness As he couldn't fulfil his hood We put him straight into a small room We had a brief experience na waku tuwati. Ewi kwa niiha zasak. Tbha kwa héla inuweza kutuwa kwa. Ewi riko uka. Chair yo nila, mainuweza Siriiii. Doi na waku tuwati. Benuwa na kia, kitakita niiwa. Watumahatna waka ma Careful to puhakawa kwa. Nama na kusimia. Kukwa niiwa.  Nyawera was in... Ok, she was in TPF 5, after head to TPF 4. Mi Nyawera, there's this guy, Devika Moko. Saizi ndi o... Amangu jina bigi sana kwa mugi the industry. Nga wegi na kada, we were in the same class in music school. So we formed a band, Nisi Si Band. Na tumiko tu kichapa, we've been together for the last... ... for the last, I think, eight years. Na tumi na chapa jubu mob sana, tu kona songi hindi, na ito abam chikicha. Tu kona songi hindi na piya, na ito house of lungula, tu li fanya... ... kunai movie, ilu kona ito house of lungula. Sindap li fanya yo theme, theme song. Na piya tumiko tu kifanya vitu mob sana, sana sana. Amang the bandmates, Isdoru Nyawera, was also a contestant in Tasker Project Room 5. In 2012, I had like three months to spare in the calendar, right? And I didn't want to go back to Nyaweru. So I'm in Nairobi, and there's auditions for Tasker. I think I've gotten a swing at this thing. They're like, you know what, do it. And then I said, you know, if I go into this thing, then I don't have to go back to the farm. That's cool, right? So I did it. And then to my total surprise, because seriously, I didn't think much was going to come out of it. I go through, and it was like a really amazing experience in terms of like the music, the different cultures exchanged in there, the lessons. It was so much in so little time you take in. And obviously now, for me, that changed like my social standing overnight. You know, I went in there, a campus student just needing three months break. And then I left there, somebody who the whole country knows. It was crazy. And then it was the very first big stage I ever performed at. And right there, I just decided, you know what, this feels nice. I'm going to do this. I feel like I could... Nesisi Band is my chosen family. We've been playing together for... It's going to be a decade soon. A decade. Amazing, right? So when we met, we were... I just left TPF and then hopped onto a project where UNICEF was... ...coming to counties. Every county in Kenya worked with the Kenyan government, trying to make desensitize young people, so we wouldn't have another post-election violence. It was an election, yeah. So we did the tour with the National Youth Talent Academy, whereas most of my bandmates, apart from Juve, it was also on Taskar Project fame. One time at a UNICEF gig, they asked, what's the name of the band? We were like, guys, we graduated from music school. So atwezi se masisi ni talent academy band. So the theme of the event was Nesisi. And it was also about young people. Kamasisi ni nani. The concept was taking the country's reins and giving it to the young people, like a handover event. So we said, Nesisi band. But the band for today's event, and every time that came up in the next week in conversation, it was so funny. Siyo sisi ni nini. Mne zajitwa ni sisi. And then when somebody says you're like, siyo nini ni sisi. It stayed that way and it stuck and we registered it. We were like, you know what, let's keep it. And that's how we ended up being called Nesisi band ever since. We've been a family. Our parents know each other, our partners know each other, our families know each other, we shop for each other, even at home events and things like that. We've become like siblings, which is why I usually like to say how great of a unifier music can be because it gave me a family, a whole second family. So for that I'm so grateful. Those guys are like brothers for me, you know. We've done, I'm sure you know how single Abamchikicha. So at the time when we were writing Abamchikicha, it was the most difficult thing. Imagine a group of eight people trying to write one. Yo, and it's like, so yeah, according to you, the texture of your voice, this is probably where I feel you should come in. No, no, no, no, no. I had much rather finish the song. I had much rather take the bridge. It was like dinner time at home, you know. Just minus the parents, just the kids, you know. And I would say it's been one of my hugest gifts. Jube and his bandmates not only entertain people with their music, but also give back to the society in whichever way they can. We have versatile. Tu kona mziki ya wa zahe, tu kona, we also play mziki ya kina mbogi, isima mbogi, mbogi zote, tu kona country. Okay, me and I do a lot of country music and reggae. Nne kuna mutu manya ana kosetret na mogidi, kuna manya na kosetret na rock, mani ja mani, but to a lot of people sing about their music, I want to do this. Maa kuna sool. Ya ni kikuwa kilamutu akuna strengthen ake. So muna pata kani. Me nimi tuwezu maa kuntri na mogidi na rumba na. Ha, kuntri rumba na sool. Na ma klasiko. Kuna mutu manya na kosetret na rock, mani ja mani ni. Netimle yнende za skizuw n Dear Qilam, kwa yente tn faekidence mb 3 nga 7 ze dago hana démiki inti qstellung me markexhales karma🍜 ShibuNzougu Wazaaiwa, Shiza Gitar produceancesnabu na pier ku ya na aúnى ni shiki, w ninee ni kukele Badan mga brada zetu, mga sita zetu. Nga wakiawa pali nani piyatu kenda pali na patiya moral. As a band, we have a provision for music training. We got free training as well. We were kids once, people took a chance on us. So once in a while we also, when we can, we also take a chance. We've worked with guys like the Brookhouse school. So one of the task of the famed judges is the teacher there of music. So we've worked with his school and been like the motivation and peer judges for his students. It's always so lovely and we also have projects where we do, where we, let me just mention one. We have an organization we always partner with, it's called LASH. Primarily they deal with mentally challenged adults. Yeah, but it's part of a peak umbrella where now we have a specific section that deals with people that have been affected and or often by HIV. And then we have another one where it's the one that's called Efferta now, the one we mostly deal with. It's the one that deals with grownups that are mentally challenged.   And one of the most important things we do is make sure we see or we win off the ones with musical talent.


In the continuation of the previous module about the sterilization kinetics, we have one Arrhenius equation. So, if we combine that Arrhenius equation with the equation which we achieved by the integration of that equation. So, you can see here. So, we have in that module this equation ln of n t over n naught is equal to minus k t and k is equal to a is Arrhenius constant e powered by e over r t. So, if we combine these two equation then we have this equation. So, if we put just the value of k this value then we have this kind of the equation. So, by you can easily see that a dot e and then this is the. So, according to the D endoropher and Humphrey 1959 they use the term for ln naught over n t as design the criteria for the sterilization. So, that factor they called sometime they called as the del factor or nubbler factor or sterilization criteria. So, represented in this del factor or nubbler factors or a sterilization criteria by this sign. So, this sign is commonly known as del factor nubbler factor or sterilization criteria. So, we will use in later slides as a del factor. So, the del factor is the measure of the fraction reduction in the viable organism counted here we can say that count produced by the certain heat and the time regime. So, then the del factor if we say that del factor is equal to the this one then our del factor is equal to ln is into n naught over n t. So, this is basically show the fraction reduction in the viable organism with respect to the heat and the time of heat treatment. So, as we have this equation l and then we have this k t is equal to a dot t over this then the delta factor is this one. So, on rearranging the above equations then the equation will be l and t is equal to e over r t plus ln del factor over a that is known as Arrhenius constant. So, the plot of the natural logarithm of the time required to achieve a certain del factor value against the reciprocal of the absolute temperature that will yield a straight line. So, the slope of which is dependent on the activation energy you can see this whole relationship in this slide. So, when we draw the graph between the log of nature of the time with the temperature which we called as absolute temperature. So, then we can see from this figure. So, the degree of sterilization which we called as the del factor obtained over a wide range of the time. So, if we have a different time pattern then we can say we have a 2.3, 4.6, 23 and 69.6 these are the different del factors with respect to different temperature. So, this graph actually show the effect of sterilization and the temperature on del factor achieved during the process. The kinetic description of the bacterial death enables the design of the procedures that given to the certain del factors. So, by this way by choosing the value of n t then the procedure may be designed having a certain probability of achieving the sterility based upon the degree of risk. So, that whole degree of sterilization and the degree of risk that totally depend upon the del factors. So, in later module we will discuss this del factor in detail.