Hello,

I have a Linux based switch that I need to have syncronise with an NTP
server.  It WILL sync on startup and the time/date is correct but if the NTP
time source is changed (date time change) the Linux Switch does not change
it's time to reflect.  The NTPD Daemon is supposed to (I am told) do this
automatically but it does not.

I have set-up in /etc the ntp.conf file with an ip address of the NTP time
source and also in /etc/ntp/step-tickers the same ip address.  Now as I say
this appears to sync upon boot-up when the Daemon first starts but never
again.

I need to know how to make this switch Poll the NTP Server to maintain time
with it.  It does not seem to be polling for the time source after intitial
sync.

Linux Kernel is 2.4 I think...

Can anyone help me please?!

Geoff
Canberra, Australia

Geoff <g_wynn@ozemail.com.au> wrote:
> Hello,

> I have a Linux based switch that I need to have syncronise with an NTP
> server.  It WILL sync on startup and the time/date is correct but if the NTP
> time source is changed (date time change) the Linux Switch does not change
> it's time to reflect.

How big of a change?  NTP is supposed to keep systems in sync, not
propogate large changes quickly.

> The NTPD Daemon is supposed to (I am told) do this automatically but
> it does not.

How long did you wait?  Were there any messages in the system log?  What
does ntpq -p show?

The changes should propogate eventually unless you leave the 1000s
sanity boundary.  If you do that, ntpd will assuming something is very
wrong and exit.

> I have set-up in /etc the ntp.conf file with an ip address of the NTP time
> source and also in /etc/ntp/step-tickers the same ip address.  Now as I say
> this appears to sync upon boot-up when the Daemon first starts but never
> again.

> I need to know how to make this switch Poll the NTP Server to maintain time
> with it.  It does not seem to be polling for the time source after intitial
> sync.

show 'ntpq -p' output.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Darren, many thanks.

Actually the change in time is significant, by years, not seconds.  How can
I test it is actually re-syncing if the max timeout is 1000 seconds (ok,
1000 secs is ok but is it Secs or Msecs?)  I can change the time by a few
mins to check if you think that is the better option, all I want to know is
if it is re-syncing.  I waited 1/2 hour to an hour.

No, haven't checked the system log.  In fact to sound dumb, how do I do
that?  This version of Linux is very watered down as it is on a switch.

again, thanks,

Geoff

"Darren Dunham" <ddunham@redwood.taos.com> wrote in message
news:104ge.887$Y81.831@newssvr21.news.prodigy.com...
> Geoff <g_wynn@ozemail.com.au> wrote:
> > Hello,
>
> > I have a Linux based switch that I need to have syncronise with an NTP
> > server.  It WILL sync on startup and the time/date is correct but if the
NTP
> > time source is changed (date time change) the Linux Switch does not
change
> > it's time to reflect.
>
> How big of a change?  NTP is supposed to keep systems in sync, not
> propogate large changes quickly.
>
> > The NTPD Daemon is supposed to (I am told) do this automatically but
> > it does not.
>
> How long did you wait?  Were there any messages in the system log?  What
> does ntpq -p show?
>
> The changes should propogate eventually unless you leave the 1000s
> sanity boundary.  If you do that, ntpd will assuming something is very
> wrong and exit.
>
> > I have set-up in /etc the ntp.conf file with an ip address of the NTP
time
> > source and also in /etc/ntp/step-tickers the same ip address.  Now as I
say
> > this appears to sync upon boot-up when the Daemon first starts but never
> > again.
>
> > I need to know how to make this switch Poll the NTP Server to maintain
time
> > with it.  It does not seem to be polling for the time source after
intitial
> > sync.
>
> show 'ntpq -p' output.
>
> -- 
> Darren Dunham                                           ddunham@taos.com
> Senior Technical Consultant         TAOS            http://www.taos.com/
> Got some Dr Pepper?                           San Francisco, CA bay area
>          < This line left intentionally blank to confuse you. >

At 7:55 PM +1000 2005-05-11, Geoff wrote:

>  Actually the change in time is significant, by years, not seconds.

	If your time server suddenly jumps years, then all the clients 
are going to exit.  The hard limit is one thousand seconds, not 
milliseconds, days, months, or any other unit of time -- 1000 
seconds.  If you suddenly exceed that limit after you've gone through 
the startup phase, then all NTP clients should exit as soon as they 
detect that change.

>                                                                      How can
>  I test it is actually re-syncing if the max timeout is 1000 seconds (ok,
>  1000 secs is ok but is it Secs or Msecs?)

	It's not a timeout -- it is an absolute maximum difference 
between client and server, and the value is 1000 seconds.

>                                             I can change the time by a few
>  mins to check if you think that is the better option, all I want to know is
>  if it is re-syncing.  I waited 1/2 hour to an hour.

	Generally speaking, you watch the logs, or you watch the output 
from "ntpq -p".  If you use this command, you simply run it every 
minute or so and watch the values as they change.  You're looking for 
the amount that your server thinks it is offset from the upstream 
time server, which is the next-to-last column in the output from this 
command.

>  No, haven't checked the system log.  In fact to sound dumb, how do I do
>  that?  This version of Linux is very watered down as it is on a switch.

	You should be able to check the log the same way you would any 
other Linux machine.  If not, then you would need to contact your 
vendor for details.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

Geoff <g_wynn@ozemail.com.au> wrote:
> Darren, many thanks.

> Actually the change in time is significant, by years, not seconds.  How can
> I test it is actually re-syncing if the max timeout is 1000 seconds (ok,
> 1000 secs is ok but is it Secs or Msecs?)  I can change the time by a few
> mins to check if you think that is the better option, all I want to know is
> if it is re-syncing.  I waited 1/2 hour to an hour.

Then run 'ntpq -p' and post the output.

Can I back up real quick and ask why you're trying to propogate very
large time changes?  It's entirely possible that you should be using
something other than ntpd to process these changes.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

I am not trying to propogate large time changes really.  Although it appears
this way.  I am trying to test if NTPD is working as it should.  I also have
Cisco Devices and they accept the change of several years etc but not the
Linux Switch.  I was just typing in years as I did not realise NTPD would
drop out etc if the difference in time was more than 1000 Seconds.

On that note, it appears that the NTPD Daemon syncronises on startup to the
NTP server but does not maintain correct time.  It displays the difference
in time, when the NTP server is omved forwards or backwards as in the Daemon
displays 76s or -45s etc but it does not change the actuall time to reflect.

I am still looking into this problem,

Many thanks,

Geoff


"Darren Dunham" <ddunham@redwood.taos.com> wrote in message
news:acpge.1401$Y81.215@newssvr21.news.prodigy.com...
> Geoff <g_wynn@ozemail.com.au> wrote:
> > Darren, many thanks.
>
> > Actually the change in time is significant, by years, not seconds.  How
can
> > I test it is actually re-syncing if the max timeout is 1000 seconds (ok,
> > 1000 secs is ok but is it Secs or Msecs?)  I can change the time by a
few
> > mins to check if you think that is the better option, all I want to know
is
> > if it is re-syncing.  I waited 1/2 hour to an hour.
>
> Then run 'ntpq -p' and post the output.
>
> Can I back up real quick and ask why you're trying to propogate very
> large time changes?  It's entirely possible that you should be using
> something other than ntpd to process these changes.
>
> -- 
> Darren Dunham                                           ddunham@taos.com
> Senior Technical Consultant         TAOS            http://www.taos.com/
> Got some Dr Pepper?                           San Francisco, CA bay area
>          < This line left intentionally blank to confuse you. >

Geoff wrote:

>I am not trying to propogate large time changes really.  Although it appears
>this way.  I am trying to test if NTPD is working as it should.  I also have
>Cisco Devices and they accept the change of several years etc but not the
>Linux Switch.  I was just typing in years as I did not realise NTPD would
>drop out etc if the difference in time was more than 1000 Seconds.
>
>On that note, it appears that the NTPD Daemon syncronises on startup to the
>NTP server but does not maintain correct time.  It displays the difference
>in time, when the NTP server is omved forwards or backwards as in the Daemon
>displays 76s or -45s etc but it does not change the actuall time to reflect.
>
>I am still looking into this problem,
>
>Many thanks,
>
>Geoff
>
>
>"Darren Dunham" <ddunham@redwood.taos.com> wrote in message
>news:acpge.1401$Y81.215@newssvr21.news.prodigy.com...
>  
>
>>Geoff <g_wynn@ozemail.com.au> wrote:
>>    
>>
>>>Darren, many thanks.
>>>      
>>>
>>>Actually the change in time is significant, by years, not seconds.  How
>>>      
>>>
>can
>  
>
>>>I test it is actually re-syncing if the max timeout is 1000 seconds (ok,
>>>1000 secs is ok but is it Secs or Msecs?)  I can change the time by a
>>>      
>>>
>few
>  
>
>>>mins to check if you think that is the better option, all I want to know
>>>      
>>>
>is
>  
>
>>>if it is re-syncing.  I waited 1/2 hour to an hour.
>>>      
>>>
>>Then run 'ntpq -p' and post the output.
>>
>>Can I back up real quick and ask why you're trying to propogate very
>>large time changes?  It's entirely possible that you should be using
>>something other than ntpd to process these changes.
>>
>>-- 
>>Darren Dunham                                           ddunham@taos.com
>>Senior Technical Consultant         TAOS            http://www.taos.com/
>>Got some Dr Pepper?                           San Francisco, CA bay area
>>         < This line left intentionally blank to confuse you. >
>>    
>>
>
>
>  
>
I think you may be working under a misapprehension!!  ntpd does not 
"set" the clock to whatever random time value it gets from a server.   
It assumes that time is monotonically increasing at a rate of one second 
per second and responds to large jumps with disbelief!

ntpd will not attempt to correct any error greater than 1024 seconds 
(about 17 minutes), the "panic threshold".  It assumes that someone has 
lost his mind and exits.

To start ntpd, you need to set your clock to approximately the correct 
time; the closer the better.  Use your wristwatch, your cellular phone, 
wall clock or whatever you have available.   If you are within seventeen 
minutes, ntpd will figure it out eventually.  The closer your clock is 
to the correct time, the faster ntpd will synchronize it.    The maximum 
rate at which ntpd will slew the clock is limited to 500 parts per 
million or 500 microseconds per second.   An error of 17 minutes will 
take days to correct!

Most people still use ntpdate to set the clock initially although 
ntpdate is "deprecated".   The supported way is to use nptd -g which 
allows a one time "step" though I believe the panic threshold still applies.

You should really try to read and understand the  Documentation 
<http://www.eecis.udel.edu/%7Emills/ntp/html/index.html>

In article <fn_je.724$oj7.17795@nnrp1.ozemail.com.au>,
Geoff <g_wynn@ozemail.com.au> wrote:

> NTP server but does not maintain correct time.  It displays the difference
> in time, when the NTP server is omved forwards or backwards as in the Daemon
> displays 76s or -45s etc but it does not change the actuall time to reflect.

76 or 45 seconds are large steps.  Time itself doesn't step, but the 
measurement can step by the variability in the differential propagation
time of the protocol messages.  That will be typically under 50ms and
never more than 2 (1?) seconds (as this would involve a step from 
maximum root distance in one direction to the same in the other direction).

Your large steps won't resolve until enough samples (possibly at a 1024
second poll interval) have been accumulated for the filters to output
the revised time and until after a further sanity check period of about
quarter of an hour has expired, and then until after the five or six 
minutes for the filters to prime themselves with times consistent with
the new idea of reality.

It's also possible that you have disabled stepping, in which case
the the correction rate will be limited to +/- 500ppm relative to the
actual local clock free running frequency.  If that frequency is poor,
the absolute rate may be close to zero in one direction and close to
1,000 ppm in the other.

The error recovery mechanisms will eventually cope with changing to or
from a good clock or between bad clocks (the latter case applies for
free running LCL clock sources), but this is error recovery, not a
normal function.

The correct way of verify lock is to look at the stratum and reference
ID for the machine or to use ntpq to check that a peer has been selected,
and that the frequency correction has stabilised.

Geoff,

Geoff wrote:
[...]
> NTP server but does not maintain correct time.  It displays the difference
> in time, when the NTP server is omved forwards or backwards as in the
> Daemon displays 76s or -45s etc but it does not change the actuall time to
> reflect.

Where have you observed those values? Are you aware that the billboard
printed by the "ntpq -p" command displays offsets in milliseconds, not in
seconds?

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany