[9fans] timesync is slow to set the time after boot

[9fans] timesync is slow to set the time after boot

[Richard Powell]

Hello 9fans,

I've noticed that timesync takes a minute or so to set the system time from the PC clock after a boot.  It seems that it 
  ignores the first sample from the clock and sleeps for a minute before setting the time from a second sample.  I've 
included a diff just to illustrate the issue.  Does anyone know the circumstances that led to this?  Are there 
problematic clocks out there:-)  Maybe we could restrict the dalay to the cases where it's needed.

Thanks,
Richard



diff -c timesync.org timesync.c.mod
*** timesync.org        Fri Mar 14 19:42:32 2003
--- timesync.c.mod      Fri Mar 14 19:42:32 2003
***************
*** 375,382 ****
                         s->stime = s->ltime + diff;

                 // if the sample was bad or if this is the first sample, ignore it
!               if(s->stime < 0 || !already){
!                       already = 1;
                         free(s);
                         continue;
                 }
--- 375,383 ----
                         s->stime = s->ltime + diff;

                 // if the sample was bad or if this is the first sample, ignore it
!       //      if(s->stime < 0 || !already){
!       //              already = 1;
!               if(s->stime < 0){
                         free(s);
                         continue;
                 }

Re: [9fans] timesync is slow to set the time after boot

[David Presotto]

Mostly we run from ntp and it takes a while to get a reasonable time
base.  I should just to it right away when syncing from the rtc.

Re: [9fans] timesync is slow to set the time after boot

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

I stopped ignoring the first sample.  It made some difference since the
first sample is usually perverted a bit by the system starting up.  However,
it really doesn't help to have a wrong time for a minute.   Thanks powell.

[-- Attachment #2: Type: message/rfc822, Size: 3105 bytes --]

From: Richard Powell <richard@powell.name>
To: 9fans <9fans@cse.psu.edu>
Subject: [9fans] timesync is slow to set the time after boot
Date: Fri, 14 Mar 2003 22:48:08 -0800
Message-ID: <3E72CCA8.2030605@powell.name>

Hello 9fans,

I've noticed that timesync takes a minute or so to set the system time from the PC clock after a boot.  It seems that it 
  ignores the first sample from the clock and sleeps for a minute before setting the time from a second sample.  I've 
included a diff just to illustrate the issue.  Does anyone know the circumstances that led to this?  Are there 
problematic clocks out there:-)  Maybe we could restrict the dalay to the cases where it's needed.

Thanks,
Richard



diff -c timesync.org timesync.c.mod
*** timesync.org        Fri Mar 14 19:42:32 2003
--- timesync.c.mod      Fri Mar 14 19:42:32 2003
***************
*** 375,382 ****
                         s->stime = s->ltime + diff;

                 // if the sample was bad or if this is the first sample, ignore it
!               if(s->stime < 0 || !already){
!                       already = 1;
                         free(s);
                         continue;
                 }
--- 375,383 ----
                         s->stime = s->ltime + diff;

                 // if the sample was bad or if this is the first sample, ignore it
!       //      if(s->stime < 0 || !already){
!       //              already = 1;
!               if(s->stime < 0){
                         free(s);
                         continue;
                 }

Re: [9fans] timesync is slow to set the time after boot

[Richard Powell]

David,

If there are problems reading the clock on the first pass, maybe we 
could just wait one second between passes instead of one minute. (Or 
even zero seconds if you think that's safe enough.).

Thanks for looking into this.
Richard



diff -c timesync.org timesync.c.tsecs0
*** timesync.c.org        Fri Mar 14 19:42:32 2003
--- timesync.c.tsecs1   Sun Mar 16 00:05:10 2003
***************
*** 344,349 ****
--- 344,350 ----
                         break;
                 case Rtc:
                         s->stime = sample(rtctime);
+                       tsecs = 1;
                         break;
                 case Utc:
                         s->stime = utcsample();
***************
*** 385,391 ****
                 diff = s->stime - s->ltime;
                 if(diff > 10*SEC || diff < -10*SEC){
                         // we're way off, just set the time
!                       secs = MinSampleSecs;
                         settime(s->stime, 0, 0, 0);
                 } else {
                         // keep a running average of the error.
--- 386,392 ----
                 diff = s->stime - s->ltime;
                 if(diff > 10*SEC || diff < -10*SEC){
                         // we're way off, just set the time
!                       tsecs = secs = MinSampleSecs;
                         settime(s->stime, 0, 0, 0);
                 } else {
                         // keep a running average of the error.



David Presotto wrote:
> I stopped ignoring the first sample.  It made some difference since the
> first sample is usually perverted a bit by the system starting up.  However,
> it really doesn't help to have a wrong time for a minute.   Thanks powell.
> 

Re: [9fans] timesync is slow to set the time after boot

[David Presotto]

No, it was just trying to get any system startup effects out of the
measurement.  It just mattered for ntp round trip, not for the real
time clock.  For NTP there's an assumption that the round trip time
twixt the systems is equally separated in the two directions.  When
the system is coming up, especially on diskless systems, the ether
can stay pretty busy for seconds after the boot as different things
page in, db's get read, etc.  Dropping the first sample was just an
attempt to avoid that since most of our systems (except our web
server) have settled after a minute.

However, I booted our systems here a few dozen times since then and
looked at the time convergence.  It doesn't seem to make a difference
either way so the check stays out.