FreeSWITCH, NTP daemon and clock drift
Anthony, There's previously been a discussion captured on http://wiki.freeswitch.org/wiki/Clock regarding the internal clock time FS keeps. Currently FreeSWITCH uses the monotonic clock and ignores system time. On machines where the time is very unreliable, NTP isn't in use and the sysadmin is changing the time manually or by ntpdate the system time can make large jumps - and I can indeed see the reasoning that having FS use its own clock on these systems is more reliable as it prevents billing time being lost because of a large clock jump. However, on systems correctly running ntpd that have clock drift the system time will constantly be being corrected and won't experience large jumps and in these cases the system time will be more accurate than FreeSWITCH's internal time. On such systems although FreeSWITCH might not be losing billing seconds from clock jumps (which shouldn't normally happen) the clock drift will mean that there is also that clock drift present in FreeSWITCH's CDRs - and these could conceivably cause billing disputes where a customer's CDRs do not have the same times because their times are more accurate than FS's due to that clock drift. This is unlikely to be large enough to affect billed minutes much, but could put a large number of calls on the wrong billing rate (eg if FS's internal time in the CDRs identifies calls as on a peak rate when the customer believes it is on an offpeak rate). On a badly drifting system over a month on a large volume of calls that could become a noticeable discrepancy. Obviously there is the sync_clock option, but it seems you shouldn't need to run that frequently (and would that cause any sideeffects?) Running it infrequently would cause the same time-jumping behaviour FS's internal time was designed to avoid, and sync_clock_when_idle isn't possible on busier systems. On systems running ntpd perhaps it would be worth adding an opt-in option that lets FreeSWITCH use the system time and rely on ntpd (but keeping the present behaviour as the default)? Your thoughts please... Warm regards, -Steve
My first instinct is to say: don't use boxes with unreliable timing in them since if they can't keep time, the precision for audio could be even worse. But, Its not an unreasonable request give this param a try in latest git: enable-use-system-time in switch.conf.xml the status uptime should still be right but the timestamps etc will follow system time. use at your own risk On Tue, Jul 3, 2012 at 2:36 PM, Steven Ayre <steveayre@gmail.com> wrote:
Anthony,
There's previously been a discussion captured on http://wiki.freeswitch.org/wiki/Clock regarding the internal clock time FS keeps.
Currently FreeSWITCH uses the monotonic clock and ignores system time. On machines where the time is very unreliable, NTP isn't in use and the sysadmin is changing the time manually or by ntpdate the system time can make large jumps - and I can indeed see the reasoning that having FS use its own clock on these systems is more reliable as it prevents billing time being lost because of a large clock jump.
However, on systems correctly running ntpd that have clock drift the system time will constantly be being corrected and won't experience large jumps and in these cases the system time will be more accurate than FreeSWITCH's internal time.
On such systems although FreeSWITCH might not be losing billing seconds from clock jumps (which shouldn't normally happen) the clock drift will mean that there is also that clock drift present in FreeSWITCH's CDRs - and these could conceivably cause billing disputes where a customer's CDRs do not have the same times because their times are more accurate than FS's due to that clock drift. This is unlikely to be large enough to affect billed minutes much, but could put a large number of calls on the wrong billing rate (eg if FS's internal time in the CDRs identifies calls as on a peak rate when the customer believes it is on an offpeak rate). On a badly drifting system over a month on a large volume of calls that could become a noticeable discrepancy.
Obviously there is the sync_clock option, but it seems you shouldn't need to run that frequently (and would that cause any sideeffects?) Running it infrequently would cause the same time-jumping behaviour FS's internal time was designed to avoid, and sync_clock_when_idle isn't possible on busier systems.
On systems running ntpd perhaps it would be worth adding an opt-in option that lets FreeSWITCH use the system time and rely on ntpd (but keeping the present behaviour as the default)?
Your thoughts please...
Warm regards, -Steve
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (2)
-
Anthony Minessale
-
Steven Ayre