Another source of skew is multi-processor systems. I'm not sure if it applies to multi-core, but I would guess it does. Peter Beckman wrote:
On Wed, 4 Nov 2009, Colin wrote:
GMT for the win.
Agreed, though we use UTC. While GMT and UTC are mostly the same, UTC is based on atomic time and includes leap seconds that are added occasionally to account for the irregularity in the earth and sun's movements. We decided UTC was a more accurate and "official" representation of time. GMT is based on the hypothetical average day at Greenwich, which is much less scientifically accurate.
Everything in our system is stored as UTC, and we convert on a per-user basis when displaying call logs and the like. That way we avoid any issues with DST.
I would make all of your CPE devices on UTC as well. It avoids confusion about what time zone any date/time in your system is on the back end. Build the conversion into your front-end systems and reporting on a per-customer basis.
You also avoid calls that were really 4 minutes, but get billed as -56 minutes or 64 minutes for calls during the change from/to DST.
In discussing time, one of my providers avoids syncing their servers to the correct time on an ongoing basis (i.e. with ntpd), with the argument that if they sync during calls, billing would be wrong. Some of there servers therefore skew a LOT, and sometimes their call servers can be off the real time by _HOURS_ (I suspect this is due to running Asterisk on VMs which are notoriously bad at keeping time). I've griped about it, but they say they only sync the time when there are no calls at midnight, which never happens.
Has anyone else been frustrated by the lack of punctuality/analness when it comes to making sure clocks are accurate when it comes to call records?
Beckman ---------------------------------------------------------------------------
Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops