Re: [9fans] timesync doubletime

[erik quanstrom <quanstro@quanstro.net>]

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