D. L. Mills. Network Time Protocol (version1) Specification and Implementa- tion. DARPA-Internet Report RFC-1059, DARPA, July 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... using a set of loosely synchronized clocks to choose queue entry times, it is possible to use a set of tightly synchronized clocks, i.e. a distributed set of clocks where the maximum tinhe difference between any two clocks is less than some known value e e can be chosen to be a very small number) [Mills 1988]. In such a system, a topaction uses its OM s local clock tinhe as its proposed queue entry time; actions choose entry times that correspond to their real commit order. Topaction va:Ldate request messages will tend to arrive at a given OM with proposed queue entry times properly ordered, since ....

D. L. Mills. Network Time Protocol (version1) Specification and Implementa- tion. DARPA-Internet Report RFC-1059, DARPA, July 1988.

....be detected. Our method is based on loosely synchronized clocks; because it depends on synchronized clocks, we refer to our protocol as the synchronized clock message protocol, or SCMP for short. Our protocol can easily tolerate the clock skews provided by existing clock synchronization protocols [2]; these skews are typically less than 100 milliseconds, even in a wide area network. If the rare event of unsynchronized clocks does occur, the protocol continues to work correctly, although there may be a degradation of performance. The paper is organized as follows. In Section 2 we describe ....

....network by a stable storage service [7] Every node has a clock. As mentioned, we assume that the nodes clocks are loosely synchronized with some skew ; nodes ensure this by carrying out a clock synchronization protocol periodically. At least one practical clock synchronization protocol exists [2]. It synchronizes clocks of nodes on a geographically distributed network so that clocks are guaranteed with very high probability to have a skew of less than a hundred milliseconds. The protocol does this at low cost and low overhead (each node exchanges a pair of messages with three other nodes ....

Mills, D.L. Network Time Protocol (version1) specification and implementation. DARPA-Internet Report RFC-1059. July 1988.

....clocks that never run backwards. The correctness of our protocol depends only on the monotonicity assumption, but performance can suffer when clocks drift too far apart. There are protocols that with low cost synchronize clocks in geographically distributed networks, e.g. the NTP protocol [24] provides a clock skew on the order of a hundred milliseconds. Typically clocks are monotonic both while nodes are up and across crashes. If they need to be adjusted this is done by slowing them down or speeding them up. Also, clocks are usually stable; if not the clock value can be saved to ....

Mills, D. L. Network Time Protocol (versionl ) specification and implementation. DARPA-Internet Report RFC-1059, DARPA, 1988.

....loosely synchronized to within a few tens of milliseconds of one another. This assumption is not needed for correctness, but improves performance since it allows each OR to make time dependent decisions, e.g. when discarding old information. This assumption is a reasonable one for current systems [44]. Every participant of the transaction will try to serialize the transaction relative to other transactions. This is done using a backward validation scheme [28] the committing transaction is compared with other committed and committing transactions, but not with active transactions (since that ....

D. L. Mills. Network time protocol (version 1) specification and implementation. DARPAInternet Report RFC 1059, July 1988.

....at commit time. In this thesis, we adapt the optimistic schemes that have been suggested in the past and propose a validation strategy that truncates transaction history information frequently without causing unnecessary aborts. We assume the availability of an external service such as NTP [Mills88] that provides loosely synchronized clocks. This assumption allows a server to generate an appropriate timestamp for a committing transaction; it has also helped us in simplifying the validation process. In addition, loosely synchronized clocks help in reducing the logging requirements for ....

....schemes synchronize the counters at various sites as part of the concurrency control mechanism. The Thor model assumes that loosely synchronized clocks [Lamport78] are available in the system; this is a reasonable assumption for current systems where protocols such as the Network Time Protocol [Mills88] provide such a facility. To choose a timestamp for transaction T, the coordinator server uses its local clock and augments it with the server id to make T.ts globally unique. Since loosely synchronized 35 S 1 S 2 S i S i 1 S j S n ts: 97 ROS: x, 79 MOS: Incoming ....

Mills D. L. Network Time Protocol (Version 1): Specification and Implementation. DARPA-Internet Report RFC 1059, July 1988. 93

....The network can partition, and messages can be lost, delayed, duplicated, and delivered out of order. The configuration of the system can change; nodes can leave and join the network at any time. We assume nodes have loosely synchronized clocks. There are practical protocols, such as NTP [26] that with low cost synchronize clocks in geographically distributed networks. A replicated application is implemented by service consisting of replicas running at different nodes in a network. To hide replication from clients, the system also provides front end code that runs at client nodes. To ....

Mills, D. L. Network Time Protocol (version1) specification and implementation. DARPA-Internet Report RFC-1059, DARPA, 1988.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC