Why aren'y you recording all cdr's in GMT and adjusting call log displays as needed based on where the customer wants to see the call log in? Colin On Nov 6, 2009, at 11:06 AM, David Hiers wrote:
My system clocks are all within 1 second of time.gov just days after the DST change. We made the jump all at once, got double the number of hourly CDR files for an hour, and will get no CDR files for an hour in the spring. Don't think that we did anything special...
What do your clocks look like today?
We show start time and duration for customer-facing reports.
David
On Thu, Nov 5, 2009 at 9:28 PM, James Hess <mysidia at gmail.com> wrote:
The NTP protocol uses UTC as reference time; UTC is a time zone that has no DST changes. If the real-time clock on a device is kept in a local time, the NTP implementation on the device has to translate to UTC and back. There should be no difference in the calculated UTC time before, or after time change caused by DST.
On Thu, Nov 5, 2009 at 4:34 PM, Jonathan Thurman <jonathan at thurmantech.com> wrote:
On Thu, Nov 5, 2009 at 3:16 PM, David Hiers <hiersd at gmail.com> wrote: [...] It is the responsibility of the operator to get the clock in sync to start with, then NTP will adjust for the natural drift.
Adjusting clocks by large amounts by default can be dangerous.. there might be an accident on another NTP server. An evil hacker who can forge NTP packets may have cracked an expired Kerberos TGT, or may desire that a server execute a certain cron job over and over again....
If the time is off by less than 128ms, NTP will slew. If it's off by more than that NTP will often step (make a large error correction) instead. But there is a "panic" limit to the error corrections. If the clock is too far off, NTP will simply exit. You can change the number of seconds, or set it to be unlimited [at own risk]:
tinker panic 0 ...
In certain *ix distros, you also get stepping at NTP startup according to entries made in an /etc/ntp/step-tickers
-- -J
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops