1<!--$Id: clock_skew.so,v 1.3 2007/10/24 14:33:31 sue Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Clock Skew</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></b></td> 13<td align=right><a href="/rep/lease.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/rep/partition.html"><img src="/images/next.gif" alt="Next"></a> 14</td></tr></table> 15<p align=center><b>Clock Skew</b></p> 16<p>Since master leases take into account a timeout that is used across 17all sites in a replication group, leases must also take into account 18any known skew (or drift) between the clocks on different machines 19in the group. The guarantees provided by master leases take clock 20skew into account. Consider a replication group where a client's 21clock is running faster than the master's clock and the group has 22a lease timeout of 5 seconds. If clock skew is not taken into 23account, eventually, the client will believe that 5 seconds have 24passed faster than the master and that client may then grant its 25lease to another site. Meanwhile, the master site does not believe 265 seconds have passed because its clock is slower, and it believes 27it still holds a valid lease grant. For this reason, Berkeley DB compensates 28for clock skew.</p> 29<p>The master of a group using leases must account for skew 30in case that site has the slowest clock in the group. This computation 31avoids the problem of a master site believing a lease grant is valid 32too long. Clients in a group must account for skew in case they 33have the fastest clock in the group. This computation avoids 34the problem of a client site expiring its grant too soon and 35potentially granting a lease to a different site. Berkeley DB uses 36a conservative computation and accounts for clock skew on both 37sides, yielding a double compensation.</p> 38<p>The <a href="/api_c/rep_clockskew.html">DB_ENV->rep_set_clockskew</a> method takes the values for both the fastest 39and slowest clocks in the entire replication group as parameters. 40The values passed in must be the same for all sites in the group. 41If the user knows the maximum clock drift of their sites, then those 42values can be expressed as a relative percentage. Or, if the user 43runs an experiment then the actual values can be used.</p> 44<p>For example, suppose the user knows that there is a maximum drift 45rate of 2% among sites in the group. The user should pass in 46102 and 100 for the fast and slow clock values respectively. 47That is an unusually large value, so suppose, for example, the 48rate is 0.03% among sites in the group. The user should pass in 4910003 and 10000 for the fast and slow clock values. Those values 50can be used to express the level of precision the user needs.</p> 51<p>An example of an experiment a user can run to help determine skew 52would be to write a program that started simultaneously on all 53sites in the group. Suppose, after 1 day (86400 seconds), one 54site shows 86400 seconds and the other site shows it ran faster 55and it indicates 86460 seconds has passed. 56The user can use 86460 and 86400 for their parameters for the 57fast and slow clock values.</p> 58<p>Since Berkeley DB is using those fast and slow clock values to compute 59a ratio internally, if the user cannot detect or measure any 60clock skew, then the same value should be passed in for both 61parameters, such as 1 and 1.</p> 62<table width="100%"><tr><td><br></td><td align=right><a href="/rep/lease.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/rep/partition.html"><img src="/images/next.gif" alt="Next"></a> 63</td></tr></table> 64<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 65</body> 66</html> 67
