RE: Acqusition of time

["Reckhard, Tobias" <tobias.reckhard () secunet com>]

Martin Peikert wrote:
> Reckhard, Tobias wrote:
>
> But in comparison to clockspeed, the ntp driftfile is written 
> every hour 
> - a quite small amount of time to calculate the drift.

Oh, but it (ntpd) doesn't do that. In contrast to clockspeed, ntpd
continually monitors and corrects the local software clock, mostly by
modifying its speed, and using rather sophisticated (but low-impact) data
grooming and clock modeling algorithms. It always has a notion of the
clock's drift, which, once ntpd has settled down and in a favourable
environment, only changes very slowly, if at all over time. ntpd writes that
value to the filesystem every hour. But the value is not derived from the
past hour, but rather a much longer time.

DJB, true to his nature, doesn't provide a lot of detail on
http://cr.yp.to/clockspeed.html about how clockspeed works. He says it takes
"a few measurements" from "a reliable source" to calculate the drift. He
doesn't say how many measurements in how big a timeframe.

> From what he says, I also gather that clockspeed itself makes no attempt to
judge the validity or quality of the source, while ntpd does. This is no
criticism, just an observation. It is fully consistent with DJB's software
development habits. However, I am not aware of a toolset that, in
conjunction with clockspeed, is able to duplicate (most of) ntpd's
functionality, in the way that djbdns is able to replace BIND. If something
similar existed, I'd happily switch myself.

[clockspeed's range of adequacy]
> 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.

I agree completely. You should make sure your clocks don't jump around (like
those of some SGIs do) and adjust your clockspeed polling rate to the
offsets you're willing to bear.

I just wanted to point out where clockspeed's useful realm of applicability
ends. ntpd contains code to be able to constantly and dynamically adjust to
a changing environment. clockspeed doesn't, so you need to either ensure
that your environment won't change or take measures to compensate for that
yourself. That's all, no opinion stated.

> > 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.

That's what spurred my remark. I know the quote and just wanted to have it
seen from a different perspective. I didn't take it for your opinion.

> > > 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'm not sure. I have read the entire documentation of the ntp distribution,
but it's been a while and I don't have the equipment nor have I had the time
to research many things for myself. And back when I was researching NTP and
the distribution, there were some things in its behaviour that puzzled me. I
prefer to verify claims for myself and until then, I won't utter them
without mention of doubt. This is one of those situations. I know ntpd could
behave in the manner described, but I haven't verified it myself. Maybe I'll
give that a try in our lab in the near future. I'd love to have a stratum 1
first, though...

> 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:

True. I wasn't referring to Ben's post, but rather responding to your's. And
providing some opinion of my own. Sorry if I didn't make that clear.

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