[ntp:questions] ntpd questions - FreeBSD 5.5
tglassey at earthlink.net
Mon Jul 20 15:55:38 UTC 2009
Danny Mayer wrote:
> David Shoulders wrote:
>> Danny -
>> I don't have a critical need for accuracy, so I didn't want to add any
>> more load to the servers than necessary. I thought that a few hits 4
>> times a day would be a smaller load than running the daemon all the
>> time. Now that my computer's clock seems to be running inconsistently,
>> the load from the ntpd running continuously would be even higher, right?
> You won't notice any load running ntpd, it is almost invisible. I have
> run ntpd and targeted 200 simultaneous clients at it for a load test and
> it was like it was not not running. A server sends out a packet at most
> once every 64 seconds (these are using default settings) per server
> specified in the configuration file and usually much less frequently if
> it has been running for a while.
>> BTW, new data on my little mystery: the computer clock seems to gain
>> time (like 2 seconds in 3 hours) during times when I'm using my other
>> systems -- never when idling.
So do a time-query every minute and track the offset and them map the
logs to that set of offsets. If there are financial records in the
system once a daily operations period is started there must only be
monotically incremental time-stamps in the logging system so creating an
external 'map' to realign those log entries is the right solution from
an audit perspective.
>> This even though the computer is just
>> providing nfs service and occasional backups.
yea - life is like that when you use cheap gear. It drifts all over the
>> Shouldn't an increase in
>> average load slow the clock (by masking more interrupts)?
> It sounds like the clock needs to be disciplined and by not running ntpd
> continuously the clock is drifting too much.
You could as long as the steering discipline never incremented in the
> The question of the affect
> of load on the clock depends on how it handles interrupts.
yep, but with many embedded controllers much of the overhead (like
framing packets and qualifying them) is now done in the Interface so the
OS never sees this overhead. This is one of the design flaws with how
NTP exists today.
> Linux has had
> that problem for years of losing interrupts while FreeBSD never has a
Not quite true... Any system (FreeBSD included) with Interrupt
Coalescence in the driver's will lose interrupts or defer them, so this
happens in many 1G networks and in all of the faster (10G) Ethernet
deployments I have tested unless its specifically disabled.
> Run ntpd continuously and see if that solves your problem.
Which opens a huge security problem - you should ONLY run NTPd on
systems which are serving time to other systems. Otherwise a simple CRON
process to every minute test the existing setting of the time from a
reliable set of reference systems totally answers this problem.
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/19/09 17:59:00
More information about the questions