Comments 10
Подход с синхронизацией времени может оказывать влияние на полученные данные, потому что нет гарантии точной синхронизации времени на всех серверах тем более в случае с ntp. Рекомендую обратить внимание на ptpd он может обеспечить наиболее точное время в рамках группы хостов.
Обратите внимание на TWAMP и его реализацию от perfSONAR.
Эм. Самый очевидный и простой способ распознавания асимметричного пинга — это вовсе не таймстампы, а трассировка. Так как асимметричный пинг, как верно замечено в статье, обычно является следствием асимметричного маршрута — достаточно изучить маршрут (и пинги до всех его узлов) чтобы всё понять.
Если же маршрут симметричный, или по какой-то причине его невозможно исследовать, то всё может оказаться не так радужно, как думает автор. Если время на серверах синхронизируется через тот же канал с ассиметричным пингом — то ничего из этого не получится. В таком случае (не имея доп. каналов связи) невозможно (строго невозможно) отличить симметричный пинг 50+50 и правильное время "там" от пинга 70(туда)+30(обратно) и отстающего на 20мс времени "там".
Как изучить обратный маршрут не имея доступа к удалённому узлу?
В большинстве случаев можно обойтись анализом аномалий в пингах к узлам прямого маршрута. Ещё можно TTL эхо-ответов учитывать, но и это редко нужно.
Как изучить обратный маршрут не имея доступа к удалённому узлу?
Не раз приходилось "изучать" асимметричность маршрута. Обычно запускали traceroute -A dsthost, и искали LookingGlass начиная от ближайшего к dsthost провайдера (по asnum искали, кто пров, и есть ли у него лукин гласс вообще, если есть — обычно с функциями ping/traseroute). Если кто-то знает лучший способ — поделитесь, плиз.
Скажите пожалуйста, чем это вы так красиво нарисовали график ошибок NTP от GPS?
Как эффективно разделить пинг