[Freeswitch-users] FreeSWITCH, NTP daemon and clock drift

[Anthony Minessale]

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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.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 at 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 at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900