1 1 00:00:00,600 --> 00:00:02,300 Performance metrics. 2 2 00:00:02,300 --> 00:00:03,910 In this lesson, we're going to talk 3 3 00:00:03,910 --> 00:00:06,320 all about performance metrics and how they're used 4 4 00:00:06,320 --> 00:00:08,210 to ensure network availability. 5 5 00:00:08,210 --> 00:00:10,670 Now, network performance metrics are a large part 6 6 00:00:10,670 --> 00:00:12,140 of network monitoring. 7 7 00:00:12,140 --> 00:00:14,170 Network performance monitoring is the end-to-end 8 8 00:00:14,170 --> 00:00:16,960 network monitoring of your end user experience. 9 9 00:00:16,960 --> 00:00:19,140 This differs from traditional monitoring though, 10 10 00:00:19,140 --> 00:00:21,750 because traditional monitoring is focused on performance 11 11 00:00:21,750 --> 00:00:24,390 between two points, like a switch and a router, 12 12 00:00:24,390 --> 00:00:26,420 but with network performance monitoring, 13 13 00:00:26,420 --> 00:00:28,970 we're going to look at the overall end user experience 14 14 00:00:28,970 --> 00:00:30,040 by monitoring the performance 15 15 00:00:30,040 --> 00:00:32,950 from the end user's workstation to the final destination 16 16 00:00:32,950 --> 00:00:34,410 that they're trying to reach. 17 17 00:00:34,410 --> 00:00:36,690 So to help us monitor network performance, 18 18 00:00:36,690 --> 00:00:38,500 there's really going to be three key metrics 19 19 00:00:38,500 --> 00:00:39,620 that we're going to use. 20 20 00:00:39,620 --> 00:00:42,510 These are latency, bandwidth and jitter. 21 21 00:00:42,510 --> 00:00:44,850 The first metric is latency. 22 22 00:00:44,850 --> 00:00:47,210 Now, latency is the measure of the time that it takes 23 23 00:00:47,210 --> 00:00:50,140 for data to reach its destination across a network. 24 24 00:00:50,140 --> 00:00:53,279 Usually we measure network latency as the round trip time 25 25 00:00:53,279 --> 00:00:55,700 from a workstation to the distant end 26 26 00:00:55,700 --> 00:00:57,370 and back to the workstation. 27 27 00:00:57,370 --> 00:00:59,850 We report this time in milliseconds. 28 28 00:00:59,850 --> 00:01:02,660 Now, for example, let's say you open up your command prompt 29 29 00:01:02,660 --> 00:01:06,860 and you enter the command ping 8.8.8.8, and you hit enter. 30 30 00:01:06,860 --> 00:01:08,190 You're going to get a response that tells you 31 31 00:01:08,190 --> 00:01:11,940 how long it took for an ICNP packet to leave your computer 32 32 00:01:11,940 --> 00:01:15,200 reach the Google DNS server located at eight dot 8.8.8.8 33 33 00:01:15,200 --> 00:01:17,140 and return to your computer again. 34 34 00:01:17,140 --> 00:01:21,470 In my case, this took an average time of 38.2 milliseconds 35 35 00:01:21,470 --> 00:01:24,450 when I did it for four repetitive ping requests. 36 36 00:01:24,450 --> 00:01:26,740 Now it's important to measure the round trip delay 37 37 00:01:26,740 --> 00:01:29,130 for network latency because the computer that uses 38 38 00:01:29,130 --> 00:01:32,520 a TCP IP network can send only a limited amount of data 39 39 00:01:32,520 --> 00:01:34,280 to its destination at one time, 40 40 00:01:34,280 --> 00:01:36,680 and then it sits and waits for an acknowledgement 41 41 00:01:36,680 --> 00:01:39,230 that that data was received before it sends out 42 42 00:01:39,230 --> 00:01:40,860 more data across the network. 43 43 00:01:40,860 --> 00:01:44,230 So if you have high latency or a long round trip delay, 44 44 00:01:44,230 --> 00:01:45,670 this can drastically slow down 45 45 00:01:45,670 --> 00:01:48,800 your overall network performance for your end users. 46 46 00:01:48,800 --> 00:01:50,680 Now, if you're seeing consistent delays 47 47 00:01:50,680 --> 00:01:53,090 or even just spikes in the delay time in your network, 48 48 00:01:53,090 --> 00:01:55,400 this could indicate a major performance issue 49 49 00:01:55,400 --> 00:01:56,730 that's going to be occurring. 50 50 00:01:56,730 --> 00:01:58,740 For regular web traffic these delays 51 51 00:01:58,740 --> 00:02:00,150 aren't usually noticeable, 52 52 00:02:00,150 --> 00:02:02,590 but if you're using streaming video applications, 53 53 00:02:02,590 --> 00:02:05,480 things like voiceover IP, or you're playing video games, 54 54 00:02:05,480 --> 00:02:07,640 these delays are extremely noticeable 55 55 00:02:07,640 --> 00:02:10,580 and they can cause a lot of problems for your end users. 56 56 00:02:10,580 --> 00:02:13,720 Our second metric media monitor is known as bandwidth. 57 57 00:02:13,720 --> 00:02:16,390 Now bandwidth is the maximum rate of data transfer 58 58 00:02:16,390 --> 00:02:18,000 across a given network. 59 59 00:02:18,000 --> 00:02:19,830 Now, technically bandwidth is actually 60 60 00:02:19,830 --> 00:02:22,500 a theoretical concept that measures how much data 61 61 00:02:22,500 --> 00:02:25,410 could be transferred from a source to a destination 62 62 00:02:25,410 --> 00:02:27,000 under ideal conditions. 63 63 00:02:27,000 --> 00:02:29,270 But in reality, when we're talking about our networks 64 64 00:02:29,270 --> 00:02:31,280 and our connections, they're rarely operating 65 65 00:02:31,280 --> 00:02:33,510 at the perfect or ideal conditions. 66 66 00:02:33,510 --> 00:02:36,270 Therefore we often measure something known as throughput 67 67 00:02:36,270 --> 00:02:39,290 instead of bandwidth to monitor our network performance. 68 68 00:02:39,290 --> 00:02:41,620 Throughput is the actual measure of data 69 69 00:02:41,620 --> 00:02:43,190 as it's being successfully transferred 70 70 00:02:43,190 --> 00:02:45,370 from the source to the destination, 71 71 00:02:45,370 --> 00:02:47,680 but you'll often hear people use the terms 72 72 00:02:47,680 --> 00:02:49,910 bandwidth and throughput interchangeably, 73 73 00:02:49,910 --> 00:02:51,880 not realizing there is a difference. 74 74 00:02:51,880 --> 00:02:54,960 Technically, bandwidth is a theoretical limit 75 75 00:02:54,960 --> 00:02:57,810 where throughput is the reality of what you're achieving. 76 76 00:02:57,810 --> 00:03:00,450 So if you want to a bandwidth speed test 77 77 00:03:00,450 --> 00:03:03,210 or more accurately, a throughput test for your network, 78 78 00:03:03,210 --> 00:03:06,630 you can go to something like speedtest.net and click on go, 79 79 00:03:06,630 --> 00:03:08,580 and you'll have a series of downloads and uploads 80 80 00:03:08,580 --> 00:03:10,100 that'll occur from your workstation 81 81 00:03:10,100 --> 00:03:11,720 to their server and back. 82 82 00:03:11,720 --> 00:03:13,930 Then it will report to you how fast or slow 83 83 00:03:13,930 --> 00:03:16,430 your connection was in terms of throughput. 84 84 00:03:16,430 --> 00:03:19,000 In this example, you can see my results indicate 85 85 00:03:19,000 --> 00:03:21,270 I have a throughput with a top download speed 86 86 00:03:21,270 --> 00:03:23,180 of 240 megabits per second, 87 87 00:03:23,180 --> 00:03:27,020 and a top upload speed of around 241 megabits per second. 88 88 00:03:27,020 --> 00:03:29,370 The problem with that is that my actual bandwidth, 89 89 00:03:29,370 --> 00:03:32,830 my theoretical, limit should be 650 megabits per second 90 90 00:03:32,830 --> 00:03:36,190 for downloads and 310 megabits per second for uploads. 91 91 00:03:36,190 --> 00:03:39,210 So why is my throughput so much less? 92 92 00:03:39,210 --> 00:03:40,910 Well, when I was doing this test, 93 93 00:03:40,910 --> 00:03:43,850 I connected to my office network using my wifi adapter 94 94 00:03:43,850 --> 00:03:46,400 and not directly connecting through a wired switch. 95 95 00:03:46,400 --> 00:03:48,090 At the same time, there's other people 96 96 00:03:48,090 --> 00:03:49,570 in the office using the connection, 97 97 00:03:49,570 --> 00:03:51,990 and all of these factors lead to a less than ideal 98 98 00:03:51,990 --> 00:03:54,780 environment and this makes my throughput much lower 99 99 00:03:54,780 --> 00:03:56,570 than my expected bandwidth. 100 100 00:03:56,570 --> 00:03:58,570 As I make different changes to my network, 101 101 00:03:58,570 --> 00:04:00,930 I can retest the throughput to see if those changes 102 102 00:04:00,930 --> 00:04:03,010 help or hurt my overall throughput. 103 103 00:04:03,010 --> 00:04:04,210 For example, if I switched 104 104 00:04:04,210 --> 00:04:05,650 from a wireless internet connection 105 105 00:04:05,650 --> 00:04:07,350 to a wired internet connection, 106 106 00:04:07,350 --> 00:04:09,030 I'll be able to see a dramatic increase 107 107 00:04:09,030 --> 00:04:10,980 in overall throughput that I wouldn't see 108 108 00:04:10,980 --> 00:04:12,880 over that wireless connection. 109 109 00:04:12,880 --> 00:04:15,890 The third metric we need to monitor is known as jitter. 110 110 00:04:15,890 --> 00:04:17,710 Jitter is the network condition that occurs 111 111 00:04:17,710 --> 00:04:20,350 when a time delay in the sending of the data packets 112 112 00:04:20,350 --> 00:04:22,580 over a network connection is occurring. 113 113 00:04:22,580 --> 00:04:24,290 Now jitter is really a big problem 114 114 00:04:24,290 --> 00:04:26,900 for any real-time applications that you may be supporting 115 115 00:04:26,900 --> 00:04:27,740 on your network. 116 116 00:04:27,740 --> 00:04:29,620 If you're doing things like video conferences 117 117 00:04:29,620 --> 00:04:32,720 and voiceover IP, and virtual desktop infrastructure, 118 118 00:04:32,720 --> 00:04:35,470 all of these are negatively affected by jitter. 119 119 00:04:35,470 --> 00:04:37,720 Basically a jitter is simply a variation 120 120 00:04:37,720 --> 00:04:39,160 in the delay of the packets. 121 121 00:04:39,160 --> 00:04:41,620 And this can cause some really strange side effects, 122 122 00:04:41,620 --> 00:04:44,130 especially for your voice and video calls. 123 123 00:04:44,130 --> 00:04:45,820 If you've ever been in a video conference 124 124 00:04:45,820 --> 00:04:47,110 and somebody starts speaking, 125 125 00:04:47,110 --> 00:04:48,510 and then all of a sudden you hear their voice 126 126 00:04:48,510 --> 00:04:50,770 start speeding up for about five or 10 seconds, 127 127 00:04:50,770 --> 00:04:52,790 and then it returns back to normal speed, 128 128 00:04:52,790 --> 00:04:55,860 that usually is because of jitter on their network. 129 129 00:04:55,860 --> 00:04:58,300 If you have a good quality of service management in place, 130 130 00:04:58,300 --> 00:05:00,220 you shouldn't experience a lot of jitter, 131 131 00:05:00,220 --> 00:05:02,560 but if you're not doing QoS properly, 132 132 00:05:02,560 --> 00:05:04,080 then jitter will occur. 133 133 00:05:04,080 --> 00:05:06,590 You see, when your network suffers from congestion, 134 134 00:05:06,590 --> 00:05:08,880 the network devices like your routers and switches 135 135 00:05:08,880 --> 00:05:11,570 are going to be unable to send the equivalent amount of traffic 136 136 00:05:11,570 --> 00:05:13,080 as what they're receiving. 137 137 00:05:13,080 --> 00:05:15,810 This causes their packet buffers to start to fill up, 138 138 00:05:15,810 --> 00:05:18,070 and eventually they'll start to drop packets 139 139 00:05:18,070 --> 00:05:20,160 if they have too much in the buffers. 140 140 00:05:20,160 --> 00:05:22,100 This is known as packet loss. 141 141 00:05:22,100 --> 00:05:24,460 Now, when this happens, your TCP packets 142 142 00:05:24,460 --> 00:05:26,610 are going to get resent, and this causes 143 143 00:05:26,610 --> 00:05:28,320 increased network load again. 144 144 00:05:28,320 --> 00:05:30,710 Now on the other hand, if the buffer begins to fill up, 145 145 00:05:30,710 --> 00:05:33,160 but then the network congestion eases up 146 146 00:05:33,160 --> 00:05:35,020 those buffers will be able to quickly send 147 147 00:05:35,020 --> 00:05:37,250 all of their contents to the destination. 148 148 00:05:37,250 --> 00:05:39,580 The destination will then try to process them all, 149 149 00:05:39,580 --> 00:05:41,610 but usually it can't do that. 150 150 00:05:41,610 --> 00:05:43,690 And this leads to delays in processing 151 151 00:05:43,690 --> 00:05:46,670 that can result in jitter on the endpoint device as well. 152 152 00:05:46,670 --> 00:05:49,040 So to prevent jitter, we want to ensure our network 153 153 00:05:49,040 --> 00:05:51,040 is using quality of service properly. 154 154 00:05:51,040 --> 00:05:52,390 We want to make sure we're categorizing 155 155 00:05:52,390 --> 00:05:54,880 and prioritizing our voice and video traffic over 156 156 00:05:54,880 --> 00:05:56,410 the other types of traffic. 157 157 00:05:56,410 --> 00:05:58,700 Also, we need to verify our network connections 158 158 00:05:58,700 --> 00:06:00,650 and our devices are large enough to support 159 159 00:06:00,650 --> 00:06:03,010 the amount of data that we're trying to transfer. 160 160 00:06:03,010 --> 00:06:04,350 As a network administrator, 161 161 00:06:04,350 --> 00:06:06,300 it's your responsibility to always monitor 162 162 00:06:06,300 --> 00:06:08,660 your network's performance and the three key metrics 163 163 00:06:08,660 --> 00:06:10,290 you always should be keeping track of 164 164 00:06:10,290 --> 00:06:13,845 are latency, bandwidth or throughput and jitter. 165 165 00:06:13,845 --> 00:06:16,428 (logo buzzing)