1
00:00:00,170 --> 00:00:01,002
In this lesson,

2
00:00:01,002 --> 00:00:02,670
we're going to talk all about performance

3
00:00:02,670 --> 00:00:05,939
metrics and how they're used to ensure network availability.

4
00:00:05,939 --> 00:00:08,070
Now, network performance metrics are a large

5
00:00:08,070 --> 00:00:09,870
part of network monitoring.

6
00:00:09,870 --> 00:00:12,210
Network performance monitoring is the end-to-end network

7
00:00:12,210 --> 00:00:14,700
monitoring of your end user experience.

8
00:00:14,700 --> 00:00:16,890
This differs from traditional monitoring though,

9
00:00:16,890 --> 00:00:19,470
because traditional monitoring is focused on performance

10
00:00:19,470 --> 00:00:22,140
between two points, like a switch and a router.

11
00:00:22,140 --> 00:00:24,180
But with network performance monitoring,

12
00:00:24,180 --> 00:00:26,700
we're going to look at the overall end user experience

13
00:00:26,700 --> 00:00:28,800
by monitoring the performance from the end user's

14
00:00:28,800 --> 00:00:30,690
workstation to the final destination

15
00:00:30,690 --> 00:00:32,159
that they're trying to reach.

16
00:00:32,159 --> 00:00:34,410
So to help us monitor network performance,

17
00:00:34,410 --> 00:00:35,790
there's really going to be three key

18
00:00:35,790 --> 00:00:37,350
metrics that we're going to use.

19
00:00:37,350 --> 00:00:40,230
These are latency, bandwidth, and jitter.

20
00:00:40,230 --> 00:00:42,570
The first metric is latency.

21
00:00:42,570 --> 00:00:44,940
Now latency is the measure of the time that it takes

22
00:00:44,940 --> 00:00:47,880
for data to reach its destination across a network.

23
00:00:47,880 --> 00:00:49,950
Usually we measure network latency

24
00:00:49,950 --> 00:00:53,430
as the round trip time from a workstation to the destination

25
00:00:53,430 --> 00:00:55,110
and back to the workstation.

26
00:00:55,110 --> 00:00:57,570
We report this time in milliseconds.

27
00:00:57,570 --> 00:01:00,030
Now, for example, let's say you opened up your command

28
00:01:00,030 --> 00:01:03,510
prompt and you enter the command ping 8.8.8.8,

29
00:01:03,510 --> 00:01:04,590
and you hit enter.

30
00:01:04,590 --> 00:01:06,308
You're going to get a response

31
00:01:06,308 --> 00:01:07,141
that tells you how long it took

32
00:01:07,141 --> 00:01:09,660
for an ICMP packet to leave your computer,

33
00:01:09,660 --> 00:01:12,600
reach the Google DNS server located at 8.8.8.8,

34
00:01:12,600 --> 00:01:15,810
and return to your computer again, in my case,

35
00:01:15,810 --> 00:01:19,980
this took an average time of 38.2 milliseconds when I did it

36
00:01:19,980 --> 00:01:22,200
for four repetitive ping requests.

37
00:01:22,200 --> 00:01:24,510
Now, it's important to measure the roundtrip delay

38
00:01:24,510 --> 00:01:25,770
for network latency

39
00:01:25,770 --> 00:01:28,830
because a computer that uses a TCP/IP network can send

40
00:01:28,830 --> 00:01:30,270
only a limited amount of data

41
00:01:30,270 --> 00:01:33,210
to its destination at one time, and then it sits

42
00:01:33,210 --> 00:01:35,730
and waits for an acknowledgement that that data was received

43
00:01:35,730 --> 00:01:38,610
before it sends out more data across the network.

44
00:01:38,610 --> 00:01:40,140
So if you have high latency

45
00:01:40,140 --> 00:01:41,659
or a long roundtrip delay,

46
00:01:41,659 --> 00:01:44,340
this can drastically slow down your overall network

47
00:01:44,340 --> 00:01:46,530
performance for your end users.

48
00:01:46,530 --> 00:01:48,450
Now, if you're seeing consistent delays

49
00:01:48,450 --> 00:01:50,820
or even just spikes in the delay time in your network,

50
00:01:50,820 --> 00:01:53,130
this could indicate a major performance issue

51
00:01:53,130 --> 00:01:54,480
that's going to be occurring.

52
00:01:54,480 --> 00:01:55,800
For regular web traffic,

53
00:01:55,800 --> 00:01:57,900
these delays aren't usually noticeable,

54
00:01:57,900 --> 00:02:00,330
but if you're using streaming video applications,

55
00:02:00,330 --> 00:02:01,770
things like Voice over IP

56
00:02:01,770 --> 00:02:03,210
or you're playing video games,

57
00:02:03,210 --> 00:02:05,430
these delays are extremely noticeable

58
00:02:05,430 --> 00:02:08,310
and they can cause a lot of problems for your end users.

59
00:02:08,310 --> 00:02:11,460
Our second metric medium monitor is known as bandwidth.

60
00:02:11,460 --> 00:02:13,290
Now, bandwidth is the maximum rate

61
00:02:13,290 --> 00:02:15,750
of data transfer across a given network.

62
00:02:15,750 --> 00:02:18,330
Now, technically, bandwidth is actually a theoretical

63
00:02:18,330 --> 00:02:19,500
concept that measures

64
00:02:19,500 --> 00:02:22,050
how much data could be transferred from a source

65
00:02:22,050 --> 00:02:24,750
to a destination under ideal conditions.

66
00:02:24,750 --> 00:02:27,180
But in reality, when we're talking about our networks in our

67
00:02:27,180 --> 00:02:29,760
connections, they're rarely operating at the perfect

68
00:02:29,760 --> 00:02:31,260
or ideal conditions.

69
00:02:31,260 --> 00:02:33,240
Therefore, we often measure something known

70
00:02:33,240 --> 00:02:35,190
as throughput instead of bandwidth

71
00:02:35,190 --> 00:02:37,050
to monitor our network performance.

72
00:02:37,050 --> 00:02:39,360
Throughput is the actual measure of data

73
00:02:39,360 --> 00:02:41,310
as it's being successfully transferred from the

74
00:02:41,310 --> 00:02:43,110
source to the destination.

75
00:02:43,110 --> 00:02:45,900
But you'll often hear people use the terms bandwidth

76
00:02:45,900 --> 00:02:47,640
and throughput interchangeably,

77
00:02:47,640 --> 00:02:49,620
not realizing there is a difference.

78
00:02:49,620 --> 00:02:52,710
Technically, bandwidth is a theoretical limit

79
00:02:52,710 --> 00:02:55,560
where throughput is the reality of what you're achieving.

80
00:02:55,560 --> 00:02:58,170
So if you want to do a bandwidth speed test

81
00:02:58,170 --> 00:03:00,960
or more accurately a throughput test for your network,

82
00:03:00,960 --> 00:03:04,043
you can go to something like speedtest.net and click on go,

83
00:03:04,043 --> 00:03:05,730
and you'll have a series of downloads

84
00:03:05,730 --> 00:03:07,860
and uploads that'll occur from your workstation

85
00:03:07,860 --> 00:03:09,480
to their server and back.

86
00:03:09,480 --> 00:03:11,400
Then it'll report to you how fast

87
00:03:11,400 --> 00:03:14,160
or slow your connection was in terms of throughput.

88
00:03:14,160 --> 00:03:17,010
In this example, you can see my results indicate I have a

89
00:03:17,010 --> 00:03:19,020
throughput with a top download speed

90
00:03:19,020 --> 00:03:21,030
of 240 megabits per second

91
00:03:21,030 --> 00:03:24,750
and a top upload speed of around 241 megabits per second.

92
00:03:24,750 --> 00:03:27,120
The problem with that is that my actual bandwidth,

93
00:03:27,120 --> 00:03:30,540
my theoretical limit should be 650 megabits per second

94
00:03:30,540 --> 00:03:33,930
for downloads and 310 megabits per second for uploads.

95
00:03:33,930 --> 00:03:36,960
So why is my throughput so much less?

96
00:03:36,960 --> 00:03:39,210
Well, when I was doing this test, I connected

97
00:03:39,210 --> 00:03:41,610
to my office network using my wifi adapter

98
00:03:41,610 --> 00:03:44,130
and not directly connecting through a wired switch.

99
00:03:44,130 --> 00:03:46,530
At the same time, there's other people in the office using

100
00:03:46,530 --> 00:03:48,780
the connection and all these factors lead

101
00:03:48,780 --> 00:03:50,400
to a less than ideal environment,

102
00:03:50,400 --> 00:03:52,590
and this makes my throughput much lower than

103
00:03:52,590 --> 00:03:54,330
my expected bandwidth.

104
00:03:54,330 --> 00:03:56,310
As I make different changes to my network,

105
00:03:56,310 --> 00:03:59,040
I can retest the throughput to see if those changes help

106
00:03:59,040 --> 00:04:00,780
or hurt my overall throughput.

107
00:04:00,780 --> 00:04:03,390
For example, if I switch from a wireless internet connection

108
00:04:03,390 --> 00:04:05,550
to a wired internet connection, I'll be able

109
00:04:05,550 --> 00:04:07,950
to see a dramatic increase in overall throughput

110
00:04:07,950 --> 00:04:10,283
that I wouldn't see over that wireless connection.

111
00:04:10,283 --> 00:04:13,620
The third metric we need to monitor is known as jitter.

112
00:04:13,620 --> 00:04:15,000
Jitter is the network condition

113
00:04:15,000 --> 00:04:16,980
that occurs when a time delay in the sending

114
00:04:16,980 --> 00:04:20,279
of the data packets over a network connection is occurring.

115
00:04:20,279 --> 00:04:22,019
Now jitter is really a big problem

116
00:04:22,019 --> 00:04:23,670
for any real time applications

117
00:04:23,670 --> 00:04:25,470
that you may be supporting on your network.

118
00:04:25,470 --> 00:04:27,390
If you're doing things like video conferences

119
00:04:27,390 --> 00:04:28,530
and Voice over IP

120
00:04:28,530 --> 00:04:30,720
and virtual desktop infrastructure, all

121
00:04:30,720 --> 00:04:33,210
of these are negatively affected by jitter.

122
00:04:33,210 --> 00:04:35,610
Basically, a jitter is simply a variation in

123
00:04:35,610 --> 00:04:36,930
the delay of the packets.

124
00:04:36,930 --> 00:04:39,330
And this can cause some really strange side effects,

125
00:04:39,330 --> 00:04:41,880
especially for your voice and video calls.

126
00:04:41,880 --> 00:04:43,560
If you've ever been in a video conference

127
00:04:43,560 --> 00:04:44,880
and somebody starts speaking

128
00:04:44,880 --> 00:04:46,470
and then all of a sudden you hear their voice starts

129
00:04:46,470 --> 00:04:48,197
speeding up for about five or 10 seconds

130
00:04:48,197 --> 00:04:51,420
and then it returns back to normal speed, that usually is

131
00:04:51,420 --> 00:04:53,610
because of jitter on their network.

132
00:04:53,610 --> 00:04:56,040
If you have a good quality of service management in place,

133
00:04:56,040 --> 00:04:57,990
you shouldn't experience a lot of jitter.

134
00:04:57,990 --> 00:05:00,300
But if you're not doing QoS properly,

135
00:05:00,300 --> 00:05:01,830
then jitter will occur.

136
00:05:01,830 --> 00:05:04,320
You see, when your network suffers from congestion,

137
00:05:04,320 --> 00:05:05,940
the network devices like your routers

138
00:05:05,940 --> 00:05:07,560
and switches are going to be unable

139
00:05:07,560 --> 00:05:08,933
to send the equivalent amount of traffic

140
00:05:08,933 --> 00:05:10,496
as what they're receiving.

141
00:05:10,496 --> 00:05:12,955
This causes their packet buffers to start to fill up,

142
00:05:12,955 --> 00:05:14,730
and eventually they'll start

143
00:05:14,730 --> 00:05:17,910
to drop packets if they have too much in the buffers.

144
00:05:17,910 --> 00:05:19,860
This is known as packet loss.

145
00:05:19,860 --> 00:05:21,030
Now, when this happens,

146
00:05:21,030 --> 00:05:23,013
your TCP packets are going to get reset,

147
00:05:23,013 --> 00:05:26,040
and this causes increased network load again.

148
00:05:26,040 --> 00:05:28,440
Now, on the other hand, if the buffer begins to fill up,

149
00:05:28,440 --> 00:05:30,900
but then the network congestion eases up,

150
00:05:30,900 --> 00:05:33,030
those buffers will be able to quickly send all

151
00:05:33,030 --> 00:05:35,010
of their contents to the destination.

152
00:05:35,010 --> 00:05:37,320
The destination will then try to process them all,

153
00:05:37,320 --> 00:05:39,480
but usually it can't do that.

154
00:05:39,480 --> 00:05:41,430
And this leads to delays in processing

155
00:05:41,430 --> 00:05:44,430
that can result in jitter on the endpoint device as well.

156
00:05:44,430 --> 00:05:45,660
So to prevent jitter,

157
00:05:45,660 --> 00:05:47,160
we want to ensure our network is using

158
00:05:47,160 --> 00:05:48,810
quality of service properly.

159
00:05:48,810 --> 00:05:50,130
We want to make sure we're categorizing

160
00:05:50,130 --> 00:05:51,300
and prioritizing our voice

161
00:05:51,300 --> 00:05:54,150
and video traffic over the other types of traffic.

162
00:05:54,150 --> 00:05:56,580
Also, we need to verify our network connections and our

163
00:05:56,580 --> 00:05:58,695
devices are large enough to support the amount of data

164
00:05:58,695 --> 00:06:00,437
that we're trying to transfer.

165
00:06:00,437 --> 00:06:03,240
As a network administrator, it's your responsibility

166
00:06:03,240 --> 00:06:05,250
to always monitor your network's performance.

167
00:06:05,250 --> 00:06:07,650
And the three key metrics you always should be keeping track

168
00:06:07,650 --> 00:06:11,237
of are latency, bandwidth or throughput, and jitter.