Re: Acqusition of time

["Martin Peikert" <Martin.Peikert () discon de>]

Reckhard, Tobias wrote:

> ntpd periodically (every hour, I believe) saves the current clock drift to a

From the man page: it's true what you - em, believe.

> drift file, typically /etc/ntp.drift. When the daemon starts, it initializes
> the drift of its state machine using the value in this file in an effort to
> speed up synchronisation (and especially it settling down). I believe it
> will apply this correction to the clock even when running in an
> unsynchronised state, i.e. when it can't reach any reliable peers or
> servers.

But in comparison to clockspeed, the ntp driftfile is written every hour 
- a quite small amount of time to calculate the drift.

> You shouldn't make the typical mistake of configuring the local clock as a

Of course, you should read (and understand) the fine man page ;-)

> > | clockspeed uses a hardware tick counter to compensate for a
> > | persistently fast or slow system clock. Given a few time 
> > | measurements  from a reliable source, it computes and then
> > | eliminates the clock  skew.
>
> Of course this only works as long as the clock skew is constant, resulting
> in linear drift if uncompensated. This is an OK assumption for quartzes
> running at fixed levels of temperature, such as the clocks in always-on
> servers in a thermally controlled server room. It is not OK for your typical
> workstation. 

Didn't we talk about servers, firewalls IIRC, where logs are 
time-critical? Anyway, if your servers are in a thermically controled 
room (as I thope they are ;-), clockspeed will do the job.

> > | Typical success story: I started clockspeed on one of my Pentium
> > | computers at home on 1998-05-05. I ran sntpclock (through a 28.8
> > | dialup line) once on 1998-05-05 and once on 1998-05-30. On 
> > | 1998-08-22,  after no network time input for nearly three months, the
> > | clock was just 0.21 seconds off.
>
> This rating is rather subjective, of course. .21 seconds equates to 210 ms,

Right, I never said anything contrary. It's not my opinion, it's a quote 
from djb`s site and I'm sorry if I didn't indicate that in that way that 
everybody could see that at once.

> > So, if a firewall can't reach an NTP server a longer time, I would
> > think that you really have a problem ;-) But for a sufficient length
> > of time clockspeed will do the job and keep the time from drifting
> > too far...
>
> Could be that ntpd will, too.

Could be? Could be that ntpd will _not_. Are you sure or not?

> I myself prefer to have a stratum 1 source in the management network that

Yeah, that's what I prefer, too. But then I do not have to worry about 
external ntp servers and setting time and date on any of my servers - if 
I had a stratum 1 source in my network, I would never need anything 
_like_ clockspeed. But that wasn't the assumption of Ben Nagy I answered:

Ben Nagy wrote:
> If a firewall can't reach an NTP server because of some transient
> network condition the clock doesn't automatically go haywire - it will
> just startdrifting as per the normal accuracy of the hardware clock,
> no?

So, I just wanted to give the hint that clockspeed is able to do a good 
job if there is *temporarily no ntp source available*.

> Of course, when faced with The Real World (TM) this  setup often
> remains a dream..

ACK.

GTi

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards