# Asymmetric latency measurement tool

**URL:** <https://community.ntppool.org/t/asymmetric-latency-measurement-tool/3336>\
**Category:** Client Configuration and Development\
**Created:** [April 8, 2024, 3:37pm UTC](https://community.ntppool.org/t/asymmetric-latency-measurement-tool/3336 "2024-04-08T15:37:36Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\
**Post date:** [April 8, 2024, 7:31pm UTC](https://community.ntppool.org/t/asymmetric-latency-measurement-tool/3336/8 "2024-04-08T19:31:06Z")

</div>

I’ve done extensive measurements using standard NTP. See [Multiple Network Paths](http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf) in my PTTI paper.  
Some comments:

- If the NTP server or NTP client have local times that differ significantly (milliseconds or larger) the calculated asymmetry will be incorrect. This risk also exists with the custom UDP described in this thread.

- The unidirectional delay may depend on which UDP ports are used. I monitor NTP using multiple UDP client ports.

- NTP server implementations can have weird bugs. Using custom UDP programs as done by Badeand might avoid many of these.

- The UDP port used by NTP (123) is sometimes the target of [middleboxes](https://www.rfc-editor.org/rfc/rfc3234) which can result in drops and unexpected delays. The custom UDP program may help.

---

_[View the full topic](https://community.ntppool.org/t/asymmetric-latency-measurement-tool/3336)._