[Ky.]

Alex-68, а вот на эту тему я изрядно работал в свое время ))
Собственно, первый источник косяка - сам модуль времени. По крайней мере, в старых модификациях модулей GPS (призводителя модулей не знаю - не участвовал в потрохах), которые и моя контора использовала, был косяк - время от времени происходил скачок то на секунду вперед, то назад. Особенно, когда антенна не находится в зоне уверенного приема - ЕМНИП, как минимум, 120° сектор свободного обзора на юг. Опять же, нынче часто применяются гибридные модули GSM/ГЛОНАС, а у них тоже время немного отличается.
В контроллере источника, который работает с модулем GSM и обеспечивает внешний интерфейс, тоже могут быть свои баги.

Далее идет передача от модуля к серверу
Спутниковые часы в твоих системах время по NTP отдают или по последовательному каналу?
И там и там возможны нюансы.
В первом случае, дефолтные настройки NTP клиента в Винде дают точность примерно как прогноз погоды. Даже если ты указываешь адрес источника, запросы к нему будут ходить раз в несколько часов, в лучшем случае. Для исправления этого безобразия надо лезть в реестр.
Во втором, обычно сказывается сильное влияние неравномерной загрузки ЦП на задержки в обработке принимаемых пакетов со временем. Обычно приходится задавать максимальный приоритет потокам чтения из СОМ-порта и синхронизации времени. Ну и еще есть алгоритмические трюки по вычислению фактического отклонения времени..

Синхронизация от сервера к контроллерам и приборам учета/контроля/измерения тоже полна сюрпризов. Начать с того, что большинство производителей тупо периодически шлет в канал связи с контроллерами текущее время сервера. А связь с объектами обычно построена на виртуальных СОМ-портах через сеть. Сеть означает неопределенную задержку, при передаче текущего времени получаем пляски. Да и по сети.. колхозные реализации МЭК-104 тоже обычно так же действуют.

Всё, хватит пока. Работа опять привалила.