WEBVTT

1
00:00:00.160 --> 00:00:03.799
<v Speaker 1>Welcome to the deep dive. Today, we're getting into something

2
00:00:03.879 --> 00:00:08.880
<v Speaker 1>fundamental but often totally invisible, network synchronization. And we're not

3
00:00:08.960 --> 00:00:11.400
<v Speaker 1>just talking about you know, knowing it's lunchtime. We mean

4
00:00:12.000 --> 00:00:15.880
<v Speaker 1>hyper precise time down to nanoseconds that underpins things like

5
00:00:15.919 --> 00:00:17.679
<v Speaker 1>five G automated trading.

6
00:00:18.359 --> 00:00:21.519
<v Speaker 2>The works. It really does hold it all together. Our

7
00:00:21.559 --> 00:00:23.920
<v Speaker 2>mission today really is to get a handle on the

8
00:00:23.960 --> 00:00:26.039
<v Speaker 2>basics of this digital time. You know, what are the

9
00:00:26.079 --> 00:00:30.199
<v Speaker 2>different kinds of zync frequency, phase time, and how do

10
00:00:30.239 --> 00:00:33.560
<v Speaker 2>we actually get this level of precision across huge networks

11
00:00:33.600 --> 00:00:36.200
<v Speaker 2>down to the nanosecond. And there's a key point in

12
00:00:36.240 --> 00:00:39.320
<v Speaker 2>the source material too. When this stuff fails, it's sneaky.

13
00:00:39.600 --> 00:00:42.439
<v Speaker 1>Yeah, that really jumped out. It says timing failures often

14
00:00:42.439 --> 00:00:43.920
<v Speaker 1>look like something else entirely.

15
00:00:43.679 --> 00:00:46.039
<v Speaker 2>At first exactly. I remember back in my circuit board

16
00:00:46.039 --> 00:00:49.399
<v Speaker 2>design days, a clock problem could totally look like a

17
00:00:49.439 --> 00:00:52.159
<v Speaker 2>software bug or just weird logic makes it incredibly hard

18
00:00:52.159 --> 00:00:54.600
<v Speaker 2>to track down. Now, scale that up from one board

19
00:00:54.679 --> 00:00:58.799
<v Speaker 2>to say, a whole continence network, multiple vendors, different gear

20
00:00:58.960 --> 00:01:01.280
<v Speaker 2>a few microseconds off could look like a bad route,

21
00:01:01.320 --> 00:01:03.079
<v Speaker 2>a broken process. Really tough.

22
00:01:03.280 --> 00:01:06.920
<v Speaker 1>Okay, so let's maybe start at the beginning time seems simple, yeah, right,

23
00:01:07.079 --> 00:01:10.920
<v Speaker 1>but trying to get everyone on the same page globally, Yeah,

24
00:01:10.959 --> 00:01:12.120
<v Speaker 1>that I complicated fast.

25
00:01:12.120 --> 00:01:15.319
<v Speaker 2>Oh absolutely. I mean historically, every town just set its

26
00:01:15.319 --> 00:01:18.359
<v Speaker 2>clock by the sun. Noon was noon locally. Worked fine

27
00:01:18.680 --> 00:01:22.640
<v Speaker 2>until the trains came along. Suddenly you needed timetables that

28
00:01:22.680 --> 00:01:26.120
<v Speaker 2>worked across different zones. You couldn't have a train leaving

29
00:01:26.159 --> 00:01:28.959
<v Speaker 2>one town at two pm and arriving somewhere else, you know,

30
00:01:29.000 --> 00:01:32.640
<v Speaker 2>before two pm according to their clock. That push, that

31
00:01:32.840 --> 00:01:36.280
<v Speaker 2>need for consistency led to standardizing time ach wor Greenwich

32
00:01:36.359 --> 00:01:38.519
<v Speaker 2>Meantime GMT back in eighteen eighty four.

33
00:01:38.640 --> 00:01:42.920
<v Speaker 1>Right, GMT. But today the standard is Coordinated Universal Time UTC.

34
00:01:43.680 --> 00:01:47.640
<v Speaker 1>What's the practical difference for most people or for these networks.

35
00:01:47.359 --> 00:01:49.400
<v Speaker 2>Well, the core reference is different. UTC is what we

36
00:01:49.439 --> 00:01:52.599
<v Speaker 2>all use. Yeah, but it's based on International Atomic Time TAI.

37
00:01:52.840 --> 00:01:55.680
<v Speaker 2>TI comes from hundreds of atomic clocks around the world.

38
00:01:55.680 --> 00:01:59.079
<v Speaker 2>It's incredibly stable, just ticks a long perfectly, well almost perfectly.

39
00:01:59.079 --> 00:02:02.599
<v Speaker 2>It's continuous. But UTC is what we call discontinuous. We

40
00:02:02.640 --> 00:02:04.159
<v Speaker 2>sometimes have to add leap seconds.

41
00:02:04.239 --> 00:02:07.439
<v Speaker 1>Ah, yes, leap seconds the bane of sysadminin's everywhere.

42
00:02:07.680 --> 00:02:11.439
<v Speaker 2>Huh, exactly, They exist because the Earth's rotation isn't perfectly regular.

43
00:02:11.520 --> 00:02:14.400
<v Speaker 2>It wobbles a bit, so the IIRS, that's the International

44
00:02:14.479 --> 00:02:18.479
<v Speaker 2>Earth Rotation Service, they manage these leap seconds. The goal

45
00:02:18.560 --> 00:02:21.360
<v Speaker 2>is to keep UTC within zero point nine seconds of

46
00:02:21.400 --> 00:02:24.560
<v Speaker 2>the actual solar day, you know, based on Earth's spin.

47
00:02:25.039 --> 00:02:27.599
<v Speaker 1>Okay, so if UTC is the gold standard, how do

48
00:02:27.680 --> 00:02:31.680
<v Speaker 1>we know what the real official UTC is like right

49
00:02:31.759 --> 00:02:32.319
<v Speaker 1>this second.

50
00:02:32.400 --> 00:02:35.919
<v Speaker 2>That's the fascinating part. You don't not perfectly in real time.

51
00:02:36.159 --> 00:02:38.599
<v Speaker 2>Any time signal you get right now is an approximation,

52
00:02:38.680 --> 00:02:40.960
<v Speaker 2>a very very good one hopefully, but still an approximation.

53
00:02:41.360 --> 00:02:45.560
<v Speaker 2>The actual single official UTC value. It's only calculated after

54
00:02:45.599 --> 00:02:48.439
<v Speaker 2>the month ends. They gather data from all those atomic clocks,

55
00:02:48.439 --> 00:02:51.759
<v Speaker 2>globally process it, and then the BPM, the International Bureau

56
00:02:51.800 --> 00:02:54.479
<v Speaker 2>of Weights and Measures, publishes the definitive value in something

57
00:02:54.520 --> 00:02:57.039
<v Speaker 2>called circular t, usually a couple of weeks late.

58
00:02:57.240 --> 00:03:00.439
<v Speaker 1>So the absolute truth about this very nanosecond we won't

59
00:03:00.439 --> 00:03:01.240
<v Speaker 1>know it for weeks.

60
00:03:01.439 --> 00:03:03.759
<v Speaker 2>Pretty much kind of changes how you think about real time,

61
00:03:03.800 --> 00:03:04.479
<v Speaker 2>doesn't it.

62
00:03:04.479 --> 00:03:07.520
<v Speaker 1>It really does? Okay? Knowing the official time is always

63
00:03:07.639 --> 00:03:11.039
<v Speaker 1>a bit delayed, that's a big takeaway. Now let's talk terminology.

64
00:03:11.639 --> 00:03:14.879
<v Speaker 1>Synchronization gets thrown around a lot, but the sources are clear.

65
00:03:15.039 --> 00:03:16.759
<v Speaker 1>There are three distinct types.

66
00:03:17.000 --> 00:03:19.879
<v Speaker 2>Yeah, getting these straight is super important if you're dealing

67
00:03:19.960 --> 00:03:22.960
<v Speaker 2>with high performance networks. Let's maybe use an orchestra analogy.

68
00:03:23.000 --> 00:03:26.800
<v Speaker 1>Okay, sound good. Let's start with frequency synchronization. What's that about.

69
00:03:27.000 --> 00:03:30.479
<v Speaker 2>Frequency sync is about the rate of the clock, the

70
00:03:30.520 --> 00:03:34.319
<v Speaker 2>tempo maybe, or the pitch in music. So in the orchestra,

71
00:03:34.439 --> 00:03:37.560
<v Speaker 2>it's making sure two violins are playing the exact same

72
00:03:38.039 --> 00:03:41.080
<v Speaker 2>a you know, four hundred and forty hertz, four hundred

73
00:03:41.080 --> 00:03:44.360
<v Speaker 2>and forty oscillations per second. In a network device, it

74
00:03:44.439 --> 00:03:47.240
<v Speaker 2>means making sure its internal oscillator is ticking at the

75
00:03:47.240 --> 00:03:51.000
<v Speaker 2>correct speed, its nominal frequency. We can use external sources

76
00:03:51.000 --> 00:03:53.159
<v Speaker 2>like SINCSA, which we'll get to to make that much

77
00:03:53.199 --> 00:03:55.960
<v Speaker 2>more accurate. Instead of maybe being off by say four

78
00:03:56.039 --> 00:03:58.240
<v Speaker 2>point six parts per million, we can get down to

79
00:03:58.280 --> 00:04:01.840
<v Speaker 2>like sixteen parts per billion, much tighter control over the rate.

80
00:04:02.039 --> 00:04:04.439
<v Speaker 1>Okay, so frequencies of the rate, the speed of the ticking.

81
00:04:04.680 --> 00:04:06.479
<v Speaker 1>What about phase synchronization? Then?

82
00:04:06.759 --> 00:04:10.199
<v Speaker 2>Facinc is about aligning the tick itself, making sure the

83
00:04:10.240 --> 00:04:13.759
<v Speaker 2>ticks happen at the exact same instant. Back to the orchestra.

84
00:04:14.039 --> 00:04:17.600
<v Speaker 2>It's the conductor ensuring everyone hits the downbeat together right

85
00:04:17.639 --> 00:04:20.839
<v Speaker 2>on time. Phase is about the relative offset between clocks,

86
00:04:21.240 --> 00:04:25.600
<v Speaker 2>usually measured in tiny fractions of a second, milliseconds, microseconds, nanoseconds.

87
00:04:25.680 --> 00:04:27.480
<v Speaker 2>It's about agreeing on when now is.

88
00:04:27.959 --> 00:04:30.199
<v Speaker 1>And the sources gave a really good, kind of stark

89
00:04:30.319 --> 00:04:34.759
<v Speaker 1>example of why phase matters so much in industry factory automation.

90
00:04:34.959 --> 00:04:37.920
<v Speaker 2>Oh yeah, that's a perfect illustration. Imagine you've got two

91
00:04:38.000 --> 00:04:40.720
<v Speaker 2>robots passing a part between them. They're not using cameras,

92
00:04:40.759 --> 00:04:44.439
<v Speaker 2>they're just timed. Robot A let's go at say start

93
00:04:44.519 --> 00:04:47.759
<v Speaker 2>plus point four over zero seconds. Robot B needs to

94
00:04:47.759 --> 00:04:49.959
<v Speaker 2>grab it at exactly start plus point four zero zero

95
00:04:50.120 --> 00:04:52.879
<v Speaker 2>seconds for that to work. Their idea of when start

96
00:04:52.920 --> 00:04:55.040
<v Speaker 2>plus zero point zero zero theory happen has to be

97
00:04:55.079 --> 00:04:57.959
<v Speaker 2>absolutely identical. Now, their facecinc is a bit loose, maybe

98
00:04:58.000 --> 00:05:00.639
<v Speaker 2>only accurate to fifty milliseconds. Robot A might let go

99
00:05:00.720 --> 00:05:03.720
<v Speaker 2>fifty milliseconds before Robot B is ready, and bam, part

100
00:05:03.759 --> 00:05:06.240
<v Speaker 2>hits the floor, a physical failure caused by a tiny,

101
00:05:06.279 --> 00:05:07.360
<v Speaker 2>tiny timing error.

102
00:05:07.399 --> 00:05:10.639
<v Speaker 1>Wow, so fifty milliseconds is enough to cause real physical problem.

103
00:05:10.639 --> 00:05:12.000
<v Speaker 2>Absolutely shows you the stakes.

104
00:05:12.240 --> 00:05:15.759
<v Speaker 1>That factory example really brings it home. Milliseconds matter physically,

105
00:05:16.399 --> 00:05:19.120
<v Speaker 1>but looking at the big data networks, the requirements are

106
00:05:19.120 --> 00:05:23.800
<v Speaker 1>pushing into micro seconds, even nanoseconds. Why such extreme precision

107
00:05:24.120 --> 00:05:26.040
<v Speaker 1>across whole continents?

108
00:05:26.199 --> 00:05:28.639
<v Speaker 2>Right, It's not just factories. There are really three big

109
00:05:28.680 --> 00:05:31.560
<v Speaker 2>areas pushing this need for tighter and tighter timing.

110
00:05:31.600 --> 00:05:34.279
<v Speaker 1>Okay, where should we start? Maybe one? We can perceive

111
00:05:34.319 --> 00:05:35.800
<v Speaker 1>directly audio and video.

112
00:05:35.959 --> 00:05:40.600
<v Speaker 2>Yeah, av sync. Humans are surprisingly sensitive to this. Research

113
00:05:40.639 --> 00:05:42.560
<v Speaker 2>shows if the audio is ahead of the video by

114
00:05:42.720 --> 00:05:45.279
<v Speaker 2>just forty milliseconds that's less than two frames of video,

115
00:05:45.360 --> 00:05:47.920
<v Speaker 2>about twenty percent of people will notice it it feels wrong.

116
00:05:48.319 --> 00:05:53.079
<v Speaker 2>So for professional broadcast streaming movies, they use specific timing

117
00:05:53.120 --> 00:05:56.439
<v Speaker 2>profiles like SMPTE twenty five nine to two built on

118
00:05:56.480 --> 00:05:58.879
<v Speaker 2>PTP to keep audio and video locked tight.

119
00:05:59.000 --> 00:06:01.480
<v Speaker 1>Okay, so av is on one. What about finance? You

120
00:06:01.480 --> 00:06:03.000
<v Speaker 1>mentioned high frequency trading earlier.

121
00:06:03.160 --> 00:06:06.160
<v Speaker 2>Definitely a huge driver. This really kicked into high gear

122
00:06:06.199 --> 00:06:09.519
<v Speaker 2>with a regulation called MIFIED two from the EU back

123
00:06:09.519 --> 00:06:13.279
<v Speaker 2>in twenty fourteen. It basically mandated that all high frequency

124
00:06:13.279 --> 00:06:16.959
<v Speaker 2>trading transactions had to have super accurate time stamps. Traceable

125
00:06:17.000 --> 00:06:21.160
<v Speaker 2>time stamps. We're talking precision way beyond what older protocols

126
00:06:21.199 --> 00:06:24.959
<v Speaker 2>like MTP could reliably deliver. It became a legal necessity

127
00:06:24.959 --> 00:06:28.800
<v Speaker 2>for transparency, for proving when trades happened, preventing manipulation, they

128
00:06:28.839 --> 00:06:32.839
<v Speaker 2>needed microsecond Sometimes better accuracy makes sense.

129
00:06:33.360 --> 00:06:37.000
<v Speaker 1>Legal compliance often pushes technology, but the sources suggests the

130
00:06:37.040 --> 00:06:40.720
<v Speaker 1>biggest driver, the one really pushing phasinc. Everywhere, is mobile

131
00:06:40.759 --> 00:06:42.000
<v Speaker 1>networks five G.

132
00:06:42.120 --> 00:06:45.079
<v Speaker 2>Specifically, without a doubt, five G is the main engine

133
00:06:45.120 --> 00:06:48.560
<v Speaker 2>right now for widespread phase synchronization, deployment and transport networks.

134
00:06:48.759 --> 00:06:51.800
<v Speaker 2>The core reason is a technology called time division duplex

135
00:06:51.920 --> 00:06:54.800
<v Speaker 2>or TDD. In TDD, a base station uses the same

136
00:06:54.879 --> 00:06:57.680
<v Speaker 2>chunk of radio frequency to both transmit and receive. It

137
00:06:57.759 --> 00:07:00.319
<v Speaker 2>just switches really fast between the two. Now, imagine two

138
00:07:00.319 --> 00:07:02.519
<v Speaker 2>base stations near each other. If one is transmitting while

139
00:07:02.519 --> 00:07:04.600
<v Speaker 2>its neighbor is trying to receive on that same frequency,

140
00:07:04.959 --> 00:07:07.120
<v Speaker 2>you get massive interference. They jam each other.

141
00:07:07.519 --> 00:07:10.360
<v Speaker 1>Uh okay. So they have to coordinate very very carefully

142
00:07:10.480 --> 00:07:12.639
<v Speaker 1>when they transmit and when they listen exactly.

143
00:07:12.680 --> 00:07:16.800
<v Speaker 2>They need extremely tight phase alignment. The requirement is pretty stunning.

144
00:07:17.160 --> 00:07:19.759
<v Speaker 2>The time difference between any two neighboring base stations has

145
00:07:19.759 --> 00:07:22.639
<v Speaker 2>to be less than three microseconds, and the way networks

146
00:07:22.680 --> 00:07:25.720
<v Speaker 2>achieve that is by making sure every base station across

147
00:07:25.759 --> 00:07:29.480
<v Speaker 2>the entire network is synchronized to the master UTC reference

148
00:07:29.519 --> 00:07:32.480
<v Speaker 2>clock to within plus or minus one point five microseconds.

149
00:07:32.759 --> 00:07:35.519
<v Speaker 2>If everyone stays within that one point five microsecond window

150
00:07:35.560 --> 00:07:38.959
<v Speaker 2>relative to UTC, then any two neighbors will automatically be

151
00:07:39.040 --> 00:07:40.800
<v Speaker 2>within three microseconds of each other.

152
00:07:40.800 --> 00:07:43.639
<v Speaker 1>Plus or minus one point five microseconds. Wow, that's the

153
00:07:43.720 --> 00:07:45.160
<v Speaker 1>tolerance across the whole system.

154
00:07:45.279 --> 00:07:46.360
<v Speaker 2>Tolerance it's demanding.

155
00:07:46.480 --> 00:07:49.279
<v Speaker 1>Okay, so we understand the need plus or minus one

156
00:07:49.319 --> 00:07:52.519
<v Speaker 1>point five microseconds for five G, even tighter for finance

157
00:07:52.560 --> 00:07:56.560
<v Speaker 1>in some cases, How do networks actually get this timing

158
00:07:56.639 --> 00:08:00.879
<v Speaker 1>signal and then distribute it reliably? Where does it originate?

159
00:08:01.079 --> 00:08:05.720
<v Speaker 2>Well, the ultimate source, the primary reference time clocks or prtcs.

160
00:08:06.439 --> 00:08:10.920
<v Speaker 2>Those are generally the Global Navigation Satellite Systems GNSS, So

161
00:08:11.000 --> 00:08:14.160
<v Speaker 2>think GPS, which is the US system, gel NASS from Russia,

162
00:08:14.240 --> 00:08:18.000
<v Speaker 2>Galileo from Europe, bay DO from China. They are, in essence,

163
00:08:18.040 --> 00:08:22.120
<v Speaker 2>constellations of atomic clocks orbiting the Earth. They constantly broadcast

164
00:08:22.199 --> 00:08:25.680
<v Speaker 2>signals that include very precise timing information. Receivers on the

165
00:08:25.680 --> 00:08:27.759
<v Speaker 2>ground pick these up and can figure out their position,

166
00:08:27.839 --> 00:08:30.879
<v Speaker 2>and crucially for us, the current precise time. Got it?

167
00:08:30.920 --> 00:08:34.159
<v Speaker 1>So the time comes from space basically. Then once a

168
00:08:34.200 --> 00:08:36.799
<v Speaker 1>receiver on the ground has that signal, how does it

169
00:08:36.840 --> 00:08:40.559
<v Speaker 1>get shared across say miles of fiber optic cable in

170
00:08:40.600 --> 00:08:43.799
<v Speaker 1>the finance port network. What tools do network designers use?

171
00:08:43.960 --> 00:08:46.960
<v Speaker 2>There are two main specialized methods used often in combination.

172
00:08:47.039 --> 00:08:49.679
<v Speaker 2>The first one is called synchronous ethernet or sink.

173
00:08:49.679 --> 00:08:51.000
<v Speaker 1>Okay, sink E. What's this role?

174
00:08:51.240 --> 00:08:55.039
<v Speaker 2>Sink E is all about frequency synchronization, remember the rate

175
00:08:55.080 --> 00:08:58.279
<v Speaker 2>of the clock. It's actually built into the physical layer

176
00:08:58.360 --> 00:09:01.720
<v Speaker 2>of the ethernet connection, kind of like how older technologies

177
00:09:01.759 --> 00:09:05.879
<v Speaker 2>like SDH or sonnet handled frequency. It allows network devices

178
00:09:05.919 --> 00:09:09.440
<v Speaker 2>to pass along a very stable frequency reference directly over

179
00:09:09.480 --> 00:09:13.120
<v Speaker 2>the fiberlink itself, without needing special timing packets or relying

180
00:09:13.200 --> 00:09:16.559
<v Speaker 2>on software higher up. So it's very reliable, very predictable

181
00:09:16.600 --> 00:09:20.080
<v Speaker 2>for keeping the rate stable across the network carrier grade frequency.

182
00:09:20.360 --> 00:09:23.960
<v Speaker 1>Okay, so SYNC nails the frequency. What about the actual

183
00:09:24.000 --> 00:09:26.559
<v Speaker 1>time of day, the phase alignment down to microseconds. That's

184
00:09:26.600 --> 00:09:28.200
<v Speaker 1>the other one. PTP exactly.

185
00:09:28.240 --> 00:09:31.799
<v Speaker 2>PTP the precision time protocol that's defined by IE fifteen

186
00:09:31.840 --> 00:09:35.600
<v Speaker 2>eighty eight PTP is specifically designed to distribute precise phase

187
00:09:35.639 --> 00:09:39.240
<v Speaker 2>and time synchronization over packet networks. Like standard ethernet networks,

188
00:09:39.600 --> 00:09:42.919
<v Speaker 2>it aims for microsecond level accuracy, sometimes even better. The

189
00:09:43.000 --> 00:09:45.240
<v Speaker 2>key thing that makes PTP so much better than older

190
00:09:45.279 --> 00:09:48.360
<v Speaker 2>protocols like NTP is its use of hardware time stamping.

191
00:09:48.559 --> 00:09:50.080
<v Speaker 1>Hardware time stamping what does that mean?

192
00:09:50.360 --> 00:09:53.080
<v Speaker 2>It means the time stamps marking when a PTP timing

193
00:09:53.120 --> 00:09:56.600
<v Speaker 2>packet arrives or departs, are applied right at the network

194
00:09:56.600 --> 00:09:59.559
<v Speaker 2>interface card as close to the physical wire as possible.

195
00:10:00.039 --> 00:10:02.320
<v Speaker 2>If you rely on the main CPU or the operating

196
00:10:02.320 --> 00:10:05.279
<v Speaker 2>system to do the time stamping, you introduce all sorts

197
00:10:05.279 --> 00:10:09.200
<v Speaker 2>of delays and variability jitter that kills your accuracy. PTP

198
00:10:09.399 --> 00:10:13.279
<v Speaker 2>with hardware support bypasses a lot of that software unpredictability.

199
00:10:13.399 --> 00:10:15.279
<v Speaker 1>Right, get the time stamp as close to the physical

200
00:10:15.320 --> 00:10:19.440
<v Speaker 1>event as possible makes sense. So SYNCY for frequency stability,

201
00:10:19.519 --> 00:10:23.399
<v Speaker 1>PTP for phase and time accuracy. How do operators get

202
00:10:23.399 --> 00:10:26.000
<v Speaker 1>the absolute best result? Do they choose one or the other?

203
00:10:26.279 --> 00:10:29.240
<v Speaker 2>Usually for the most demanding applications like five G, they

204
00:10:29.320 --> 00:10:32.039
<v Speaker 2>use both together. It's often called hybrid mode. They use

205
00:10:32.080 --> 00:10:34.759
<v Speaker 2>sync along constantly on the physical layer to provide that

206
00:10:34.919 --> 00:10:38.639
<v Speaker 2>rock solid, stable frequency foundation, and then they run PTP

207
00:10:38.799 --> 00:10:41.399
<v Speaker 2>on top of that stable frequency to distribute the precise

208
00:10:41.480 --> 00:10:44.720
<v Speaker 2>phase and time information. This combination gives you the best

209
00:10:44.720 --> 00:10:47.639
<v Speaker 2>of both worlds, the stability of SYNC and the accuracy

210
00:10:47.639 --> 00:10:51.000
<v Speaker 2>of PTP. It's generally considered the gold standard for carrier

211
00:10:51.039 --> 00:10:54.639
<v Speaker 2>networks define inspects like the itut G point eight two

212
00:10:54.639 --> 00:10:59.080
<v Speaker 2>seven five point one profile for telecom. It provides deterministic performance.

213
00:10:59.399 --> 00:11:01.720
<v Speaker 1>Okay, so hybrid mode seems like the way to go.

214
00:11:02.320 --> 00:11:05.399
<v Speaker 1>But even with the best protocols, the network itself can

215
00:11:05.399 --> 00:11:09.000
<v Speaker 1>fight back, right. The sources mentioned packet delay, variation, jitter,

216
00:11:09.399 --> 00:11:12.360
<v Speaker 1>and something called asymmetry as the main enemy. So let's

217
00:11:12.360 --> 00:11:13.360
<v Speaker 1>focus on asymmetry.

218
00:11:13.399 --> 00:11:16.679
<v Speaker 2>What is that, ah, asymmetry. Yes, that's a really tricky

219
00:11:16.720 --> 00:11:19.360
<v Speaker 2>one for PTP. It's kind of the silent killer of

220
00:11:19.480 --> 00:11:23.399
<v Speaker 2>timing accuracy. See PTP works out the time it takes

221
00:11:23.399 --> 00:11:25.440
<v Speaker 2>for a packet to travel from the master clock to

222
00:11:25.480 --> 00:11:28.480
<v Speaker 2>the slave clock by measuring the total round trip time

223
00:11:28.559 --> 00:11:32.159
<v Speaker 2>and then dividing by two. It fundamentally assumes that the

224
00:11:32.200 --> 00:11:35.320
<v Speaker 2>path delay from master to slave is exactly the same

225
00:11:35.519 --> 00:11:37.600
<v Speaker 2>as the path delay from slave back to master.

226
00:11:37.799 --> 00:11:40.480
<v Speaker 1>AH Okay, it assumes the journey takes the same amount

227
00:11:40.519 --> 00:11:42.159
<v Speaker 1>of time in both directions precisely.

228
00:11:42.399 --> 00:11:45.600
<v Speaker 2>Asymmetry is simply when that assumption is wrong, when the

229
00:11:45.679 --> 00:11:48.720
<v Speaker 2>forward path delay is different from the reverse path delay.

230
00:11:48.799 --> 00:11:49.519
<v Speaker 1>What could cause that?

231
00:11:49.639 --> 00:11:53.320
<v Speaker 2>Yeah, different routs exactly. Maybe the packets go out via

232
00:11:53.440 --> 00:11:55.840
<v Speaker 2>one set of routers and fibers but come back via

233
00:11:56.000 --> 00:11:59.559
<v Speaker 2>completely different set due to network routing decisions. Or maybe

234
00:11:59.559 --> 00:12:02.080
<v Speaker 2>the five verer length itself is physically different in one

235
00:12:02.080 --> 00:12:05.080
<v Speaker 2>direction versus the other in some older setups. Or maybe

236
00:12:05.080 --> 00:12:09.000
<v Speaker 2>there's traffic congestion affecting delays only in one direction. Lots

237
00:12:09.000 --> 00:12:10.039
<v Speaker 2>of potential causes.

238
00:12:10.120 --> 00:12:11.600
<v Speaker 1>Why is that so bad for PTP?

239
00:12:12.120 --> 00:12:15.200
<v Speaker 2>Because of what some call the golden rule of packet timing,

240
00:12:15.679 --> 00:12:18.399
<v Speaker 2>half of the total path asymmetry shows up directly as

241
00:12:18.399 --> 00:12:21.440
<v Speaker 2>a constant time error a phase offset at the slave clock.

242
00:12:21.960 --> 00:12:25.559
<v Speaker 2>So if your network path has one hundred nanoseconds of asymmetry,

243
00:12:25.639 --> 00:12:27.919
<v Speaker 2>meaning the trip one way is one hundred thens longer

244
00:12:27.960 --> 00:12:30.399
<v Speaker 2>than the other way, your slave clock will be permanently

245
00:12:30.440 --> 00:12:34.399
<v Speaker 2>wrong by fifty nanoseconds. PDP can't easily detect or correct

246
00:12:34.440 --> 00:12:35.200
<v Speaker 2>for that on its own.

247
00:12:35.360 --> 00:12:38.320
<v Speaker 1>Wow, fifty nanoseconds just baked in his error. Okay, that's

248
00:12:38.320 --> 00:12:40.559
<v Speaker 1>a huge deal when the total budget is only, say,

249
00:12:40.799 --> 00:12:43.559
<v Speaker 1>fifteen hundred nanoseconds. Yeah, so that's an internal network problem.

250
00:12:43.600 --> 00:12:46.200
<v Speaker 1>What about the sorts itself. We rely heavily on GNSS

251
00:12:46.200 --> 00:12:47.600
<v Speaker 1>those satellites. Are they vulnerable?

252
00:12:47.720 --> 00:12:51.559
<v Speaker 2>Oh? Absolutely, that's a major concern. GENUSA signals are very

253
00:12:51.559 --> 00:12:53.759
<v Speaker 2>weak by the time they reach the ground. This makes

254
00:12:53.799 --> 00:12:58.399
<v Speaker 2>them susceptible to jamming, basically overpowering the signal with noise

255
00:12:58.440 --> 00:13:01.039
<v Speaker 2>so the receiver can't lock on. That's denial of service.

256
00:13:01.759 --> 00:13:05.120
<v Speaker 2>Even more worrying, perhaps, is spoofing. That's when an attacker

257
00:13:05.159 --> 00:13:08.919
<v Speaker 2>transmits fake GNSS signals to trick the receiver into calculating

258
00:13:08.960 --> 00:13:10.720
<v Speaker 2>the wrong time or position.

259
00:13:10.679 --> 00:13:13.519
<v Speaker 1>So some could potentially feed incorrect time into the network

260
00:13:13.559 --> 00:13:14.159
<v Speaker 1>at its source.

261
00:13:14.399 --> 00:13:17.840
<v Speaker 2>It's a known vulnerability. Yes, and because our critical infrastructure,

262
00:13:17.879 --> 00:13:21.759
<v Speaker 2>power grids, finance, mobile networks relies so heavily on GNSS timing,

263
00:13:22.000 --> 00:13:26.360
<v Speaker 2>this vulnerability is taken very seriously. Resilient backup timing sources

264
00:13:26.360 --> 00:13:28.799
<v Speaker 2>are becoming essential, not just nice to haves.

265
00:13:29.080 --> 00:13:31.600
<v Speaker 1>Is that where things like h l RAN come in.

266
00:13:31.720 --> 00:13:33.320
<v Speaker 1>I saw that mention enhanced.

267
00:13:33.000 --> 00:13:36.360
<v Speaker 2>Loran exactly A loran is being looked at and deployed

268
00:13:36.360 --> 00:13:39.399
<v Speaker 2>in some regions as a terrestrial backup or complement to

269
00:13:39.600 --> 00:13:45.000
<v Speaker 2>space based GNSS. Loran uses very powerful low frequency radio

270
00:13:45.000 --> 00:13:47.919
<v Speaker 2>transmitters on the ground. The signals are much harder to

271
00:13:48.000 --> 00:13:51.919
<v Speaker 2>jam than genss and can penetrate buildings, tunnels, even underground

272
00:13:51.919 --> 00:13:55.320
<v Speaker 2>to some extent where satellite signals can't reach. The goal

273
00:13:55.360 --> 00:13:58.399
<v Speaker 2>for l RAN is to provide UTC traceability potentially down

274
00:13:58.440 --> 00:14:02.480
<v Speaker 2>to the fifteen nanosecond level, offering a really robust alternative

275
00:14:02.519 --> 00:14:04.960
<v Speaker 2>if GNSS is unavailable or compromised.

276
00:14:05.159 --> 00:14:08.120
<v Speaker 1>Interesting a ground based backup using very different technology.

277
00:14:08.320 --> 00:14:11.480
<v Speaker 2>Yeah, diversity and sources is key for resilience. Hashtag tag outro.

278
00:14:11.759 --> 00:14:13.679
<v Speaker 1>Okay, we'scovered a lot of ground here, from old town

279
00:14:13.720 --> 00:14:17.720
<v Speaker 1>clocks needing sun dials to needing nanoseca precision from space

280
00:14:17.799 --> 00:14:20.799
<v Speaker 1>and distributing it globally. Before we wrap up, let's quickly

281
00:14:20.840 --> 00:14:23.000
<v Speaker 1>just nail down the difference between two terms we used,

282
00:14:23.360 --> 00:14:25.960
<v Speaker 1>accuracy and stability. They sounds similar, but.

283
00:14:25.879 --> 00:14:29.799
<v Speaker 2>Aren't the same, right, correct, They're related, but distinct. Accuracy

284
00:14:29.960 --> 00:14:32.000
<v Speaker 2>is about how close your clock is to the true

285
00:14:32.039 --> 00:14:35.679
<v Speaker 2>reference time. Like UTC, we measure it using time error.

286
00:14:35.799 --> 00:14:39.639
<v Speaker 2>Often the maximum absolute time error maxte is your clock

287
00:14:39.759 --> 00:14:43.039
<v Speaker 2>actually showing the right time. Stability, on the other hand,

288
00:14:43.320 --> 00:14:46.159
<v Speaker 2>is about how consistently your clock ticks does its rate

289
00:14:46.279 --> 00:14:49.200
<v Speaker 2>change over time. A clock could be very stable its

290
00:14:49.240 --> 00:14:51.840
<v Speaker 2>frequency doesn't drift much but still be inaccurate if it

291
00:14:51.879 --> 00:14:55.159
<v Speaker 2>was set wrong initially, or it could be unstable it's

292
00:14:55.240 --> 00:14:58.200
<v Speaker 2>rate wandering even if it happens to be accurate right now. Ideally,

293
00:14:58.200 --> 00:15:01.679
<v Speaker 2>for network timing, you want both high accuracy and high stability.

294
00:15:01.759 --> 00:15:04.320
<v Speaker 1>Got Accurate means close to the truth. Stable means keeps

295
00:15:04.320 --> 00:15:07.159
<v Speaker 1>a steady beat. So looking ahead, we talked about that

296
00:15:07.480 --> 00:15:10.799
<v Speaker 1>demanding one point five microsecond absolute requirement from five G

297
00:15:10.960 --> 00:15:14.120
<v Speaker 1>relative to UTC, but the source material also mentions something

298
00:15:14.159 --> 00:15:17.679
<v Speaker 1>even tighter, e merging relative timing requirements between nearby five

299
00:15:17.720 --> 00:15:21.360
<v Speaker 1>G radios, sometimes needing alignment as close as sixty five nanoseconds.

300
00:15:21.399 --> 00:15:25.879
<v Speaker 2>That's right. That relative requirement is incredibly tight. It's needed

301
00:15:25.919 --> 00:15:29.120
<v Speaker 2>for some of the really advanced five G features, like

302
00:15:29.440 --> 00:15:34.159
<v Speaker 2>coordinated multipoint comp where multiple cell sites coordinate transmissions to

303
00:15:34.200 --> 00:15:39.320
<v Speaker 2>your phone simultaneously, or for sophisticated massive MIMO antenna arrays.

304
00:15:39.679 --> 00:15:42.480
<v Speaker 2>These features only work if the radios involved are synchronized

305
00:15:42.519 --> 00:15:45.559
<v Speaker 2>to each other with extreme precision, far tighter than just

306
00:15:45.600 --> 00:15:47.360
<v Speaker 2>their individual alignment to UTC.

307
00:15:48.000 --> 00:15:51.399
<v Speaker 1>Okay, sixty five nanoseconds relative alignment. So here's the final

308
00:15:51.440 --> 00:15:54.519
<v Speaker 1>thought we wanted to leave you the listener with. Today

309
00:15:54.639 --> 00:15:57.559
<v Speaker 1>we learned that half of any path asymmetry turns directly

310
00:15:57.559 --> 00:16:00.799
<v Speaker 1>into time air. If these new radio features demand relative

311
00:16:00.840 --> 00:16:04.720
<v Speaker 1>accuracy down to maybe sixty five nanoseconds between sites, what

312
00:16:04.799 --> 00:16:07.159
<v Speaker 1>kind of challenges does that create for the people designing

313
00:16:07.159 --> 00:16:09.840
<v Speaker 1>and running these transport networks, especially if they're getting their

314
00:16:09.840 --> 00:16:12.799
<v Speaker 1>timing signal maybe as a service over fiber circuits owned

315
00:16:12.840 --> 00:16:14.879
<v Speaker 1>by a third party, where they might not have full

316
00:16:14.919 --> 00:16:17.000
<v Speaker 1>control or visibility over the path symmetry.

317
00:16:17.159 --> 00:16:19.440
<v Speaker 2>Yeah, that's the rub, isn't it. The margin for error

318
00:16:19.480 --> 00:16:23.600
<v Speaker 2>is just vanishingly small. Trusting that the underlying path provides

319
00:16:23.639 --> 00:16:27.799
<v Speaker 2>that level of nanosecond symmetry constantly, that's going to be

320
00:16:27.919 --> 00:16:31.159
<v Speaker 2>I think one of the next big headaches and opportunities

321
00:16:31.360 --> 00:16:33.159
<v Speaker 2>in network timing. How do you guarantee that?

322
00:16:33.679 --> 00:16:36.559
<v Speaker 1>Definitely something to chew on. A fascinating look into an

323
00:16:36.600 --> 00:16:38.799
<v Speaker 1>invisible world. Thanks for joining us on the deep dive.