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, [EMAIL PROTECTED] 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
