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