Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!emory!gatech!mcnc!duke!khera From: khera@thneed.cs.duke.edu (Vick Khera) Newsgroups: comp.unix.questions Subject: Re: Network Time Protocol Message-ID: Date: 13 Nov 90 16:10:49 GMT References: <1423@nixsin.UUCP> Sender: news@duke.cs.duke.edu Organization: Duke University CS Dept., Durham, NC Lines: 33 Nntp-Posting-Host: thneed.cs.duke.edu In-reply-to: koerberm@nixsin.UUCP's message of 12 Nov 90 12:13:48 GMT In article <1423@nixsin.UUCP> koerberm@nixsin.UUCP (Mathias Koerber) writes: From: koerberm@nixsin.UUCP (Mathias Koerber) Newsgroups: comp.unix.questions Keywords: ntp PROGRESS In article nguyend@caip.rutgers.edu (Duc Nguyen) writes: > I've been trying to synchronize the clocks of sites on the Ethernet >but could not figure out how to do this as accurate as possible. I OK, I get the idea of synchronising the clocks of different hosts on a network, and I think it is quite useful... BUT: I know, that PROGRESS Database eg is *very* allergic against changes in the system time. Especially setting the time BACKWARDS (even 1 sec) will kill the server/broker process, because database integrity is based on the time. with time synchronization, if you need to set the clock backwards, you don't just change the time, you slow down the clock until it has reached the proper time. in unix, this is accomplished by the adjtime() system call. this should be indetectible by processes. similarly, to set the clock forward, the speed is increased until the proper time is reached. v . -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vick Khera Gradual Student Department of Computer Science ARPA: khera@cs.duke.edu Duke University UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528