From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5c65e1bbe6cf58f625cf953b0c269871@quanstro.net> From: erik quanstrom Date: Tue, 8 Aug 2006 15:07:09 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] timesync doubletime In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 9a398310-ead1-11e9-9d60-3106f5b1d025 what you're saying makes sense. the problem is that wasn't quite what happened. when i started timesync, the clock was running about 10 minutes fast. when i killed timesync, the clock was about 8 hours fast. i think the problem is that the network connection was interrupted. but i can't figure out why that would cause this problem. if that were to happen, sample(fstime) will return 0, i think, and then try to write n0 to /dev/bintime. the kernel takes that as a delta of 0. things should have been okay. maybe i'm reading the code incorrectly. a local ntp server would be a good idea, but when your network connection is a modem, i don't think it makes much difference. ;-) also, the accuracy i was looking for was "getting to work on time" not intercepting the iss. ;-) - erik On Tue Aug 8 09:54:32 CDT 2006, rsc@swtch.com wrote: > > the rtc clock in one of my machines runs a bit slow -- maybe 2 minutes a month. > > i ran timesync -h /srv/sources and now the system clock runs ~28 sec/min too fast. > > killing timesync had no effect. > > Killing timesync probably did have an effect. > > As Kris pointed out, if you were a few minutes behind sources > then maybe timesync was running time fast to catch up. Killing it > doesn't help -- now time will run fast forever, when if you'd left it, > it probably would have slowed to regular speed once it caught up. > The speed in use at time of kill is what the kernel will use until > told otherwise. > > Also, you might get more precise results by using NTP instead > of relying on a long-distance TCP connection to sources. > > Russ