How to fix timing problems in the realtime page when using MySQL storage
2007-02-20If you run QueueMetrics with MySQL storage mode, you will likely have QueueMetrics reside on a
server that will be different from the one Asterisk is, and might as
well be different from the one MySQL is.
If the clocks of all or some of those those machines have small discrepancies, this can lead to minor problems with the realtime page, showing calls with negative or positive length offsets and sometimes completely ignoring the shortest of calls.
Those problems will be experienced only with the realtime page, while the standard reports are unaffected (as they compute durations from actual data and not by inferring them from the local time).
To fix those problems, we strongly suggest you use a high-precision time syncing utility like the NTP package found in most Linux distros, and that you run it on all servers involved (Asterisk, QueueMetrics and MySQL) in order to have highly coherent timing and logging data.
To do this, simply run the following command as root to fix your system clock:
If the clocks of all or some of those those machines have small discrepancies, this can lead to minor problems with the realtime page, showing calls with negative or positive length offsets and sometimes completely ignoring the shortest of calls.
Those problems will be experienced only with the realtime page, while the standard reports are unaffected (as they compute durations from actual data and not by inferring them from the local time).
To fix those problems, we strongly suggest you use a high-precision time syncing utility like the NTP package found in most Linux distros, and that you run it on all servers involved (Asterisk, QueueMetrics and MySQL) in order to have highly coherent timing and logging data.
To do this, simply run the following command as root to fix your system clock:
ntpdate ntp.ien.it
We strongly suggest running it daily using a cron job so that you make sure the servers are
consistently time-aligned in the future.