1 00:00:00,040 --> 00:00:02,460 The following content is provided under a Creative 2 00:00:02,460 --> 00:00:03,870 Commons license. 3 00:00:03,870 --> 00:00:06,910 Your support will help MIT OpenCourseWare continue to 4 00:00:06,910 --> 00:00:10,560 offer high-quality educational resources for free. 5 00:00:10,560 --> 00:00:13,460 To make a donation or view additional materials from 6 00:00:13,460 --> 00:00:19,290 hundreds of MIT courses, visit MIT OpenCourseWare at 7 00:00:19,290 --> 00:00:21,790 ocw.mit.edu. 8 00:00:21,790 --> 00:00:23,040 PROFESSOR: Good morning, everybody. 9 00:00:25,070 --> 00:00:27,390 We're on the home stretch here. 10 00:00:27,390 --> 00:00:31,130 Only two more lectures, no more recitations, and a small 11 00:00:31,130 --> 00:00:32,734 matter of a final exam. 12 00:00:35,750 --> 00:00:38,590 I should remind you the final exam is on 13 00:00:38,590 --> 00:00:40,550 Monday of finals week. 14 00:00:40,550 --> 00:00:46,380 And it will be a two-hour exam, not a three-hour exam. 15 00:00:46,380 --> 00:00:51,270 Same kind of format as on the first two quizzes. 16 00:00:51,270 --> 00:00:53,400 Open book, open notes. 17 00:00:53,400 --> 00:00:56,850 The difference is that we'll be giving you some code, which 18 00:00:56,850 --> 00:01:01,450 we'll be posting today, which we're going to ask you to 19 00:01:01,450 --> 00:01:05,580 study in preparation for the exam. 20 00:01:05,580 --> 00:01:09,100 And then we'll ask you some questions about that code. 21 00:01:09,100 --> 00:01:12,410 For example, ask you to make a small modification 22 00:01:12,410 --> 00:01:15,060 to it on the exam. 23 00:01:15,060 --> 00:01:18,920 And in fact, today's lecture, just as a special incentive to 24 00:01:18,920 --> 00:01:22,890 pay attention, will be about things related to the code 25 00:01:22,890 --> 00:01:27,280 we'll be posting for you to study for the exam. 26 00:01:27,280 --> 00:01:31,200 It covers one final class of simulation that we haven't 27 00:01:31,200 --> 00:01:34,860 looked at at all this term, but I think is important to at 28 00:01:34,860 --> 00:01:37,810 least know a little bit about it. 29 00:01:37,810 --> 00:01:39,630 And those are queueing network simulations. 30 00:01:54,380 --> 00:01:59,170 From the time of conception until death, human beings find 31 00:01:59,170 --> 00:02:02,570 themselves all too often waiting for things-- 32 00:02:02,570 --> 00:02:06,000 waiting for events, waiting for conditions, waiting for 33 00:02:06,000 --> 00:02:08,870 TAs, et cetera. 34 00:02:08,870 --> 00:02:14,690 Queuing networks give us a formal way to study systems in 35 00:02:14,690 --> 00:02:18,440 which waiting plays a fundamental role. 36 00:02:18,440 --> 00:02:22,350 Some typical examples might be in a supermarket, 37 00:02:22,350 --> 00:02:23,640 waiting to check out. 38 00:02:23,640 --> 00:02:27,290 You get in a queue, wait your turn. 39 00:02:27,290 --> 00:02:30,450 Computers all the time -- 40 00:02:30,450 --> 00:02:33,370 you may wonder sometimes why when you hit your computer, 41 00:02:33,370 --> 00:02:36,110 and ask it to do something, sometimes it's fast, 42 00:02:36,110 --> 00:02:37,920 sometimes it's slow. 43 00:02:37,920 --> 00:02:39,960 Well, it's because there are tasks running in the 44 00:02:39,960 --> 00:02:43,320 background that are ahead of your task in the queue, and 45 00:02:43,320 --> 00:02:46,170 you're waiting for them to finish. 46 00:02:46,170 --> 00:02:50,980 Computer networks, waiting for arrivals and things like that. 47 00:02:50,980 --> 00:02:54,700 If you look at the internal structure of the internet, as, 48 00:02:54,700 --> 00:02:59,070 say, an email hops from hither to yon between two sites, 49 00:02:59,070 --> 00:03:02,230 along the way, it enters queues and waits for its turn 50 00:03:02,230 --> 00:03:04,205 to get forwarded to the next hop. 51 00:03:06,750 --> 00:03:09,640 A few of you have experienced this when you go to office 52 00:03:09,640 --> 00:03:12,150 hours, where there's a wait for a TA, and 53 00:03:12,150 --> 00:03:15,470 you get in a queue. 54 00:03:15,470 --> 00:03:19,890 Public transit, analysis of highway systems. 55 00:03:19,890 --> 00:03:24,700 All of these things depend upon understanding queues to 56 00:03:24,700 --> 00:03:25,950 understand how they work. 57 00:03:29,800 --> 00:03:32,560 You might wonder why we have queues. 58 00:03:32,560 --> 00:03:37,250 The answer is pretty simple, in that it typically makes 59 00:03:37,250 --> 00:03:38,500 economic sense. 60 00:03:43,530 --> 00:03:48,950 As we'll see in our analysis, when resources are limited-- 61 00:03:48,950 --> 00:03:51,280 particularly, say, servers-- 62 00:03:51,280 --> 00:03:57,300 it makes economic sense to have jobs line up for service. 63 00:03:57,300 --> 00:04:00,420 So if you think about a supermarket, ideally, when you 64 00:04:00,420 --> 00:04:03,160 go to check out, you'd like there to be no line. 65 00:04:03,160 --> 00:04:07,750 But think about how many cash registers they would need to 66 00:04:07,750 --> 00:04:10,320 ensure that all the time when someone was ready, 67 00:04:10,320 --> 00:04:12,390 there was no line. 68 00:04:12,390 --> 00:04:14,610 And the problem is if they did that, they 69 00:04:14,610 --> 00:04:16,959 would have idle servers. 70 00:04:16,959 --> 00:04:21,019 And so they would not get very good resource utilization of 71 00:04:21,019 --> 00:04:25,390 the people they would be hiring to do the checkout. 72 00:04:25,390 --> 00:04:28,120 In designing a system with queues-- 73 00:04:28,120 --> 00:04:31,530 and that's what the simulations help us do-- 74 00:04:31,530 --> 00:04:43,630 we're aiming for a balance between, essentially, customer 75 00:04:43,630 --> 00:04:50,920 service and resource utilization. 76 00:05:02,630 --> 00:05:06,680 The organization paying for the resources would like them 77 00:05:06,680 --> 00:05:10,440 to be working a 100% of the time at full capacity, so 78 00:05:10,440 --> 00:05:13,090 there's no wasted expense. 79 00:05:13,090 --> 00:05:15,820 On the other hand, it's easy to show in any reasonable 80 00:05:15,820 --> 00:05:20,650 system that if you have a 100% resource utilization, you're 81 00:05:20,650 --> 00:05:23,810 going to be providing terrible customer service. 82 00:05:23,810 --> 00:05:28,320 There is always a need for excess capacity in a complex 83 00:05:28,320 --> 00:05:30,680 system in order to provide adequate 84 00:05:30,680 --> 00:05:33,040 service most of the time. 85 00:05:33,040 --> 00:05:36,200 And that's because, as we'll see, the demand for service is 86 00:05:36,200 --> 00:05:38,140 probabilistic and unpredictable. 87 00:05:40,850 --> 00:05:46,890 And in order to absorb bursts of activity, you need excess 88 00:05:46,890 --> 00:05:50,120 capacity, because a lot of the time, you 89 00:05:50,120 --> 00:05:52,780 don't see those bursts. 90 00:05:52,780 --> 00:05:54,140 All right. 91 00:05:54,140 --> 00:05:57,600 All that by way of introduction. 92 00:05:57,600 --> 00:06:02,320 If we think about how to model a system with queues, they're 93 00:06:02,320 --> 00:06:06,510 are all modeled essentially the same way. 94 00:06:06,510 --> 00:06:13,320 You start with some jobs, work to be done. 95 00:06:13,320 --> 00:06:14,990 Those jobs enter a queue. 96 00:06:23,230 --> 00:06:26,220 They wait around for a while. 97 00:06:26,220 --> 00:06:31,020 They leave the queue one at a time and enter a server. 98 00:06:34,100 --> 00:06:35,350 And then they depart. 99 00:06:40,720 --> 00:06:42,090 So that's what it looks like. 100 00:06:42,090 --> 00:06:45,740 And of course, it can be much more complicated than this. 101 00:06:45,740 --> 00:06:48,210 You can have multiple streams of jobs. 102 00:06:48,210 --> 00:06:49,370 You can have multiple queues. 103 00:06:49,370 --> 00:06:51,910 You can have multiple servers. 104 00:06:51,910 --> 00:06:54,720 But when we build an analysis of it, when we build a 105 00:06:54,720 --> 00:06:58,610 simulation, we typically break it down into components that 106 00:06:58,610 --> 00:07:03,790 look exactly like this and use that as the key. 107 00:07:03,790 --> 00:07:07,430 As we do this, we have to look at a number 108 00:07:07,430 --> 00:07:08,680 of different things. 109 00:07:11,370 --> 00:07:13,365 We start with the arrival process. 110 00:07:18,980 --> 00:07:22,500 How do the jobs appear? 111 00:07:22,500 --> 00:07:25,370 And there are lots of questions we can ask. 112 00:07:25,370 --> 00:07:29,440 Do they arrive singly, or in groups? 113 00:07:29,440 --> 00:07:33,635 If they arrive in groups, we say that it's a batch process. 114 00:07:36,160 --> 00:07:40,780 So if you think about a service for, say, processing 115 00:07:40,780 --> 00:07:44,290 students at MIT into the database, they typically 116 00:07:44,290 --> 00:07:47,770 arrive in a big batch in September, rather than 117 00:07:47,770 --> 00:07:49,280 straggling in one at a time. 118 00:07:52,490 --> 00:07:58,910 We have to ask, related to that, is how arrivals are 119 00:07:58,910 --> 00:08:01,235 distributed in time. 120 00:08:04,300 --> 00:08:07,950 Assume for the moment that arrivals are one at a time-- 121 00:08:07,950 --> 00:08:11,390 for example, automobiles entering a highway. 122 00:08:14,910 --> 00:08:20,240 Do they come uniformly, at evenly-spaced intervals? 123 00:08:20,240 --> 00:08:22,660 Do they come at random times? 124 00:08:22,660 --> 00:08:27,160 If random, is there a time of day when we see most of them? 125 00:08:27,160 --> 00:08:32,700 We typically model all of that in what's called an 126 00:08:32,700 --> 00:08:38,159 inter-arrival time distribution. 127 00:08:50,940 --> 00:08:55,480 The simplest process is where these things do arrive at 128 00:08:55,480 --> 00:08:59,120 regular intervals, constant intervals. 129 00:08:59,120 --> 00:09:03,490 We hardly ever see this in the real world. 130 00:09:03,490 --> 00:09:09,270 Most of the time, we see something that looks much like 131 00:09:09,270 --> 00:09:11,450 our old friend, the Poisson process. 132 00:09:21,110 --> 00:09:24,550 Things arrive at a random interval. 133 00:09:24,550 --> 00:09:28,505 But they are typically exponentially distributed. 134 00:09:31,270 --> 00:09:32,520 We've seen this before. 135 00:09:37,690 --> 00:09:37,775 Ok. 136 00:09:37,775 --> 00:09:40,530 It is, as you will recall, memoryless. 137 00:09:40,530 --> 00:09:43,220 It is, as you will recall, described by a single 138 00:09:43,220 --> 00:09:46,640 parameter, the average arrival rate. 139 00:09:49,260 --> 00:09:58,310 We can look at it just briefly to see what it looks like, 140 00:09:58,310 --> 00:10:00,175 just to remind ourselves, really. 141 00:10:05,220 --> 00:10:08,500 So I've just a small piece of code, where I've given the 142 00:10:08,500 --> 00:10:10,440 mean arrival. 143 00:10:10,440 --> 00:10:14,690 And then I'm going to just have 2000 things arrive at 144 00:10:14,690 --> 00:10:15,970 Poisson intervals. 145 00:10:37,255 --> 00:10:38,505 Why is it not running? 146 00:10:41,830 --> 00:10:45,330 I cleverly rebooted before I got here, so it shouldn't have 147 00:10:45,330 --> 00:10:47,410 had any problem. 148 00:10:47,410 --> 00:10:50,070 There it is. 149 00:10:50,070 --> 00:10:54,220 All right, so that really should be-- 150 00:10:54,220 --> 00:10:55,585 anyone remember what this calls? 151 00:10:58,800 --> 00:11:00,050 Right. 152 00:11:04,990 --> 00:11:14,780 And so we'll see that we have exponential arrival times, a 153 00:11:14,780 --> 00:11:19,380 rapid decay, only a small tail out at the right in this 154 00:11:19,380 --> 00:11:22,940 picture, and a big cluster near the mean. 155 00:11:22,940 --> 00:11:25,440 We can look at this in a different way if you look at 156 00:11:25,440 --> 00:11:27,500 the scatterplot. 157 00:11:27,500 --> 00:11:31,040 And you'll notice that we've given it a mean of 60, the 158 00:11:31,040 --> 00:11:33,910 dark blue line. 159 00:11:33,910 --> 00:11:38,910 But we seem to have an awful lot of points below the mean 160 00:11:38,910 --> 00:11:41,900 compared to a very much smaller number of 161 00:11:41,900 --> 00:11:44,830 points above the mean. 162 00:11:44,830 --> 00:11:51,055 Why is that, in fact, inevitable in this situation? 163 00:11:53,970 --> 00:11:55,220 Yeah? 164 00:11:57,310 --> 00:12:00,280 AUDIENCE: Because there's less space for them to-- 165 00:12:00,280 --> 00:12:00,775 PROFESSOR: Because? 166 00:12:00,775 --> 00:12:02,260 AUDIENCE: There's just less space for them. 167 00:12:02,260 --> 00:12:03,250 We can go from 60-- 168 00:12:03,250 --> 00:12:05,230 PROFESSOR: Well, there's less space. 169 00:12:05,230 --> 00:12:09,890 And the reason that there's less space is we don't allow 170 00:12:09,890 --> 00:12:13,860 things to arrive yesterday, in negative time. 171 00:12:13,860 --> 00:12:17,130 So the smallest inter-arrival time is just 172 00:12:17,130 --> 00:12:19,750 epsilon more than 0. 173 00:12:19,750 --> 00:12:24,490 So the time between jobs can never be less than 0. 174 00:12:24,490 --> 00:12:27,320 And so if we want-- 175 00:12:27,320 --> 00:12:30,600 and we're going to have a few way out here that take a lot 176 00:12:30,600 --> 00:12:35,070 longer, because that's the nature of an exponential. 177 00:12:35,070 --> 00:12:37,380 So we're going to have to have a bunch down here to 178 00:12:37,380 --> 00:12:40,860 counterbalance the few way up here. 179 00:12:40,860 --> 00:12:45,040 We can only get 60 below the mean, in this case. 180 00:12:45,040 --> 00:12:50,700 And you can see we here have over 500 above the mean. 181 00:12:50,700 --> 00:12:56,160 So it's going to always look like that, which is why the 182 00:12:56,160 --> 00:12:59,540 histogram looks something like this. 183 00:12:59,540 --> 00:13:03,050 So you'll observe that as you look at these things. 184 00:13:03,050 --> 00:13:04,930 All right, that's the arrival process. 185 00:13:09,440 --> 00:13:15,130 We also have to look at the service mechanism. 186 00:13:15,130 --> 00:13:16,380 How does the server work? 187 00:13:22,950 --> 00:13:30,050 Again, we can ask some question like, how long will 188 00:13:30,050 --> 00:13:35,420 it take to provide service? 189 00:13:35,420 --> 00:13:37,575 And this is called the service time distribution. 190 00:13:48,030 --> 00:13:50,790 This depends on two things-- 191 00:13:50,790 --> 00:13:54,850 the amount of work the job to be served entails, and the 192 00:13:54,850 --> 00:13:56,100 speed of the server. 193 00:13:58,380 --> 00:14:00,630 So, again, you've experienced this, no doubt, at the 194 00:14:00,630 --> 00:14:03,750 supermarket, where if you get in the wrong line, where 195 00:14:03,750 --> 00:14:07,460 there's a very slow person running the cash register, 196 00:14:07,460 --> 00:14:09,820 even though the jobs are small, it takes forever, 197 00:14:09,820 --> 00:14:12,480 because there's a slow server. 198 00:14:12,480 --> 00:14:14,830 Or alternatively, you've gotten behind a line, not 199 00:14:14,830 --> 00:14:17,280 noticing that the person in front of you has two shopping 200 00:14:17,280 --> 00:14:19,430 carts full of junk. 201 00:14:19,430 --> 00:14:22,070 And so even though the server is fast, it'll take a long 202 00:14:22,070 --> 00:14:25,690 time to service that job. 203 00:14:25,690 --> 00:14:28,595 The number of servers certainly matters. 204 00:14:33,470 --> 00:14:38,300 An important question is the number of queues. 205 00:14:42,480 --> 00:14:47,000 In particular, does each server have its own queue, 206 00:14:47,000 --> 00:14:49,810 which is what you see at the supermarket? 207 00:14:49,810 --> 00:14:54,980 Or is there a single queue for many servers, typically what 208 00:14:54,980 --> 00:14:58,000 you see if you are checking in, say, in coach class at the 209 00:14:58,000 --> 00:15:05,240 airport, or lining up for security at the airport? 210 00:15:05,240 --> 00:15:07,120 Which of those is better, do you think? 211 00:15:07,120 --> 00:15:11,630 Which provides, on average, better service, multiple 212 00:15:11,630 --> 00:15:15,160 queues or a single queue? 213 00:15:15,160 --> 00:15:19,650 Single queue, right, is much better. 214 00:15:19,650 --> 00:15:21,620 In fact, it's easy to construct a 215 00:15:21,620 --> 00:15:24,840 proof why it's better. 216 00:15:24,840 --> 00:15:27,640 Which is why we now see them, typically, at places like 217 00:15:27,640 --> 00:15:29,380 banks and airports. 218 00:15:29,380 --> 00:15:31,360 Didn't used to be. 219 00:15:31,360 --> 00:15:33,720 Initially, people didn't understand this was better, 220 00:15:33,720 --> 00:15:35,075 and they would have multiple queues. 221 00:15:39,810 --> 00:15:44,410 Why don't we always have a single queue? 222 00:15:44,410 --> 00:15:49,380 Because we may not have enough space. 223 00:15:49,380 --> 00:15:52,120 So you can, again, imagine at the supermarket there'd be no 224 00:15:52,120 --> 00:15:54,710 place to put the single queue for all of the 225 00:15:54,710 --> 00:15:58,120 cash registers, maybe. 226 00:15:58,120 --> 00:16:02,100 And another question we have to ask is whether or not we 227 00:16:02,100 --> 00:16:03,350 allow preemption. 228 00:16:08,610 --> 00:16:12,880 In some queuing systems, a server can stop processing a 229 00:16:12,880 --> 00:16:17,490 customer to deal with another emergency customer. 230 00:16:17,490 --> 00:16:20,470 In others, once a job is started, it has to run to 231 00:16:20,470 --> 00:16:22,290 completion. 232 00:16:22,290 --> 00:16:24,590 And, again, you get very different performance, 233 00:16:24,590 --> 00:16:27,840 depending upon whether you allow preemption or not. 234 00:16:32,040 --> 00:16:35,260 An important part of the architecture is, of course, 235 00:16:35,260 --> 00:16:37,170 the characteristics of the queue itself. 236 00:16:49,850 --> 00:16:51,885 The fundamental question is the policy. 237 00:16:58,600 --> 00:17:02,950 How from the set of customers waiting for service do we 238 00:17:02,950 --> 00:17:05,200 choose the customer to be served next? 239 00:17:08,079 --> 00:17:12,284 So a very common policy is FIFO. 240 00:17:12,284 --> 00:17:15,609 It stands for First In First Out. 241 00:17:15,609 --> 00:17:19,050 That's the one we see most of the time in a lot of physical 242 00:17:19,050 --> 00:17:20,390 situations. 243 00:17:20,390 --> 00:17:22,899 Whoever gets in line first get served first. 244 00:17:26,760 --> 00:17:30,260 There are some situations where you do 245 00:17:30,260 --> 00:17:33,280 Last In First Out. 246 00:17:33,280 --> 00:17:37,120 Whoever's arrived most recently gets served first. 247 00:17:39,750 --> 00:17:45,690 A very popular one in many computing applications is 248 00:17:45,690 --> 00:17:51,930 what's called SRPT, which is short for Shortest Remaining 249 00:17:51,930 --> 00:17:53,180 Processing Time. 250 00:18:03,870 --> 00:18:08,705 Take whichever job you can complete fastest. 251 00:18:14,780 --> 00:18:17,900 So these are the three most popular policies. 252 00:18:17,900 --> 00:18:20,970 You could also imagine a random policy, where you just 253 00:18:20,970 --> 00:18:24,470 chose some random member of the queue. 254 00:18:24,470 --> 00:18:27,330 Then there are lots of other kinds of issues, which I won't 255 00:18:27,330 --> 00:18:30,630 go into in detail. 256 00:18:30,630 --> 00:18:34,410 The choice of queuing discipline, as we'll see when 257 00:18:34,410 --> 00:18:42,790 we look at the code, can have a major effect on performance. 258 00:18:42,790 --> 00:18:47,660 In particular, it can be used to reduce congestion. 259 00:18:47,660 --> 00:18:54,840 We'll often see in practice this one. 260 00:18:54,840 --> 00:18:59,485 Now, why might that be a very useful practical method? 261 00:19:03,072 --> 00:19:06,340 Well, It's got one obvious feature. 262 00:19:06,340 --> 00:19:15,220 If the available space for the queue is small, by taking the 263 00:19:15,220 --> 00:19:19,940 ones you can finish fastest, you reduce the average number 264 00:19:19,940 --> 00:19:23,180 of elements in the queue. 265 00:19:23,180 --> 00:19:25,910 Because you get to process more customers by taking the 266 00:19:25,910 --> 00:19:29,250 customers that you can process quickly. 267 00:19:29,250 --> 00:19:31,280 And so on average, there will be fewer 268 00:19:31,280 --> 00:19:32,600 customers in the queue. 269 00:19:35,180 --> 00:19:37,105 And so it reduces congestion. 270 00:19:43,230 --> 00:19:50,080 As we'll see, it also improves expected service time. 271 00:19:50,080 --> 00:19:54,650 So it is an excellent method. 272 00:19:54,650 --> 00:19:58,380 When we talk about queuing networks, what 273 00:19:58,380 --> 00:19:59,550 we're going to see-- 274 00:19:59,550 --> 00:20:02,320 and I hope I've implied this already-- 275 00:20:02,320 --> 00:20:05,480 is that probability has to play a fundamental role in 276 00:20:05,480 --> 00:20:09,920 understanding them, because there's randomness. 277 00:20:09,920 --> 00:20:13,820 There's randomness in the inter-arrival time, and 278 00:20:13,820 --> 00:20:18,180 there's typically randomness in how long each job will take 279 00:20:18,180 --> 00:20:21,090 to process. 280 00:20:21,090 --> 00:20:24,660 What are the questions we might want to ask about a 281 00:20:24,660 --> 00:20:29,730 queuing system to see whether we've designed it properly? 282 00:20:29,730 --> 00:20:33,220 An important question is the average waiting time. 283 00:20:39,550 --> 00:20:44,100 On average, how long does a job wait between the time it 284 00:20:44,100 --> 00:20:49,570 enters the queue and the time it leaves the queue? 285 00:20:49,570 --> 00:20:51,050 Now, imagine that you're waiting for 286 00:20:51,050 --> 00:20:53,170 the MIT Shuttle Bus. 287 00:20:53,170 --> 00:20:57,950 How long you wait before you get on the bus, on average? 288 00:20:57,950 --> 00:21:01,880 You can also ask, once the job starts, how long to complete? 289 00:21:07,790 --> 00:21:11,340 We can also ask, is the waiting time bounded? 290 00:21:17,410 --> 00:21:19,910 So this is a different question than how long you 291 00:21:19,910 --> 00:21:22,430 should expect to wait on average. 292 00:21:22,430 --> 00:21:25,670 It's, what's the probability of your not having to wait 293 00:21:25,670 --> 00:21:27,280 longer than some upper bound? 294 00:21:30,360 --> 00:21:37,620 So you can imagine that if you were working for some company 295 00:21:37,620 --> 00:21:41,430 that, for example, sold products over the telephone, 296 00:21:41,430 --> 00:21:44,170 you might want to put a bound on how long a customer would 297 00:21:44,170 --> 00:21:48,560 wait before their call got picked up. 298 00:21:48,560 --> 00:21:52,580 And you'd do some analysis, saying if people have to wait 299 00:21:52,580 --> 00:21:55,580 longer than three minutes, they hang up the phone. 300 00:21:55,580 --> 00:21:59,635 And so we'll have enough servers that it's only rare 301 00:21:59,635 --> 00:22:03,060 that someone has to wait more than three minutes. 302 00:22:03,060 --> 00:22:05,870 It's a different question than how long people have to wait 303 00:22:05,870 --> 00:22:07,120 on average. 304 00:22:09,610 --> 00:22:12,235 We've already talked about the average queue length. 305 00:22:20,120 --> 00:22:24,210 And by analogy, we can also ask about the bound. 306 00:22:31,394 --> 00:22:35,020 on queue length. 307 00:22:35,020 --> 00:22:37,490 You can imagine if you're designing a router for the 308 00:22:37,490 --> 00:22:41,640 internet, you need to know how much memory to allocate for 309 00:22:41,640 --> 00:22:45,700 the queues of jobs so that you don't run out. 310 00:22:45,700 --> 00:22:49,070 It's not infinite, so there's an upper bound in how long 311 00:22:49,070 --> 00:22:51,990 you'll let the queues grow. 312 00:22:51,990 --> 00:22:57,700 And finally, along a different dimension is something we've 313 00:22:57,700 --> 00:22:59,670 already talked about, server utilization. 314 00:23:05,500 --> 00:23:10,140 What is the expected utilization of each server, in 315 00:23:10,140 --> 00:23:12,840 the sense of, what is the expected amount of time it 316 00:23:12,840 --> 00:23:15,480 will be fully occupied? 317 00:23:15,480 --> 00:23:19,800 Remember, servers cost money, so keeping 318 00:23:19,800 --> 00:23:23,510 them busy is important. 319 00:23:23,510 --> 00:23:28,270 If we can assign relative cost values to each of these 320 00:23:28,270 --> 00:23:32,760 things, we can then build a system that will let us do an 321 00:23:32,760 --> 00:23:37,220 analysis and build an optimal system-- 322 00:23:37,220 --> 00:23:40,070 decide how big the queues should be, how many servers, 323 00:23:40,070 --> 00:23:43,660 how fast they should be, do the analysis, and design a 324 00:23:43,660 --> 00:23:45,875 system that meets some optimization criteria. 325 00:23:49,120 --> 00:23:54,030 So now, we need to investigate these things. 326 00:23:54,030 --> 00:23:55,390 Two basic methods, as we've 327 00:23:55,390 --> 00:23:58,360 discussed before, are analytic-- 328 00:23:58,360 --> 00:24:02,690 and, indeed, you can get books on analytic queuing theory, 329 00:24:02,690 --> 00:24:06,300 really thick, hard-to-read books, I might add, that give 330 00:24:06,300 --> 00:24:08,680 you complicated formulas for deriving 331 00:24:08,680 --> 00:24:10,910 these kinds of things. 332 00:24:10,910 --> 00:24:14,970 In practice, they're hardly ever used, because most 333 00:24:14,970 --> 00:24:18,990 systems are too complex to actually model analytically. 334 00:24:18,990 --> 00:24:22,650 So, in fact, today, most queuing network systems are 335 00:24:22,650 --> 00:24:28,850 analyzed using simulations, the kind of discrete event 336 00:24:28,850 --> 00:24:31,760 simulations we've looked at earlier in the term. 337 00:24:31,760 --> 00:24:32,730 All right. 338 00:24:32,730 --> 00:24:35,940 Now, I want to look at a particular example, and see 339 00:24:35,940 --> 00:24:40,950 how we can build a simulation that will let us answer these 340 00:24:40,950 --> 00:24:45,270 kinds of questions about a particular example. 341 00:24:45,270 --> 00:24:47,405 The example is a -- 342 00:24:47,405 --> 00:24:49,420 and again, this is the one that you'll be 343 00:24:49,420 --> 00:24:51,500 asked to look at -- 344 00:24:51,500 --> 00:24:56,020 is a simplification of the MIT Shuttle Bus system. 345 00:24:56,020 --> 00:25:03,560 So as I'm sure you all know, it runs in a loop, picking up 346 00:25:03,560 --> 00:25:07,850 students, and dropping them off at some number of stops. 347 00:25:07,850 --> 00:25:12,880 For legal reasons, each bus has a maximum capacity-- 348 00:25:12,880 --> 00:25:15,970 often exceeded I'm sure, in practice, but there is 349 00:25:15,970 --> 00:25:20,460 officially a maximum number of people allowed on a bus. 350 00:25:20,460 --> 00:25:24,090 And it takes a certain amount of time to go around the loop. 351 00:25:27,140 --> 00:25:32,430 The obvious question to ask is, how long should a student 352 00:25:32,430 --> 00:25:35,400 expect to have to wait for a bus at a particular stop to 353 00:25:35,400 --> 00:25:37,090 get picked up? 354 00:25:37,090 --> 00:25:41,490 And what should MIT do to, depending upon whether it's 355 00:25:41,490 --> 00:25:44,590 feeling benevolent or not, minimize or maximize the 356 00:25:44,590 --> 00:25:46,980 waiting time for the bus? 357 00:25:46,980 --> 00:25:49,040 All right. 358 00:25:49,040 --> 00:25:50,690 Most of the code we're going to look at 359 00:25:50,690 --> 00:25:54,720 now is on your handout. 360 00:25:54,720 --> 00:25:58,360 I should say I've deleted the obvious parts so I could fit 361 00:25:58,360 --> 00:25:59,850 it on the handout. 362 00:25:59,850 --> 00:26:04,360 However, we'll be posting the code on the web today, a .py 363 00:26:04,360 --> 00:26:08,880 file that you'll be able to study, and more importantly, 364 00:26:08,880 --> 00:26:10,130 probably run it. 365 00:26:18,670 --> 00:26:21,760 All right, let's start. 366 00:26:21,760 --> 00:26:25,510 So, as usual in designing a piece of code, I began with 367 00:26:25,510 --> 00:26:27,630 some useful classes. 368 00:26:27,630 --> 00:26:30,240 You won't be surprised that the first class I looked at 369 00:26:30,240 --> 00:26:31,700 was class job. 370 00:26:34,650 --> 00:26:36,830 So what is a job? 371 00:26:36,830 --> 00:26:39,000 A job is -- 372 00:26:39,000 --> 00:26:41,060 depending upon the mean arrival and 373 00:26:41,060 --> 00:26:44,060 the mean work involved. 374 00:26:44,060 --> 00:26:48,736 And I've chosen to model arrivals as exponential. 375 00:26:52,580 --> 00:26:57,690 And I've chosen to model work as a Gaussian. 376 00:26:57,690 --> 00:26:59,560 Nothing magical about this. 377 00:26:59,560 --> 00:27:02,810 And in fact, I played with various other models. 378 00:27:02,810 --> 00:27:05,690 What would happen if the work were uniformly distributed or 379 00:27:05,690 --> 00:27:07,510 exponentially distributed? 380 00:27:07,510 --> 00:27:09,215 And, of course, you get different answers. 381 00:27:11,980 --> 00:27:13,390 I said next two attributes. 382 00:27:13,390 --> 00:27:15,980 There is actually only one attribute here. 383 00:27:15,980 --> 00:27:20,150 And this is going to keep track of when a job enters the 384 00:27:20,150 --> 00:27:24,830 queue, so that we can tell how long it had to wait. 385 00:27:24,830 --> 00:27:27,900 And then there's the inter-arrival, the work, the 386 00:27:27,900 --> 00:27:31,420 queue, the queue time, et cetera. 387 00:27:31,420 --> 00:27:35,210 And then I'm going to model a passenger as a job. 388 00:27:35,210 --> 00:27:37,890 You'll note this is kind of a boring class. 389 00:27:37,890 --> 00:27:40,500 All I've done is say, pass. 390 00:27:40,500 --> 00:27:43,150 Because I'm not adding anything new. 391 00:27:43,150 --> 00:27:44,820 I am giving it a different type. 392 00:27:44,820 --> 00:27:48,280 And it gave me a place to put the comment here, that the 393 00:27:48,280 --> 00:27:51,330 arrival rate corresponds to passengers to arriving at a 394 00:27:51,330 --> 00:27:55,080 bus stop, and work is the time it takes a passenger 395 00:27:55,080 --> 00:27:58,020 to board the bus. 396 00:27:58,020 --> 00:28:00,410 There are many other things I could have done for work. 397 00:28:00,410 --> 00:28:02,840 I could have made it multi-dimensional, having to 398 00:28:02,840 --> 00:28:05,070 do with how long to get on the bus, how 399 00:28:05,070 --> 00:28:07,060 many stops, et cetera. 400 00:28:07,060 --> 00:28:09,440 For simplicity, I'm just assuming that there are some 401 00:28:09,440 --> 00:28:12,590 agile people who just get on the bus quickly, and there's 402 00:28:12,590 --> 00:28:15,090 some people who are a little bit slower, who might take a 403 00:28:15,090 --> 00:28:18,450 longer time to get on the bus. 404 00:28:18,450 --> 00:28:20,290 And that's it for jobs. 405 00:28:20,290 --> 00:28:23,980 Pretty simple, but pretty typical of the kinds 406 00:28:23,980 --> 00:28:25,230 of things we see. 407 00:28:28,110 --> 00:28:31,315 Then we come to the queues themselves. 408 00:28:34,000 --> 00:28:37,095 The root class is just the job queue. 409 00:28:39,690 --> 00:28:42,900 Jobs can arrive, and the queue can have a length. 410 00:28:42,900 --> 00:28:46,495 You'll note that I don't have any way for jobs to leave the 411 00:28:46,495 --> 00:28:48,780 queue in the base class. 412 00:28:48,780 --> 00:28:53,900 And that's because each subclass will be distinguished 413 00:28:53,900 --> 00:28:57,120 by the queueing discipline it's using. 414 00:28:57,120 --> 00:29:01,300 And the queueing discipline typically has to do with how 415 00:29:01,300 --> 00:29:04,360 jobs leave the queue. 416 00:29:04,360 --> 00:29:07,430 So there's a FIFO discipline. 417 00:29:07,430 --> 00:29:09,320 Pretty simplistic. 418 00:29:09,320 --> 00:29:14,920 It just removes the first item from the queue and returns it. 419 00:29:14,920 --> 00:29:19,330 Raises an exception if you try and remove something from the 420 00:29:19,330 --> 00:29:22,040 queue when there's nothing there. 421 00:29:22,040 --> 00:29:30,760 An SRPT is a little bit more involved, but not much. 422 00:29:30,760 --> 00:29:32,260 I've not tried to be clever. 423 00:29:32,260 --> 00:29:34,890 You could imagine a much more efficient implementation than 424 00:29:34,890 --> 00:29:36,710 the one I've got. 425 00:29:36,710 --> 00:29:40,030 But here, each time a job needs to leave the queue, I 426 00:29:40,030 --> 00:29:43,430 just search the queue to find one of the jobs with the least 427 00:29:43,430 --> 00:29:46,105 amount of work, and I remove that. 428 00:29:48,940 --> 00:29:52,970 That's why I'm searching with the index here, because pop 429 00:29:52,970 --> 00:29:57,740 lets me remove something from a list at a particular index. 430 00:30:02,040 --> 00:30:03,500 And then finally, I have another 431 00:30:03,500 --> 00:30:06,220 simple class, bus stop. 432 00:30:06,220 --> 00:30:10,370 And the key thing here what it's a subclass of. 433 00:30:10,370 --> 00:30:14,445 Initially, I'm choosing it to be a subclass of FIFO. 434 00:30:17,170 --> 00:30:21,130 Later, we'll see I could make it a subclass of SRPT, or in 435 00:30:21,130 --> 00:30:24,130 fact, anything else I chose. 436 00:30:24,130 --> 00:30:28,690 But this gives me a convenient way to decide what queueing 437 00:30:28,690 --> 00:30:31,285 discipline I'm going to use at the bus stops. 438 00:30:41,330 --> 00:30:46,450 So I mentioned earlier that SRPT is nice, because it 439 00:30:46,450 --> 00:30:52,220 allows us to reduce the size of the queue. 440 00:30:52,220 --> 00:30:57,970 I also mentioned that it's typically optimal in the sense 441 00:30:57,970 --> 00:31:02,660 of producing the shortest average waiting time. 442 00:31:02,660 --> 00:31:05,820 So let's think about why. 443 00:31:05,820 --> 00:31:09,640 Imagine that we do the opposite. 444 00:31:09,640 --> 00:31:11,590 This is a good intellectual tool. 445 00:31:11,590 --> 00:31:12,650 Just think of the opposite. 446 00:31:12,650 --> 00:31:15,345 Suppose we always took the longest job first. 447 00:31:18,300 --> 00:31:20,840 What would that do to the average waiting time? 448 00:31:24,200 --> 00:31:30,910 Say we had a job that took 10 minutes and a queue with 10 449 00:31:30,910 --> 00:31:31,885 people in it. 450 00:31:31,885 --> 00:31:35,400 Well, while we were waiting for that 1 10-minute job to 451 00:31:35,400 --> 00:31:40,510 get on the bus, the other 9 people would each have to wait 452 00:31:40,510 --> 00:31:42,050 10 minutes. 453 00:31:42,050 --> 00:31:46,480 9 times 10, 90 minutes of waiting time. 454 00:31:46,480 --> 00:31:50,080 Not very good, right? 455 00:31:50,080 --> 00:31:55,800 Now, suppose each of those 9 jobs only took 1 minute. 456 00:31:55,800 --> 00:31:59,950 Well, the first job would wait 0, the next job would wait 1 457 00:31:59,950 --> 00:32:02,750 minute, the next job would wait 2 minutes. 458 00:32:02,750 --> 00:32:06,960 And even the longest job would only have to wait 9 minutes 459 00:32:06,960 --> 00:32:08,410 before it started. 460 00:32:08,410 --> 00:32:10,880 So the total amount of time spent waiting 461 00:32:10,880 --> 00:32:12,130 would be much less. 462 00:32:15,880 --> 00:32:19,280 So we can see that by using shortest remaining processing 463 00:32:19,280 --> 00:32:23,380 time, the waiting times are reduced. 464 00:32:23,380 --> 00:32:27,310 Now, with the bus example, it's a little bit strange, in 465 00:32:27,310 --> 00:32:29,490 that, yes, you'd get on the bus, but maybe the bus 466 00:32:29,490 --> 00:32:33,280 wouldn't move at all while it was waiting for that last 467 00:32:33,280 --> 00:32:35,560 person to get on. 468 00:32:35,560 --> 00:32:37,030 But most queueing disciplines-- 469 00:32:37,030 --> 00:32:39,970 imagine you're in the supermarket-- 470 00:32:39,970 --> 00:32:42,870 you don't care how long the guys behind you take. 471 00:32:42,870 --> 00:32:45,170 As soon as you get to the front, you get processed, you 472 00:32:45,170 --> 00:32:47,870 get to leave the store. 473 00:32:47,870 --> 00:32:51,550 So in fact, a supermarket would, on average, have 474 00:32:51,550 --> 00:32:55,630 happier customers if it followed shortest remaining 475 00:32:55,630 --> 00:33:01,040 processing time, and always took whoever had the fewest 476 00:33:01,040 --> 00:33:03,910 number of items first. 477 00:33:03,910 --> 00:33:06,690 Why don't they do that? 478 00:33:06,690 --> 00:33:11,570 Or why is not SRPT always used in practice? 479 00:33:11,570 --> 00:33:14,200 It's got one glaring problem. 480 00:33:14,200 --> 00:33:15,450 What's that problem? 481 00:33:19,340 --> 00:33:21,330 AUDIENCE: It doesn't seem fair to everyone else. 482 00:33:21,330 --> 00:33:22,580 PROFESSOR: It's not fair. 483 00:33:25,050 --> 00:33:29,450 And this is actually a technical word. 484 00:33:29,450 --> 00:33:33,770 People talk about fairness of a queueing discipline. 485 00:33:33,770 --> 00:33:40,260 And in particular, it's so unfair that it allows 486 00:33:40,260 --> 00:33:46,700 starvation, another technical term. 487 00:33:52,790 --> 00:33:58,930 Imagine that you're the person with the 10-minute job, and 488 00:33:58,930 --> 00:34:01,690 there's a continuing stream of people arriving 489 00:34:01,690 --> 00:34:04,630 with 1-minute jobs. 490 00:34:04,630 --> 00:34:09,090 You never to get your job processed at all. 491 00:34:09,090 --> 00:34:10,679 You just sit there, and you wait, and you 492 00:34:10,679 --> 00:34:11,590 wait, and you wait. 493 00:34:11,590 --> 00:34:13,025 And in fact, you wait forever. 494 00:34:16,199 --> 00:34:19,190 In the bus situation, imagine you're the person who's in a 495 00:34:19,190 --> 00:34:21,449 wheelchair and takes 10 minutes to get on the bus. 496 00:34:24,080 --> 00:34:26,530 And people keep arriving at the bus stop. 497 00:34:26,530 --> 00:34:28,923 Well, before it gets to be your turn, the bus is full, 498 00:34:28,923 --> 00:34:31,170 and it leaves. 499 00:34:31,170 --> 00:34:33,670 And you have to wait for the next bus. 500 00:34:33,670 --> 00:34:36,100 But people arrive while you're waiting. 501 00:34:36,100 --> 00:34:36,949 It arrives. 502 00:34:36,949 --> 00:34:38,679 Again, you don't get on. 503 00:34:38,679 --> 00:34:40,460 And you never get on. 504 00:34:40,460 --> 00:34:43,469 This is technically called starvation. 505 00:34:43,469 --> 00:34:47,219 And it's a problem that SRPT has. 506 00:34:47,219 --> 00:34:49,850 So typically, if you're using that as your scheduling 507 00:34:49,850 --> 00:34:54,060 algorithm, you've got to put in some sort of a priority on 508 00:34:54,060 --> 00:34:58,880 top of it that gives the long jobs a chance to at least run 509 00:34:58,880 --> 00:35:00,820 once in a while. 510 00:35:00,820 --> 00:35:03,020 And there are lots of different disciplines for 511 00:35:03,020 --> 00:35:05,630 doing that. 512 00:35:05,630 --> 00:35:09,690 All right, let's continue looking at the code. 513 00:35:09,690 --> 00:35:14,060 So now we've got bus stops, which are queues. 514 00:35:14,060 --> 00:35:15,770 We got jobs. 515 00:35:15,770 --> 00:35:18,570 Well, we're going to have our server. 516 00:35:18,570 --> 00:35:20,400 And in this case, our server is a bus. 517 00:35:24,010 --> 00:35:28,530 Every bus has got a capacity, the number of people it's 518 00:35:28,530 --> 00:35:31,515 allowed to hold, and a speed. 519 00:35:31,515 --> 00:35:34,060 The speed has to do with how fast it goes 520 00:35:34,060 --> 00:35:36,770 from stop to stop. 521 00:35:36,770 --> 00:35:39,180 And for simplicity, we're going to assume that this 522 00:35:39,180 --> 00:35:43,210 depends only on the bus itself, not on the traffic. 523 00:35:43,210 --> 00:35:46,870 Not true in Cambridge and Boston, of course, but we 524 00:35:46,870 --> 00:35:48,740 can't get everything in a code that we get 525 00:35:48,740 --> 00:35:51,560 through in one lecture. 526 00:35:51,560 --> 00:35:54,770 So it's got a capacity, it's got a speed. 527 00:35:54,770 --> 00:35:56,520 And then, we can keep track of how many 528 00:35:56,520 --> 00:35:58,610 people are on the bus. 529 00:35:58,610 --> 00:36:02,100 It's got an enter, which has to do with 530 00:36:02,100 --> 00:36:04,420 people getting on it. 531 00:36:04,420 --> 00:36:08,180 And does that until it's full, and then 532 00:36:08,180 --> 00:36:11,180 it raises an exception. 533 00:36:11,180 --> 00:36:15,320 And things can leave the bus. 534 00:36:15,320 --> 00:36:17,660 And here's the interesting method. 535 00:36:17,660 --> 00:36:23,720 Unload takes a self and the number to be 536 00:36:23,720 --> 00:36:25,690 unloaded from the bus. 537 00:36:25,690 --> 00:36:30,780 And it just calls self.leave over and over again. 538 00:36:30,780 --> 00:36:34,110 All right, those are our basic classes. 539 00:36:34,110 --> 00:36:36,270 Nothing too sophisticated. 540 00:36:36,270 --> 00:36:39,060 As is often the case with classes, the code is 541 00:36:39,060 --> 00:36:41,140 straightforward. 542 00:36:41,140 --> 00:36:43,780 And now comes the not-so-quite-straightforward 543 00:36:43,780 --> 00:36:49,460 code, which is the actual simulation itself. 544 00:36:49,460 --> 00:36:52,560 Probably the most important thing to understand in looking 545 00:36:52,560 --> 00:36:57,200 at this code is the arguments. 546 00:36:57,200 --> 00:37:02,760 This will tell us what the simulation depends on. 547 00:37:02,760 --> 00:37:06,370 So there's going to be a bus. 548 00:37:06,370 --> 00:37:09,500 So notice we have only one bus. 549 00:37:09,500 --> 00:37:12,270 So, again, I've simplified the simulation. 550 00:37:12,270 --> 00:37:16,750 Instead of having multiple buses running around the loop, 551 00:37:16,750 --> 00:37:18,360 we're going to assume you've just got to wait for that 552 00:37:18,360 --> 00:37:21,010 first bus to get back. 553 00:37:21,010 --> 00:37:24,180 Later, we can talk about what would be involved in having 554 00:37:24,180 --> 00:37:26,510 multiple buses. 555 00:37:26,510 --> 00:37:30,490 The number of stops in the loop, the loop length. 556 00:37:30,490 --> 00:37:33,880 And for simplicity, I'm going to assume that the stops are 557 00:37:33,880 --> 00:37:35,770 equally spaced along the length. 558 00:37:38,870 --> 00:37:44,380 The mean arrival rate of jobs, the mean work per job, and 559 00:37:44,380 --> 00:37:45,875 then how long we're going to run the simulation. 560 00:37:48,670 --> 00:37:52,120 Roughly speaking, I'm using the same units for the 561 00:37:52,120 --> 00:37:56,120 simulation time and the loop length. 562 00:37:56,120 --> 00:37:59,830 So this would tell us, if we simulate for 30,000 times, and 563 00:37:59,830 --> 00:38:06,090 the loop is this 1,200 time units long, how many times 564 00:38:06,090 --> 00:38:08,680 around the loop we could get, and how many stops the bus 565 00:38:08,680 --> 00:38:09,930 would make. 566 00:38:12,380 --> 00:38:13,660 All right. 567 00:38:13,660 --> 00:38:16,033 And then comes the body of the simulation. 568 00:38:20,340 --> 00:38:22,850 So the first thing-- actually, let me write up some 569 00:38:22,850 --> 00:38:27,320 pseudo-code here to basically show you the way it's 570 00:38:27,320 --> 00:38:28,570 structured. 571 00:38:34,460 --> 00:38:35,770 Yeah, I think we'll put it over here. 572 00:38:43,640 --> 00:38:49,610 So the first thing we do is we create the stops, and we 573 00:38:49,610 --> 00:38:55,140 initialize some variables then we're going to use to keep 574 00:38:55,140 --> 00:38:56,390 track of performance. 575 00:39:00,650 --> 00:39:04,980 We then enter the main loop, which is essentially while 576 00:39:04,980 --> 00:39:06,230 time not expired. 577 00:39:10,170 --> 00:39:11,930 That has to do with how long we're going to run the 578 00:39:11,930 --> 00:39:13,890 simulation. 579 00:39:13,890 --> 00:39:17,400 We move the bus. 580 00:39:17,400 --> 00:39:22,350 So the loop will go through one time unit each iteration. 581 00:39:22,350 --> 00:39:24,740 At least, it looks that way initially. 582 00:39:24,740 --> 00:39:27,710 So we'll move the bus that amount of time. 583 00:39:38,750 --> 00:39:43,350 So then, while we're doing it, passengers will 584 00:39:43,350 --> 00:39:44,600 arrive at the stops. 585 00:39:59,460 --> 00:40:01,455 Then we'll see when a bus is at a stop. 586 00:40:05,220 --> 00:40:09,410 Has it driven long enough to get to the next stop? 587 00:40:09,410 --> 00:40:15,280 And when it's there, we'll unload some passengers first, 588 00:40:15,280 --> 00:40:16,810 and then we'll load some passengers. 589 00:40:19,680 --> 00:40:26,540 And then, when we're done at the very end, we'll compute 590 00:40:26,540 --> 00:40:27,790 some statistics. 591 00:40:33,930 --> 00:40:38,640 So that's the overall structure of the simulation. 592 00:40:38,640 --> 00:40:41,140 Then we can put that in something outside it that 593 00:40:41,140 --> 00:40:45,760 tells us how many simulations to run and get more statistics 594 00:40:45,760 --> 00:40:47,010 about aggregate. 595 00:40:48,940 --> 00:40:54,790 All right, now working our way through the code, the 596 00:40:54,790 --> 00:40:56,610 initialization, while time less than 597 00:40:56,610 --> 00:41:02,020 simTime, advance time. 598 00:41:02,020 --> 00:41:02,930 Move the bus. 599 00:41:02,930 --> 00:41:07,910 Now, how far we move it depends upon how fast it is. 600 00:41:07,910 --> 00:41:12,260 So we'll just add to the bus location however far it's 601 00:41:12,260 --> 00:41:15,170 allowed to move in one time unit. 602 00:41:15,170 --> 00:41:18,030 I don't care whether the time unit is seconds, minutes, 603 00:41:18,030 --> 00:41:20,025 hours, days, whatever. 604 00:41:20,025 --> 00:41:21,550 Just it has to be all consistent. 605 00:41:25,270 --> 00:41:27,860 Then I'll see if there's a passenger waiting to enter the 606 00:41:27,860 --> 00:41:30,780 queue by checking the arrival time. 607 00:41:33,550 --> 00:41:37,130 And passengers can arrive simultaneously at each stop. 608 00:41:41,200 --> 00:41:44,430 I apologize for leaving the comments out of your handouts, 609 00:41:44,430 --> 00:41:46,870 but I couldn't squeeze it onto the page with the comments. 610 00:41:56,480 --> 00:41:57,940 Then, here's the interesting piece. 611 00:41:57,940 --> 00:41:59,050 So we do this. 612 00:41:59,050 --> 00:42:03,500 We're just having passengers arrive based upon the 613 00:42:03,500 --> 00:42:06,940 characteristics of jobs. 614 00:42:06,940 --> 00:42:10,950 See if the bus is at a stop. 615 00:42:10,950 --> 00:42:17,780 If the bus location divided by the inter-stop distance is 616 00:42:17,780 --> 00:42:22,600 equal to 0, so it's actually at a stop, I'll do my 617 00:42:22,600 --> 00:42:25,420 unloading, et cetera. 618 00:42:25,420 --> 00:42:31,320 Now, down here, you'll notice that up here, I had this 619 00:42:31,320 --> 00:42:36,960 assumption that the speed of the bus is small relative to 620 00:42:36,960 --> 00:42:38,425 the inter-stop distance. 621 00:42:41,100 --> 00:42:45,895 This assumption is important because of this statement. 622 00:42:49,210 --> 00:42:53,000 If the bus were moving too fast. 623 00:42:53,000 --> 00:42:56,830 It might skip over the stops. 624 00:42:56,830 --> 00:43:02,670 Now, this is kind of a clumsy trick I've used here. 625 00:43:02,670 --> 00:43:04,550 It has to do with it being small. 626 00:43:04,550 --> 00:43:07,120 It has to do with each movement of the bus being, in 627 00:43:07,120 --> 00:43:10,540 fact, an integral of the inter-stop distance so that 628 00:43:10,540 --> 00:43:13,790 you don't skip over the stops. 629 00:43:13,790 --> 00:43:16,870 In a real simulation, I would have done something much more 630 00:43:16,870 --> 00:43:21,370 careful to deal with not missing stops. 631 00:43:21,370 --> 00:43:24,240 But again, I wanted to make this relatively simple. 632 00:43:24,240 --> 00:43:29,790 So I'm going to jigger things so that the speed of the bus 633 00:43:29,790 --> 00:43:33,390 evenly divides the inter-stop distance, so when I advance 634 00:43:33,390 --> 00:43:37,180 the bus, it never skips over a stop. 635 00:43:37,180 --> 00:43:38,390 It's just a trick. 636 00:43:38,390 --> 00:43:41,570 Not very elegant trick, but it keeps things working. 637 00:43:44,130 --> 00:43:44,256 All right. 638 00:43:44,256 --> 00:43:48,960 Then I'm going to unload some fraction of the passengers. 639 00:43:48,960 --> 00:43:52,350 Now, again, in a more realistic simulation, I'd be 640 00:43:52,350 --> 00:43:56,640 keeping track of what's the average distance a passenger 641 00:43:56,640 --> 00:43:58,170 wants to travel. 642 00:43:58,170 --> 00:44:01,910 And I would have, in fact, made work two-dimensional-- 643 00:44:01,910 --> 00:44:05,750 the amount of time to get on the bus, plus how far the 644 00:44:05,750 --> 00:44:07,850 passenger wanted to travel. 645 00:44:07,850 --> 00:44:10,350 Again, here, I've done something simple. 646 00:44:10,350 --> 00:44:13,880 I've just assumed that a fraction of all the passengers 647 00:44:13,880 --> 00:44:17,130 get off at each stop, and the fraction depends upon how many 648 00:44:17,130 --> 00:44:20,690 total stops there are. 649 00:44:20,690 --> 00:44:24,310 We can still understand most of the interesting aspects of 650 00:44:24,310 --> 00:44:28,780 the problem, even with all of these simplifications. 651 00:44:28,780 --> 00:44:31,130 And that's an important lesson. 652 00:44:31,130 --> 00:44:36,850 Every simulation is a simplification of reality. 653 00:44:36,850 --> 00:44:41,310 No simulation is ever a perfect model of reality. 654 00:44:41,310 --> 00:44:45,010 No model is ever a perfect model of reality. 655 00:44:45,010 --> 00:44:49,220 What we typically do in building the simulation is 656 00:44:49,220 --> 00:44:55,290 simplify it enough that we can get it to work, but not so 657 00:44:55,290 --> 00:44:59,640 much that we can't answer the questions we want to answer. 658 00:44:59,640 --> 00:45:03,130 And so I've made a lot of these simplifications, but 659 00:45:03,130 --> 00:45:07,420 they will still allow us, while maybe not to get precise 660 00:45:07,420 --> 00:45:11,220 answers about the impact of various things, to understand 661 00:45:11,220 --> 00:45:14,970 how things relate to each other, the relative impact of 662 00:45:14,970 --> 00:45:16,315 various design decisions. 663 00:45:23,740 --> 00:45:26,090 All right. 664 00:45:26,090 --> 00:45:30,360 If the bus is at a stop, as I said, some passengers will get 665 00:45:30,360 --> 00:45:31,610 on, get off. 666 00:45:35,260 --> 00:45:38,840 Passengers that are already at the stop will try 667 00:45:38,840 --> 00:45:40,090 and get on the bus. 668 00:45:42,700 --> 00:45:47,810 We'll have to advance time, because time starts to run out 669 00:45:47,810 --> 00:45:49,410 as people are getting on the bus, even 670 00:45:49,410 --> 00:45:51,020 though the bus is moving. 671 00:45:51,020 --> 00:45:52,520 But, of course, even though time is 672 00:45:52,520 --> 00:45:54,750 advancing, the bus is not. 673 00:45:54,750 --> 00:45:58,730 So we have to model that, the impact of loading times. 674 00:45:58,730 --> 00:46:01,460 And in fact, in mass transit systems, it turns out that 675 00:46:01,460 --> 00:46:04,770 loading time is a very important parameter. 676 00:46:04,770 --> 00:46:08,610 In many urban systems, subways will spend more time at 677 00:46:08,610 --> 00:46:12,640 stations getting loaded than between stations, moving to 678 00:46:12,640 --> 00:46:15,410 the next one, if the stations are dense. 679 00:46:15,410 --> 00:46:17,050 You may have noticed this on the Green Line. 680 00:46:19,800 --> 00:46:22,330 So we have to make sure we model that. 681 00:46:22,330 --> 00:46:25,180 And then, of course, since the bus could be at the stop for a 682 00:46:25,180 --> 00:46:28,700 while, passengers might arrive while it's at the stop. 683 00:46:33,180 --> 00:46:37,240 Then, we can keep track of the number of people left waiting 684 00:46:37,240 --> 00:46:41,400 when the simulation ends, and do things like that. 685 00:46:41,400 --> 00:46:47,630 All right, finally, there's this program test, which I 686 00:46:47,630 --> 00:46:49,770 won't go over in detail. 687 00:46:49,770 --> 00:46:53,190 It's exactly like the drivers we've written for other 688 00:46:53,190 --> 00:46:59,470 simulations for at least half the semester, in which I run 689 00:46:59,470 --> 00:47:02,270 simbus multiple times, accumulate results from 690 00:47:02,270 --> 00:47:07,390 trials, and then plot them nicely. 691 00:47:07,390 --> 00:47:10,920 All right, let's run it. 692 00:47:10,920 --> 00:47:14,190 So I'm going to run it with-- 693 00:47:14,190 --> 00:47:16,280 I've actually written it so that I can look at 694 00:47:16,280 --> 00:47:19,620 combinations of speeds and capacities. 695 00:47:19,620 --> 00:47:22,100 But first, I'll just look at small combinations-- 696 00:47:22,100 --> 00:47:22,640 i.e. 697 00:47:22,640 --> 00:47:24,750 each list will be one. 698 00:47:24,750 --> 00:47:27,760 So we'll test it with a capacity of 30 and a speed of 699 00:47:27,760 --> 00:47:30,900 10, to 40 trials. 700 00:47:30,900 --> 00:47:34,060 Then, we'll test it with a capacity of 15 and the speed 701 00:47:34,060 --> 00:47:38,240 of 10 and a capacity of 15 and a speed of 20. 702 00:47:51,760 --> 00:47:52,070 All right. 703 00:47:52,070 --> 00:47:54,500 We have some results. 704 00:47:54,500 --> 00:48:00,640 So what we can tell looking at Green Line is that I have a 705 00:48:00,640 --> 00:48:04,080 speed of 10 and a capacity of 15. 706 00:48:04,080 --> 00:48:10,930 The aggregate average wait time is long and apparently 707 00:48:10,930 --> 00:48:13,550 growing the longer I run the simulation. 708 00:48:13,550 --> 00:48:17,290 I've only plotted here up to the first 500 times if the bus 709 00:48:17,290 --> 00:48:18,980 stop at a stop. 710 00:48:18,980 --> 00:48:21,490 But we can imagine that if I went further, it would just 711 00:48:21,490 --> 00:48:24,830 get worse for a while. 712 00:48:24,830 --> 00:48:28,310 Then, it will eventually plateau, but it will take it 713 00:48:28,310 --> 00:48:29,590 quite a while to do that. 714 00:48:32,120 --> 00:48:34,710 And here we can see the interesting thing, in that the 715 00:48:34,710 --> 00:48:40,640 Blue and the Red Lines are not very different. 716 00:48:40,640 --> 00:48:44,210 So what this tells us is there's a trade-off. 717 00:48:44,210 --> 00:48:48,810 I can afford to have smaller buses if I make them faster. 718 00:48:51,450 --> 00:48:55,040 Or conversely, if I want slow buses, I have 719 00:48:55,040 --> 00:48:56,740 to make them bigger. 720 00:48:56,740 --> 00:49:00,720 And I get more or less the same average wait time and not 721 00:49:00,720 --> 00:49:04,230 much difference in how many people are left 722 00:49:04,230 --> 00:49:06,110 behind at the end. 723 00:49:06,110 --> 00:49:07,630 Clearly, here I have a big number. 724 00:49:07,630 --> 00:49:10,510 These are smallish numbers. 725 00:49:10,510 --> 00:49:14,410 Again, we'd have to run it longer to see whether these 726 00:49:14,410 --> 00:49:16,950 are stable, and with different seeds, or different random 727 00:49:16,950 --> 00:49:20,120 numbers, to see whether or not the fact that this is 80 and 728 00:49:20,120 --> 00:49:23,320 this is 40 is statistically significant, or just an 729 00:49:23,320 --> 00:49:25,070 accident of this run. 730 00:49:25,070 --> 00:49:27,260 Because we do have randomness. 731 00:49:27,260 --> 00:49:31,180 But we did do 40 trials, so maybe there's a reason to 732 00:49:31,180 --> 00:49:35,590 believe that in fact, this is slightly worse. 733 00:49:35,590 --> 00:49:38,780 You'll notice also the Blue Line doesn't quite get all the 734 00:49:38,780 --> 00:49:43,060 way to 500, which means that slow bus didn't get to make 735 00:49:43,060 --> 00:49:45,750 enough stops. 736 00:49:45,750 --> 00:49:48,170 It took a long time to load up, because it had big 737 00:49:48,170 --> 00:49:54,430 capacity and didn't really get to all of the stops. 738 00:49:54,430 --> 00:49:55,770 All right. 739 00:49:55,770 --> 00:49:58,320 Let's try another experiment. 740 00:49:58,320 --> 00:50:00,100 And let's go change the queueing discipline. 741 00:50:06,070 --> 00:50:08,210 Go way back up here. 742 00:50:08,210 --> 00:50:17,630 And let's make it SRPT and see what we get. 743 00:50:32,830 --> 00:50:35,135 Well, we get something pretty different. 744 00:50:37,790 --> 00:50:43,470 In particular, you'll note that the average wait time has 745 00:50:43,470 --> 00:50:45,330 dropped rather significantly. 746 00:50:49,670 --> 00:50:54,820 It really has, as the theory predicted, led to the improved 747 00:50:54,820 --> 00:50:56,820 wait times. 748 00:50:56,820 --> 00:50:59,330 We'll also notice that it's got some interesting shapes 749 00:50:59,330 --> 00:51:05,560 here, where it jumps around, goes up, almost a knee here. 750 00:51:05,560 --> 00:51:09,640 And you might try and understand why it's doing that 751 00:51:09,640 --> 00:51:11,150 as you look at the code. 752 00:51:11,150 --> 00:51:12,300 Is it random? 753 00:51:12,300 --> 00:51:13,260 Is it just bad luck? 754 00:51:13,260 --> 00:51:15,840 Is there something fundamental going on? 755 00:51:15,840 --> 00:51:21,300 Think it all through and decide what's going on. 756 00:51:21,300 --> 00:51:22,950 All right, finally-- 757 00:51:27,780 --> 00:51:30,250 and, again, I suggest you play this with a lot of different 758 00:51:30,250 --> 00:51:33,460 combinations to get a sense of what the code is doing. 759 00:51:33,460 --> 00:51:36,000 So one last queuing network question to test your 760 00:51:36,000 --> 00:51:38,060 understanding-- 761 00:51:38,060 --> 00:51:39,060 different question. 762 00:51:39,060 --> 00:51:42,580 Suppose you were given the job of hiring a 6.00 lab 763 00:51:42,580 --> 00:51:46,120 assistant, and you had a choice between hiring an MIT 764 00:51:46,120 --> 00:51:49,900 student at $15 an hour or two Harvard 765 00:51:49,900 --> 00:51:54,040 students at $7.50 an hour. 766 00:51:54,040 --> 00:51:57,170 Suppose further that the MIT student could deal with twice 767 00:51:57,170 --> 00:52:00,380 as many problems per hour as the Harvard students. 768 00:52:00,380 --> 00:52:01,880 Does it matter which you hire? 769 00:52:06,110 --> 00:52:08,820 Well, you could build a simulation, and you would 770 00:52:08,820 --> 00:52:12,890 discover that in your queuing network, it didn't matter. 771 00:52:12,890 --> 00:52:15,270 On the other hand, when you ran it in real life, you would 772 00:52:15,270 --> 00:52:18,480 probably discover that it mattered a lot, because the 773 00:52:18,480 --> 00:52:23,190 MIT student would answer questions correctly. 774 00:52:23,190 --> 00:52:26,420 And the moral is, the queuing network never 775 00:52:26,420 --> 00:52:28,100 tells the whole story. 776 00:52:28,100 --> 00:52:30,010 You've really got to think about the 777 00:52:30,010 --> 00:52:31,680 thing in more detail. 778 00:52:31,680 --> 00:52:32,420 All right. 779 00:52:32,420 --> 00:52:33,260 One more lecture. 780 00:52:33,260 --> 00:52:34,510 See you on Thursday.