Anthony,<div><br></div><div>There&#39;s previously been a discussion captured on <a href="http://wiki.freeswitch.org/wiki/Clock">http://wiki.freeswitch.org/wiki/Clock</a> regarding the internal clock time FS keeps.</div><div>

<br></div><div>Currently FreeSWITCH uses the monotonic clock and ignores system time. On machines where the time is very unreliable, NTP isn&#39;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.</div>

<div><br></div><div>However, on systems correctly running ntpd that have clock drift the system time will constantly be being corrected and won&#39;t experience large jumps and in these cases the system time will be more accurate than FreeSWITCH&#39;s internal time.</div>

<div><br></div><div>On such systems although FreeSWITCH might not be losing billing seconds from clock jumps (which shouldn&#39;t normally happen) the clock drift will mean that there is also that clock drift present in FreeSWITCH&#39;s CDRs - and these could conceivably cause billing disputes where a customer&#39;s CDRs do not have the same times because their times are more accurate than FS&#39;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&#39;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.</div>

<div><br></div><div>Obviously there is the sync_clock option, but it seems you shouldn&#39;t need to run that frequently (and would that cause any sideeffects?) Running it infrequently would cause the same time-jumping behaviour FS&#39;s internal time was designed to avoid, and sync_clock_when_idle isn&#39;t possible on busier systems.</div>

<div><br></div><div>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)?</div><div><br></div>

<div>Your thoughts please...</div><div><br></div><div>Warm regards,</div><div>-Steve</div>