Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!rti!dg-rtp!bigben!bigben!philip From: philip@beeblebrox.dle.dg.com (Philip Gladstone) Newsgroups: comp.protocols.time.ntp Subject: Re: xclock :-) Message-ID: Date: 6 Dec 90 01:23:38 GMT References: <90392@elsie.nci.nih.gov> Sender: usenet@dle.dg.com (Net News) Organization: Data General, Development Lab Europe Lines: 17 In-Reply-To: ado@elsie.nci.nih.gov's message of 5 Dec 90 04:33:46 GMT In article <90392@elsie.nci.nih.gov> ado@elsie.nci.nih.gov (Arthur David Olson) writes: ado> So now that you've got your system's clock within milliseconds of where you ado> want it to be, what about the display on your screen? The attached is only a ado> start; the ftime system call would be needed for a complete job, along with ado> the code to lead the time by the delay between when the xclock process sends ado> the bits and when bits appear on screen. I noticed a similar xclock 'problem'. If you set xclock to update every second, then it annoyed me that the second hand did not tick 'on the second' but at some other (non-determinate) time. Unfortunately, I don't have the sources of xclock so I can't fix it. -- Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK Listen three eyes, don't you try and outweird me, I get stranger things that you free with my breakfast cereal.