## Are you sure?

This action might not be possible to undo. Are you sure you want to continue?

**06-06798 Distributed Systems
**

Lecture 10:

Clocks and Time

11 February, 2002 2

Overview

• Time service

– requirements and problems

– sources of time

• Clock synchronisation algorithms

– clock skew & drift

– Cristian algorithm

– Berkeley algorithm

– Network Time Protocol

• Logical clocks

– Lamport’s timestamps

11 February, 2002 3

Time service

• Why needed?

– to measure delays between distributed components

– to synchronise streams, e.g. sound and video

– to establish event ordering

• causal ordering (did A happen before B?)

• concurrent/overlapping execution (no causal relationship)

– for accurate timestamps to identify/authenticate

• business transactions

• serializability in distributed databases

• security protocols

11 February, 2002 4

Clocks

• Internal hardware clock

– built-in electronic device

– counts oscillations occurring in a quartz crystal at a

definite frequency

– store the result in a counter register

– interrupt generated at regular intervals

– interrupt handler reads the counter register, scales it to

convert to time units (seconds, nanoseconds) and

updates software clock

• e.g. seconds elapsed since 1/01/1970

11 February, 2002 5

Problems with internal clocks

• Frequency of oscillations

– varies with temperature

– different rate on different computers

10:05:17 10:05:14 10:05:15

• Accuracy

– typically 1 sec in 11.6 days

• Centralised time service?

– impractical due to variable message delays

11 February, 2002 6

Clock skew and drift

• Clock skew

– difference between the readings of two clocks

• Clock drift

– difference in reading between a clock and a nominal

perfect reference clock per unit of time of the reference

clock

• typically 10

-6

seconds/second = 1 sec in 11.6 days

Network

11 February, 2002 7

Sources of time

• Universal Coordinated Time (UTC, from French)

– based on atomic time but leap seconds inserted to keep

in phase with astronomical time (Earth’s orbit)

– UTC signals broadcast every second from radio and

satellite stations

• land station accuracy 0.1-10ms due to atmospheric conditions

• Global Positioning System (GPS)

– broadcasts UTC

• Receivers for UTC and GPS

– available commercially

– used to synchronise local clocks

11 February, 2002 8

Clock synchronisation

• External: synchronise with authoritative source of

time

– the absolute value of difference between the clock and

the source is bounded above by D at every point in the

synchronisation interval

– time accurate to within D

• Internal: synchronise clocks with each other

– the absolute value of difference between the clocks is

bounded above by D at every point in the

synchronisation interval

– clocks agree to within D (not necessarily accurate time)

11 February, 2002 9

Clock compensation

• Assume 2 clocks can each drift at rate R msecs/sec

– maximum difference 2R msecs/sec

– must resynchronise every D/2R to agree within D

• Clock correction

– get UTC and correct software clock

• Problems!

– what happens if local clock is 5 secs fast and it is set right?

– timestamped versions of files get confused

– time must never run backwards!

– better to scale the value of internal clock in software

without changing the clock rate

11 February, 2002 10

Synchronisation methods

• Synchronous systems

– simpler, relies on known time bounds on system actions

• Asynchronous systems

– intranets

• Cristian’s algorithm

• Berkeley algorithm

– Internet

• The Network Time Protocol

11 February, 2002 11

Synchronous systems case

• Internal synchronisation between two processes

– know bounds MIN, MAX on message delay

– also on clock drift, execution rate

• Assume One sends message to Two with time t

– Two can set its clock to t + (MAX+MIN)/2 (estimate of

time taken to send message)

– then the skew is at most (MAX-MIN)/2

– why not t + MIN or t + MAX?

• maximum skew is larger, could be MAX-MIN

11 February, 2002 12

Cristian’s algorithm

• Estimate message propagation time by p=(T

1

-T

0

-h)/2 (=half of

round-trip of request-reply)

• Set clock to UTC+p

• Make multiple requests, at spaced out intervals, measure T

1

-T

0

– but discard any that are over a threshold (could be congestion)

– or take minimum values as the most accurate

Time Server with

UTC receiver gives

accurate current

time

Client

Time server

h = interrupt

handler time

T

0

Request

T

1

UTC Time

11 February, 2002 13

Cristian’s algorithm

• Probabilistic behaviour

– achieves synchronisation only if round-trip short

compared to required accuracy

– high accuracy only for message transmission time close

to minimum

• Problems

– single point of failure and bottleneck

– could multicast to a group of servers, each with UTC

– an impostor or faulty server can wreak havoc

• use authentication

• agreement protocol for N > 3f clocks, f number of faulty clocks

11 February, 2002 14

The Berkeley algorithm

• Choose master co-ordinator which periodically polls slaves

• Master estimates slaves’ local time based on round-trip

• Calculates average time of all, ignoring readings with

exceptionally large propagation delay or clocks out of synch

• Sends message to each slave indicating clock adjustment

2:59:50 3:00:25

2:59:51 3:00:26

2:59:52 3:00:27

3:00:00 3:00:01 3:00:02

Synchronisation

feasible to within

20-25 msec for 15

computers, with

drift rate of 2 x 10

-5

and max round trip

propagation time

of 10 msec.

3:00:00

3:00:00 3:00:00

Query

0

-10 +25

Response

+5

+15 -20

Adjust

11 February, 2002 15

The Berkeley algorithm

• Accuracy

– depends on the round-trip time

• Fault-tolerant average:

– eliminates readings of faulty clocks - probabilistically

– average over the subset of clocks that differ by up to a

specified amount

• What if master fails?

– elect another leader

11 February, 2002 16

Network Time Protocol (NTP)

• Multiple time servers across the Internet

• Primary servers: directly connected to UTC receivers

• Secondary servers: synchronise with primaries

• Tertiary servers: synchronise with secondary, etc

• Scales up to large numbers of servers and clients

1

3 3 3

2 2

= active synchronisation

= backup synchronisation

(exchange timing

information, but do not

use it to synchronise

clocks)

Copes with failures of servers

– e.g. if primary’s UTC source

fails it becomes a secondary,

or if a secondary cannot reach

a primary it finds another one.

Authentication used to check

that time comes from trusted

sources

11 February, 2002 17

NTP Synchronisation Modes

• Multicast

– one or more servers periodically multicast to other servers

on high speed LAN

– they set clocks assuming small delay

• Procedure Call Mode

– similar to Cristian’s algorithm: client requests time from a

few other servers

– used for higher accuracy or where no multicast

• Symmetric protocol

– used by master servers on LANs and layers closest to

primaries

– highest accuracy, based on pairwise synchronisation

11 February, 2002 18

NTP Symmetric Protocol

• t = transmission delay (e.g. 5ms)

• o = clock offset of B relative to A (e.g. 3ms)

• Record local times T1 = 10, T2 = 18, T3 = 20, T4 = 22

Let a = T2-T1= t + o, b = T4-T3 = t’ - o, and assume t ≈ t’

Round trip delay = t + t’ = a + b = (T2-T1)+(T4-T3) = 10

Calculate estimate of clock offset o = (a-b)/2 = 3

Server B T2 T3

Server A T1 T4

t+o t’-o

10

18 20

22

11 February, 2002 19

NTP Symmetric Protocol

• T4 = current message receive time determined at receiver

• Every message contains

– T3 = current message send time

– T2 = previous receive message receive time

– T1 = previous receive message send time

• Data filtering (obtain average values of clock offset from values

of o corresponding to minimum t)

• Peer selection (exchange messages with several peers favouring

those closer to primaries)

• How good is it? 20-30 primaries and 2000 secondaries can

synchronise to within 30 ms

11 February, 2002 20

Logical time

• For many purposes it is sufficient to agree on the

same time (e.g. internal consistency) which need not

be UTC time

• Can deduce causal event ordering

a → b (a occurs before b)

• Logical time denotes causal relationships

• but the → relationship may not reflect real causality,

only accidental

11 February, 2002 21

Event ordering

Define a → b (a occurs before b) if

– a and b are events in the same process and a occurs before

b, or

– a is the event of message sent from process A and B is the

event of message receipt by process B

If a → b and b → c then a → c.

→ is partial order.

For events such that neither a → b nor b → a we say

a, b are concurrent, denoted a || b.

11 February, 2002 22

Example of causal ordering

• a → b, c → d

• b → c, d → f

• a || e

p

1

p

2

p

3

a b

c d

e f

m

1

m

2

Physical

time

11 February, 2002 23

Logical clocks [Lamport]

• Logical clock = monotonically increasing software

counter (not real time!)

– one for each process P, used for timestamping

• How it works

– L

P

incremented before assigning a timestamp to an event

– when P sends message m, P timestamps it with current value

t of L

P

(after incrementing it), piggybacking t with m

– on receiving message (m,t), Q sets its own clock L

Q

to

maximum of L

Q

and t, then increments L

Q

before

timestamping the message receive event

• Note a → b implies T(a) < T(b)

What What

about about

converse? converse?

11 February, 2002 24

Totally ordered logical clocks

• Problem: T(a) = T(e), and yet a, e distinct.

• Create total order by taking account of process ids.

• Then (T(a),pid) < (T(b),qid) iff T(a) < T(b) or

T(a)=T(b) and pid < qid.

a

b

c d

e f

m

1

m

2

2 1

3 4

5

1

p

1

p

2

p

3

Physical

time

11 February, 2002 25

Vector clocks

• Totally ordered logical clocks

– arbitrary event order, depends on order of process ids

– i.e. (T(a),pid) < (T(b),qid) does not imply a → b, see a, e

• Vector clocks

– array of N logical clocks in each process, if N processes

– vector timestamps piggybacked on the messages

– rules for incrementing similar to Lamport’s, except

• processes own component in array modified

• componentwise maximum and comparison

• Problems

– storage requirements

11 February, 2002 26

Vector timestamps

• VT(b) < VT(c), hence b → c

• neither VT(b) < VT(e), nor VT(b) < VT(e), hence b || e

a

b

c d

e f

m

1

m

2

(2,0,0) (1,0,0)

(2,1,0) (2,2,0)

(2,2,2)

(0,0,1)

p

1

p

2

p

3

Physical

time

11 February, 2002 27

Summary

• Local clocks

– drift!

– but needed for timestamping

• Synchronisation algorithms

– must handle variable message delays

• Clock compensation estimate average delays

– adjust clocks

– can deal with faulty clocks

• Logical clocks

– sufficient for causal ordering

Overview

• Time service

– requirements and problems – sources of time

**• Clock synchronisation algorithms
**

– – – – clock skew & drift Cristian algorithm Berkeley algorithm Network Time Protocol

• Logical clocks

– Lamport’s timestamps

11 February, 2002 2

2002 3 .g. sound and video – to establish event ordering • causal ordering (did A happen before B?) • concurrent/overlapping execution (no causal relationship) – for accurate timestamps to identify/authenticate • business transactions • serializability in distributed databases • security protocols 11 February. e.Time service • Why needed? – to measure delays between distributed components – to synchronise streams.

seconds elapsed since 1/01/1970 11 February. scales it to convert to time units (seconds. 2002 4 .g. nanoseconds) and updates software clock • e.Clocks • Internal hardware clock – built-in electronic device – counts oscillations occurring in a quartz crystal at a definite frequency – store the result in a counter register – interrupt generated at regular intervals – interrupt handler reads the counter register.

2002 5 .Problems with internal clocks • Frequency of oscillations – varies with temperature – different rate on different computers 10:05:17 10:05:14 10:05:15 • Accuracy – typically 1 sec in 11.6 days • Centralised time service? – impractical due to variable message delays 11 February.

Clock skew and drift 1HWZRUN • Clock skew – difference between the readings of two clocks • Clock drift – difference in reading between a clock and a nominal perfect reference clock per unit of time of the reference clock • typically 10-6 seconds/second = 1 sec in 11. 2002 6 .6 days 11 February.

Sources of time • Universal Coordinated Time (UTC.1-10ms due to atmospheric conditions • Global Positioning System (GPS) – broadcasts UTC • Receivers for UTC and GPS – available commercially – used to synchronise local clocks 11 February. 2002 7 . from French) – based on atomic time but leap seconds inserted to keep in phase with astronomical time (Earth’s orbit) – UTC signals broadcast every second from radio and satellite stations • land station accuracy 0.

2002 8 .Clock synchronisation • External: synchronise with authoritative source of time – the absolute value of difference between the clock and the source is bounded above by D at every point in the synchronisation interval – time accurate to within D • Internal: synchronise clocks with each other – the absolute value of difference between the clocks is bounded above by D at every point in the synchronisation interval – clocks agree to within D (not necessarily accurate time) 11 February.

2002 .Clock compensation • Assume 2 clocks can each drift at rate R msecs/sec – maximum difference 2R msecs/sec – must resynchronise every D/2R to agree within D • Clock correction – get UTC and correct software clock • Problems! – – – – what happens if local clock is 5 secs fast and it is set right? timestamped versions of files get confused time must never run backwards! better to scale the value of internal clock in software without changing the clock rate 9 11 February.

relies on known time bounds on system actions • Asynchronous systems – intranets • Cristian’s algorithm • Berkeley algorithm – Internet • The Network Time Protocol 11 February.Synchronisation methods • Synchronous systems – simpler. 2002 10 .

could be MAX-MIN 11 February. MAX on message delay – also on clock drift. 2002 11 .Synchronous systems case • Internal synchronisation between two processes – know bounds MIN. execution rate • Assume One sends message to Two with time t – Two can set its clock to t + (MAX+MIN)/2 (estimate of time taken to send message) – then the skew is at most (MAX-MIN)/2 – why not t + MIN or t + MAX? • maximum skew is larger.

at spaced out intervals.Cristian’s algorithm Client T0 Request h = interrupt handler time UTC Time Time server T1 Time Server with UTC receiver gives accurate current time • Estimate message propagation time by p=(T1-T0-h)/2 (=half of round-trip of request-reply) • Set clock to UTC+p • Make multiple requests. 2002 12 . measure T1-T0 – but discard any that are over a threshold (could be congestion) – or take minimum values as the most accurate 11 February.

f number of faulty clocks 11 February. each with UTC – an impostor or faulty server can wreak havoc • use authentication • agreement protocol for N > 3f clocks. 2002 13 .Cristian’s algorithm • Probabilistic behaviour – achieves synchronisation only if round-trip short compared to required accuracy – high accuracy only for message transmission time close to minimum • Problems – single point of failure and bottleneck – could multicast to a group of servers.

14 3:00:00 3:00:00 3:00:00 2:59:50 3:00:00 3:00:25 -10 2:59:51 3:00:01 0 3:00:02 +25 3:00:26 +15 2:59:52 +5 -20 3:00:27 Query 11 February. with drift rate of 2 x 10-5 and max round trip propagation time of 10 msec. 2002 Response Adjust .The Berkeley algorithm • Choose master co-ordinator which periodically polls slaves • Master estimates slaves’ local time based on round-trip • Calculates average time of all. ignoring readings with exceptionally large propagation delay or clocks out of synch • Sends message to each slave indicating clock adjustment Synchronisation feasible to within 20-25 msec for 15 computers.

The Berkeley algorithm • Accuracy – depends on the round-trip time • Fault-tolerant average: – eliminates readings of faulty clocks . 2002 15 .probabilistically – average over the subset of clocks that differ by up to a specified amount • What if master fails? – elect another leader 11 February.

g. if primary’s UTC source = backup synchronisation fails it becomes a secondary. but do not a primary it finds another one. etc Scales up to large numbers of servers and clients 1 2 2 Copes with failures of servers – e. 2002 Authentication used to check that time comes from trusted sources 16 .Network Time Protocol (NTP) • • • • • Multiple time servers across the Internet Primary servers: directly connected to UTC receivers Secondary servers: synchronise with primaries Tertiary servers: synchronise with secondary. (exchange timing or if a secondary cannot reach information. use it to synchronise = active synchronisation clocks) 3 3 3 11 February.

based on pairwise synchronisation 11 February.NTP Synchronisation Modes • Multicast – one or more servers periodically multicast to other servers on high speed LAN – they set clocks assuming small delay • Procedure Call Mode – similar to Cristian’s algorithm: client requests time from a few other servers – used for higher accuracy or where no multicast • Symmetric protocol – used by master servers on LANs and layers closest to primaries – highest accuracy. 2002 17 .

T2 = 18. b = T4-T3 = t’ . 2002 18 . 3ms) • Record local times T1 = 10.o.g.g. T3 = 20.NTP Symmetric Protocol Server B T2 t+o T3 18 20 t’-o 10 Server A T1 22 T4 • t = transmission delay (e. and assume t ≈ t’ Round trip delay = t + t’ = a + b = (T2-T1)+(T4-T3) = 10 Calculate estimate of clock offset o = (a-b)/2 = 3 11 February. T4 = 22 Let a = T2-T1= t + o. 5ms) • o = clock offset of B relative to A (e.

2002 19 .NTP Symmetric Protocol • T4 = current message receive time determined at receiver • Every message contains – T3 = current message send time – T2 = previous receive message receive time – T1 = previous receive message send time • Data filtering (obtain average values of clock offset from values of o corresponding to minimum t) • Peer selection (exchange messages with several peers favouring those closer to primaries) • How good is it? 20-30 primaries and 2000 secondaries can synchronise to within 30 ms 11 February.

only accidental 11 February. 2002 20 .Logical time • For many purposes it is sufficient to agree on the same time (e.g. internal consistency) which need not be UTC time • Can deduce causal event ordering a → b (a occurs before b) • Logical time denotes causal relationships • but the → relationship may not reflect real causality.

2002 21 . or – a is the event of message sent from process A and B is the event of message receipt by process B If a → b and b → c then a → c. → is partial order.Event ordering Define a → b (a occurs before b) if – a and b are events in the same process and a occurs before b. b are concurrent. For events such that neither a → b nor b → a we say a. denoted a || b. 11 February.

Example of causal ordering S D S F S G P E P 3K\VLFDO WLPH • a → b. 2002 H I 22 . d → f • a || e 11 February. c → d • b → c.

2002 23 .t). Q sets its own clock LQ to What maximum of LQ and t.Logical clocks [Lamport] • Logical clock = monotonically increasing software counter (not real time!) – one for each process P. used for timestamping • How it works – LP incremented before assigning a timestamp to an event – when P sends message m. P timestamps it with current value t of LP (after incrementing it). then increments LQ before about converse? timestamping the message receive event • Note a → b implies T(a) < T(b) 11 February. piggybacking t with m – on receiving message (m.

e distinct.Totally ordered logical clocks S D E P F H G P I 3K\VLFDO WLPH S S • Problem: T(a) = T(e).pid) < (T(b). • Then (T(a).qid) iff T(a) < T(b) or T(a)=T(b) and pid < qid. • Create total order by taking account of process ids. 2002 24 . and yet a. 11 February.

Vector clocks • Totally ordered logical clocks – arbitrary event order.pid) < (T(b). (T(a). depends on order of process ids – i. e • Vector clocks – array of N logical clocks in each process. see a. except • processes own component in array modified • componentwise maximum and comparison • Problems – storage requirements 11 February.e. if N processes – vector timestamps piggybacked on the messages – rules for incrementing similar to Lamport’s.qid) does not imply a → b. 2002 25 .

Vector timestamps .

.

S D E P .

F .

H .

G P .

nor VT(b) < VT(e). hence b → c • neither VT(b) < VT(e). 2002 26 . I 3K\VLFDO WLPH S S • VT(b) < VT(c). hence b || e 11 February.

Summary • Local clocks – drift! – but needed for timestamping • Synchronisation algorithms – must handle variable message delays • Clock compensation estimate average delays – adjust clocks – can deal with faulty clocks • Logical clocks – sufficient for causal ordering 11 February. 2002 27 .

- Paper ETCTag
- RAC 11gR1 to 11gR2 Upgrade
- LTF_EN
- 630 Series Operation Manual
- T-REC-G.8265-201010-I!!PDF-E (1)
- ICTsupplement_Sep2013
- NodeB Commissioning Guide(V200_01)
- DS_S250
- Ntp Server m600
- 15-Network Management and Monitoring Configuration Guide-book (1)
- 8000gs_wg
- Spectracom SecureSync
- Abacus CCC
- Chapter 1
- On-Board Signal Integrity for GPS
- Abstract
- Overheard in Seville.17.1999
- causal - illusiory motion casual time filtering.pdf
- Selected Applications of a Dyn
- Lesson Plan - Mobile Apps
- GPS DCS Time Syhchronisation
- A ordem do tempo histórico - a longue durée e a microhistória
- 11th class physics :kinematics in one Dimension + calculus @ viresh
- unit-6 mat
- PerformanceMeasures Slides
- bridging scales
- Lemurian Legacy GS eBook
- 175923721 Time Mastery PDF

- BAB I Revisi
- FileSistem04.pptx
- _Laporan KKN Kelompok [Final]
- BAB I
- Sistem Informasi Enterprise
- Spek Teknis
- SPESIFIKASI
- BAB II SPK Penerimaan Karyawan
- BAB II
- Bahan SQL & VB
- BAB III Edit Penentuan Jursan.doc
- Spesifikasi Pengaman Pantai Sei.selari
- Seminar Beasiswa
- Pengaturan Kejahatan Elektronik Atau Cyber Crime Dalam Tatanan
- 01-Dasar Pemrograman Visual C++ 6.0
- Etika Dan Norma Ekonomi Dalam Islam
- Pertemuan 2 Arsitektur Dan Protokol
- Brosur DULUX
- koding gaji
- Draft Penawaran Sewa
- Modus Kejahatan dalam TI
- Multiple Intelligence
- Seminar Beasiswa
- Desain Form Dan Report

Sign up to vote on this title

UsefulNot usefulClose Dialog## Are you sure?

This action might not be possible to undo. Are you sure you want to continue?

Close Dialog## This title now requires a credit

Use one of your book credits to continue reading from where you left off, or restart the preview.

Loading