Time Synchronization

The Root of All Timing: Understanding root delay and root dispersion in NTP

February 25, 2021 by Douglas Arnold 2 Comments

Five Minute Facts About Packet Timing

If you examine an NTP packet you will see the fields root delay and root dispersion.  See the diagram from RFC 5905 in Figure 1 bellow, which defines NTP version 4, the current version.

ntp round trip delay

You might ask what is with all this “root” stuff?  Root in this case refers to the root of the time distribution spanning tree.  The root is a stratum 1 NTP server.  Something that usually has a GNSS receiver to get UTC.  If you are particularly fond of tree analogies, you can think of higher stratum NTP servers as branches, and clients as the leaves. 

The root delay is the round-trip packet delay from a client to a stratum 1 server.  This is important because it gives a crude estimate of the worst-case time transfer error between a client, or higher stratum server acting as a client, and a stratum 1 server.  In fact, it is the worst-case contribution to the time transfer error due to network asymmetry , if all of the round-trip delay was in one direction and none in the other direction.  Okay some of the network delay has to be in each direction, but this is an upper bound. The root delay is also used in clock steering algorithms to identify false tickers, that is servers with bad time or one’s that are sitting on the other side of a highly asymmetric network path. So, it is important. 

The root dispersion tells you how much error is added due to other factors.  One factor is the error introduced by a client due to the inaccuracy of its clock frequency.  Using NTP the higher stratum can set its clock to the lower stratum server, but if its clock frequency is off, then an error is introduced.

Recall that an NTP time transfer involves four timestamps as shown in Figure 2.

ntp round trip delay

From the four timestamps the offset of the client with respect to the server is known and the round-trip delay from the client to the server and back. 

Offset = [(t2 + t3) – (t4 + t1)]/2

Delay = (t4 -t1) – (t3 – t2)

Dispersion = DR * (t4 – t1) + timestamping errors

Where DR is the drift rate of client clocks time and is equal to the fractional frequency error.  The timestamping errors term includes things like the errors due to the finite resolution of the clock, and delays in reading the clock when fetching a timestamp. The sum of root dispersion and half the root delay is called the root distance and is the total worse case timing error accumulated between the stratum 1 server and the client.

When a client gets time from a higher stratum receiver the root delay is the sum of the delays from all of the client-server pairs in the timing spanning tree.  In the case when a client is getting time from multiple servers, the best root delay is used.  This applies to root dispersion as well.  An example is shown in Figure 3.

ntp round trip delay

Okay so you are ready to amaze your friends with your mastery of NTP root delays and root dispersion.

If you have any questions about packet timing, don’t hesitate to send me an email at  doug.arnold@meinberg-usa.com , or visit our website at  www.meinbergglobal.com .

  • share  
  • share    

Related posts:

  • NTP Monitoring
  • Network Time Security (NTS): Updated security for NTP
  • Leap Second Test
  • The virtues of clock watching: Why it’s important to monitor your timing network

' src=

May 30, 2023 at 9:44 am

Why do root servers (stratum 1) have zero dispersion? While a refclock probably has no dispersion by definition, the clock following the refclock is not perfect. Similarly for root delay: Even when the refclock is the “perfect time”, doesn’t the startum-1 server has to communicate with the refclock, introducing some non-constant delays?

' src=

June 1, 2023 at 9:28 pm

You are correct that a real implementations of stratum 1 servers are not perfect. However the definitions for root delay and root dispersion in the RFCs that define versions of NTP do not include any imperfections in stratum 1 servers. In practice, it is nearly always true that the limitations of the server are negligible compared to the delay and dispersion contributions from the network.

Share Your Comments & Feedback Cancel reply

  • Site Notice
  • Privacy Policy

You may also like

  • PTP / IEEE 1588
  • Configuration Guidelines
  • Industry Applications

Network Encyclopedia Logo

Mastering Network Time Protocol (NTP): A Comprehensive Guide

Last Edited

In the complex orchestration of networked systems, time is not merely a ticking clock; it’s a crucial variable that affects performance, synchronization, and security. In the age of global networks and distributed systems, maintaining time consistency across all nodes becomes paramount. How do we ensure that each component of a system is perfectly synchronized in time? Enter Network Time Protocol (NTP), the unsung hero of network synchronization.

Table of Contents:

What is Network Time Protocol (NTP)?

Mechanisms of ntp, the ntp packet, how to configure an ntp server, security aspects of ntp, ntp vs. other time-keeping protocols, troubleshooting common ntp issues, case studies, further reading and resources.

This comprehensive guide aims to unravel the complex web of NTP, shedding light on its mechanisms, applications, and pivotal role in contemporary computing.

Network Time Protocol (NTP)

Transitioning from a high-level overview, let’s delve into the foundational elements. Network Time Protocol (NTP) is a networking protocol devised to synchronize the clocks of computers over a data network. Originally developed by David L. Mills in 1985, NTP operates over the User Datagram Protocol (UDP) and aims for high accuracy and fault-tolerant timekeeping. While NTP might appear like a simple task of ‘setting the clock,’ in reality, it addresses numerous challenges—from variable network delays to jitter , to even taking into account the relativistic time dilation effects.

NTP employs a hierarchical, semi-layered architecture of time sources. At the top sits the stratum 0 devices—highly accurate atomic clocks. These feed time to stratum 1 servers, which in turn synchronize stratum 2 servers, and the hierarchy cascades down. This architecture not only provides robustness but also optimizes accuracy by mitigating the compounded errors that can occur in multi-step synchronization processes.

NTP Hierarchical Semi-layered Architecture

Embarking on our exploratory journey through Network Time Protocol (NTP), it is imperative to delve into the core mechanisms that make NTP such a precise and reliable protocol. This chapter aims to demystify the inner workings of NTP, including its clock stratum, poll intervals, and algorithms. Such an understanding will serve as a pivotal foundation for anyone interested in network synchronization, be it students, system administrators, or seasoned tech professionals.

Clock Stratum

To begin, let’s address the hierarchical system of time sources known as the ‘clock stratum.’ In NTP, devices are categorized into different strata based on their proximity to an authoritative time source. Stratum 0 devices are high-precision timekeeping systems—like atomic clocks or GPS clocks—that act as primary references. Subsequently, Stratum 1 servers synchronize directly with these Stratum 0 devices. Stratum 2 servers synchronize with Stratum 1 servers, and the hierarchy continues in a cascading fashion. This tiered system ensures accuracy and minimizes network congestion by controlling the flow of synchronization traffic.

Poll Intervals

Shifting gears to another crucial component, let’s consider the ‘poll interval.’ The poll interval is the duration between successive synchronization messages sent by an NTP client to its server. A smaller poll interval will result in higher accuracy but will also consume more network bandwidth. NTP dynamically adjusts the poll interval based on network conditions, clock stability, and other variables, thus maintaining an optimal balance between accuracy and resource consumption.

Algorithms: Marzullo’s Algorithm and Others

Delving deeper, algorithms are the cornerstone of NTP’s operational excellence. One of the primary algorithms used by NTP for clock synchronization is Marzullo’s Algorithm. Designed to find a time range that is consistent with the largest number of server clocks, it minimizes the impact of outlier clocks that may be significantly off. Moreover, NTP employs other techniques like the ‘clock filter algorithm’ and the ‘Cristian’s algorithm’ to filter out noise from measurements and to estimate the most probable true time.

Other Mechanisms: Jitter and Drift Compensation

Beyond these key components, NTP also addresses challenges like network jitter and clock drift. NTP’s time synchronization messages contain timestamp information that accounts for transmission delay, enabling it to filter out ‘jitter,’ or variations in time due to network congestion. Additionally, NTP employs a local clock algorithm that adjusts the system clock in small increments to avoid abrupt changes, thereby compensating for the drift.

In summary, NTP’s effectiveness stems from its meticulously crafted mechanisms, each designed to solve specific challenges in time synchronization. As we progress through subsequent chapters, these foundational concepts will serve as essential building blocks for a more nuanced understanding of NTP.

As we continue our in-depth exploration of the Network Time Protocol (NTP), it’s essential to focus on the NTP packet. This crucial data structure facilitates the entire time synchronization process, serving as the vehicle that conveys timing information across network devices. Understanding the anatomy of an NTP packet provides valuable insights into how NTP achieves its objectives of accuracy and reliability. This chapter will dissect the structure, fields, and significance of an NTP packet, further equipping students, system administrators, and tech aficionados with the knowledge to grasp NTP’s inner workings.

Packet Structure

Let’s first delve into the basic structure. An NTP packet typically consists of a 48-byte data structure, divided into various fields that carry different types of information. The packet begins with a 4-byte header, followed by various optional fields and timestamps.

Header Fields

Transitioning to the header fields, these are vital for the control and management of the packet. The header comprises several components:

  • Leap Indicator (LI) : 2 bits to notify of an impending leap second to be inserted or deleted in the last minute of the current month.
  • Version Number (VN) : 3 bits specifying the NTP version in use.
  • Mode : 3 bits indicating the mode (client, server, etc.).
  • Stratum : 8 bits representing the stratum level of the local clock.
  • Poll : 8 bits specifying the maximum interval between successive messages.
  • Precision : 8 bits describing the precision of the local clock.
  • Root Delay and Root Dispersion : These 32-bit fields provide information about the round-trip delay and dispersion to the primary reference source.

Shifting gears to perhaps the most critical part of the NTP packet, the timestamps. Four timestamps are used:

  • Reference Timestamp : Records the time when the system clock was last set.
  • Originate Timestamp : Records the time when the request departed the client for the server.
  • Receive Timestamp : Marks the time when the request was received by the server.
  • Transmit Timestamp : Marks the time when the reply departed the server for the client.

The timestamps enable the calculation of round-trip delay and clock offset, two key metrics essential for synchronization.

Optional Fields

While optional, additional fields can be included for authentication and extensions. These fields are used primarily for securing NTP against various types of attacks and for adding extensibility to the protocol.

In sum, each field within an NTP packet serves a specific and crucial function in the grand symphony of network time synchronization. The careful orchestration of these fields ensures that NTP remains a robust, accurate, and adaptable protocol, capable of meeting the stringent demands of modern networks. As we navigate further into the world of NTP, this foundational understanding of the NTP packet will be invaluable.

Pivoting from the theory and structure of NTP, it’s time to dive into practical applications. Specifically, we’ll focus on setting up an NTP server—a crucial step for system administrators aiming to maintain network-wide time synchronization. This chapter provides a hands-on, step-by-step guide to help you get an NTP server up and running.

1. Choosing an OS and NTP Software

First off, you need to select an operating system and NTP software. Linux is often the go-to choice for its robustness and flexibility. NTPd and Chrony are popular software packages for Linux. Install your chosen software using package management tools like apt for Ubuntu or yum for CentOS.

2. Configuration File

After installation, head over to the configuration file, usually located at /etc/ntp.conf or /etc/chrony/chrony.conf , depending on your software. Open the file with a text editor. Here, you define the NTP servers your system will synchronize with. Use reputable, preferably geographically close, Stratum 1 or Stratum 2 servers.

3. Firewall Rules

Don’t forget about firewall settings. Open the NTP port (usually UDP 123) to allow incoming and outgoing NTP traffic. Update your firewall rules accordingly.

4. Test and Monitor

Finally, start the NTP service using service management commands like systemctl . Monitor the synchronization process with commands like ntpq -p or chronyc tracking . Ensure everything works as expected.

To recap, setting up an NTP server involves a few straightforward steps: selecting an OS and software, editing the configuration file, adjusting firewall rules, and monitoring the service. Following this guide ensures that you won’t miss any critical components in the setup process.

Switching gears to a subject of increasing importance, let’s delve into the security aspects of NTP. In a world where cyber threats are ever-present, securing your NTP server isn’t just optional—it’s essential. This chapter will walk you through the key security features and best practices to keep your NTP implementation secure.

Authentication

First and foremost is authentication. NTP supports symmetric key authentication, wherein both the client and server share a secret key. To set this up, include the key and trustedkey directives in your NTP configuration file. This ensures that rogue servers can’t manipulate your system time.

Rate Limiting and Throttling

Next up, consider rate limiting and request throttling. These practices safeguard your server against denial-of-service attacks. Use the discard and restrict directives in your configuration file to set limitations on incoming requests.

Monitoring and Logging

Another vital component is monitoring and logging. Keep an eye on server logs and set up alerts for unusual activities. Monitoring tools can help you quickly identify and act upon any security threats.

Secure Versions and Patches

Lastly, always use secure and updated versions of NTP software. Security vulnerabilities get discovered over time, and keeping your software up-to-date protects you from known threats.

In summary, a secure NTP implementation hinges on multiple pillars: robust authentication, effective rate limiting, vigilant monitoring, and timely updates. By meticulously implementing these measures, you not only secure your NTP server but also contribute to the overall security of your network.

Having illuminated the technical and security facets of NTP, it’s now opportune to contrast it with other time-keeping protocols. This comparison will elucidate why NTP often emerges as the go-to solution for a vast array of applications. We’ll chiefly discuss Simple Network Time Protocol (SNTP) and Precision Time Protocol (PTP).

Simple Network Time Protocol (SNTP)

Firstly, let’s examine SNTP. Essentially a simplified version of NTP, SNTP is easier to implement but offers less accuracy. For small networks or less mission-critical applications, SNTP might suffice. However, it lacks advanced features like clock stratum, making it less ideal for more complex setups.

Precision Time Protocol (PTP)

Moving on to PTP, this protocol aims for extremely high accuracy, often within the nanosecond range. Commonly found in financial and scientific computing environments, PTP employs specialized hardware and is consequently more expensive to implement than NTP.

Key Differences

To sum it up, SNTP is simpler but less accurate, PTP is highly accurate but more costly, and NTP strikes a balance, offering robust features and good accuracy without requiring specialized hardware.

In the final chapter of our comprehensive guide, we pivot to the inevitable challenges: troubleshooting common NTP issues. Understanding how to diagnose and rectify issues is pivotal for anyone responsible for maintaining a network’s time synchronization. Let’s delve into some of the common problems you might encounter.

Time Drift Issues

First on our list is time drift. If you notice that your system time is constantly out of sync, check for high system load or software that might interfere with NTP. Use the ntpq or chronyc commands to analyze drift and make adjustments as necessary.

Connectivity Issues

Secondly, connectivity problems. Ensure that the NTP server is reachable and that your firewall allows traffic on the NTP port (usually UDP 123). Use ping or traceroute commands for basic network diagnostics.

Configuration Errors

Next, let’s tackle configuration errors. These often manifest as synchronization failures. Review your ntp.conf or chrony.conf file to ensure that all server addresses and options are correctly set.

Version Mismatch

Lastly, you might run into version mismatches between your NTP software and the servers you are trying to synchronize with. Always ensure you are running a compatible version, and consider updating if necessary.

In conclusion, troubleshooting NTP issues requires a systematic approach. Armed with these tips and tools, you’re well-equipped to tackle most common issues head-on, ensuring the smooth operation of your NTP service.

After dissecting the mechanics, configurations, and troubleshooting steps of NTP, it’s valuable to see how it operates in the real world. In this chapter, we take an analytical approach to a couple of case studies that demonstrate NTP’s practical implications.

Case Study 1: Financial Services

First up, the financial sector. Precision in timekeeping is vital for transaction logging and fraud detection. In this domain, NTP servers often sync with atomic clocks to attain accuracy within milliseconds. Any deviation can result in severe financial repercussions, making NTP a cornerstone of the industry’s IT infrastructure.

Case Study 2: Telecommunications

Next, let’s focus on the telecommunications sector. Accurate time synchronization is crucial for network operations, especially in mobile networks. When connecting a call or transmitting data packets, timing needs to be impeccably synchronized across various nodes. Here, NTP provides the backbone for accurate data exchange and service delivery.

These case studies show the broad scope and utility of NTP, from safeguarding financial transactions to ensuring the efficacy of telecommunications services.

As we reach the end of this comprehensive guide, let’s pivot towards the avenues where you can deepen your understanding of NTP. Knowledge is ever-evolving, and staying updated is key to adapting to new challenges in time synchronization.

  • “ Computer Networking: A Top-Down Approach ” by James F. Kurose and Keith W. Ross – Covers NTP in the context of network protocols.
  • “ UNIX System Administration Handbook ” by Evi Nemeth et al. – Contains a section on NTP and time synchronization in UNIX systems.

Online Resources

  • NTP official website – For documentation, FAQs, and latest updates.
  • NIST Time and Frequency Division – Offers articles and research on time synchronization protocols including NTP.
  • RFC 958 – Describes the original NTP.
  • RFC 5905 – Current standard for NTP.

Through these resources, you can deepen your expertise, keeping your skills and systems up-to-date in this critical area of network management.

With this, we conclude our in-depth exploration of Network Time Protocol. Armed with this knowledge, you are not just a passive user but a competent administrator or professional who can set up, secure, and troubleshoot an NTP service. Stay curious and keep learning!

  • Skip to content
  • Skip to search
  • Skip to footer

Troubleshoot and Debug Network Time Protocol (NTP) Issues

ntp round trip delay

Available Languages

Download options.

  • ePub (93.3 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
  • Mobi (Kindle) (91.7 KB) View on Kindle device or Kindle app on multiple devices

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document describes how to troubleshoot Network Time Protocol (NTP) issues with   debug    commands and the   show ntp   command.

Prerequisites

Requirements.

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

NTP show Commands

Before you look at the cause of NTP problems, you must understand the use of and output from these commands:

show ntp association

Show ntp association detail, show ntp status.

Note: Use the Command Lookup Tool in order to obtain more information on the commands used in this section. Only registered Cisco users can access internal tools and information.

Note: The Output Interpreter Tool  supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output. Only registered Cisco users can access internal tools and information.

An NTP association can be a peer association (one system is willing to synchronize to the other system or to allow the other system to synchronize to it) or a server association (only one system synchronizes to the other system and not the other way around).

This is an example of output from the show ntp association command:

This is an example of output from the show ntp association detail command:

Terms already defined in the show up association section are not repeated here.

Packet data is valid if tests 1 to 4 are passed. The data is then used in order to calculate offset, delay, and dispersion.

Packet header is valid if tests 5 to 8 are passed. Only packets with a valid header can be used to determine whether a peer can be selected for synchronization.

The sanity checks have failed, so time from the server is not accepted. The server is unsynced.

The peer/server time is valid. The local client accepts this time if this peer becomes the primary.

The peer/server time is invalid, and time cannot be accepted.

Each peer/server is assigned a reference ID (label).

Time is the last time stamp received from that peer/server.

our mode/ peer mode

This is the state of the local client/peer.

our poll intvl/ peer poll intvl

This is the poll interval from our poll to this peer or from the peer to the local machine.

Root delay is the delay in milliseconds to the root of the NTP setup. Stratum 1 clocks are considered to be at the root of an NTP setup/design. In the example, all three servers can be the root because they are at stratum 1.

root dispersion

Root dispersion is the maximum clock time difference that was ever observed between the local clock and the root clock. Refer to the explanation of 'disp' under show up association for more details.

This is an estimate of the maximum difference between the time on the stratum 0 source and the time measured by the client; it consists of components for round trip time, system precision, and clock drift since the last actual read of the stratum source.

In a large NTP setup (NTP servers at stratum 1 in the internet, with servers that source time at different strata) with servers/clients at multiple strata, NTP synchronization topology must be organized in order to produce the highest accuracy, but must never be allowed to form a time sync loop. An additional factor is that each increment in stratum involves a potentially unreliable time server, which introduces additional measurement errors. The selection algorithm used in NTP uses a variant of the Bellman-Ford distributed routing algorithm in order to compute the minimum-weight spanning trees rooted on the primary servers. The distance metric used by the algorithm consists of the stratum plus the synchronization distance, which itself consists of the dispersion plus one-half the absolute delay. Thus, the synchronization path always takes the minimum number of servers to the root; ties are resolved on the basis of maximum error.

This is the round trip delay to peer.

This is the precision of the peer clock in Hz.

This is the NTP version number used by the peer.

This is the time stamp of the NTP packet originator; in other words, it is the peer time stamp when it created the NTP packet but before it sent the packet to the local client.

This is the time stamp when the local client received the message. The difference between org time and rcv time is the offset for this peer. In the example, primary 10.4.2.254 has these times:

The difference is the offset of 268.3044 msec.

This is the transmit time stamp for the NTP packet the local client sends to this peer/server.

filtdelay filtoffset filterror

This is the round trip delay in milliseconds of each sample. This is the clock offset in milliseconds of each sample. This is the approximate error of each sample.

A sample is the last NTP packet received. In the example, primary 10.4.2.254 has these values:

These eight samples correspond to the value of the reach field, which shows whether the local client received the last eight NTP packets.

This is an example of output from the show ntp status command:

Terms already defined in the show up association section or the show ntp association detail section  are not repeated.

Troubleshoot NTP with Debugs

Some of the most common causes of NTP issues are:

  • NTP packets are not received.
  • NTP packets are received, but are not processed by the NTP process on the Cisco IOS.
  • NTP packets are processed, but erroneous factors or packet data causes the loss of synchronization.
  • NTP clock-period is manually set.

Important debug commands that help isolate the cause of these issues include:

  • debug ip packets <acl>

debug ntp packets

Debug ntp validity.

  • debug ntp sync
  • debug ntp events

The next sections illustrate the use of debugs in order to resolve these common issues.

Note: Refer to Important Information on Debug Commands before you use debug commands.

NTP Packets Not Received

Use the debug ip packet command in order to check if NTP packets are received and sent. Since debug output can be chatty, you can limit debug output with the use of Access Control Lists (ACLs). NTP uses User Datagram Protocol (UDP) port 123.

  • Create ACL 101: access-list 101 permit udp any any eq 123 access-list 101 permit udp any eq 123 any NTP packets usually have a source and destination port of 123, so this helps: permit udp any eq 123 any eq 123
  • Use this ACL in order to limit output from the debug ip packet command: debug ip packet 101
  • If the issue is with particular peers, narrow the ACL 101 down to those peers. If the peer is 172.16.1.1, change ACL 101 to: access-list 101 permit udp host 172.16.1.1 any eq 123 access-list 101 permit udp any eq 123 host 172.16.1.1

This example output indicates that packets are not sent:

Once you confirm that NTP packets are not received, you must:

  • Check if NTP is configured correctly.
  • Check if an ACL blocks NTP packets.
  • Check for routing issues to the source or destination IP.

NTP Packets Not Processed

With both debug ip packet and debug ntp packets commands enabled, you can see the packets that are received and transmitted, and you can see that NTP acts on those packets. For every NTP packet received (as shown by debug ip packet ), there is a correspondent entry generated by debug ntp packets .

This is the debug output when the NTP process works on received packets:

This is an example where NTP does not work on received packets. Although NTP packets are received (as shown by debug ip packets), the NTP process does not act on them. For NTP packets that are sent out, a corresponding debug ntp packets output is present, because the NTP process has to generate the packet. The issue is specific to received NTP packets that are not processed.

Loss of Synchronization

Loss of synchronization can occur if the dispersion and/or delay value for a server goes very high. High values indicate that the packets take too long to get to the client from the server/peer in reference to the root of the clock. So, the local machine cannot trust the accuracy of the time present in the packet, because it does not know how long it took for the packet to get here.

NTP is meticulous about time and can not synchronize with another device it cannot trust or cannot adjust in a way so that it can be trusted.

If there is a saturated link and buffering occurs along the way, the packets get delayed as they come to the NTP client. So, the timestamp contained in a subsequent NTP packet can occasionally vary a lot, and the local client cannot really adjust for that variance.

NTP does not offer a method to turn off the validation of these packets unless you use SNTP (Simple Network Time Protocol). SNTP is not much of an alternative because it is not widely supported in software.

If you experience loss of synchronization, you must check the links:

  • Are they saturated?
  • Are there any kinds of drops in your wide-area network (WAN) links
  • Does encryption occur?

Monitor the reach value from the show ntp associations detail command. The highest value is 377. If the value is 0 or low, NTP packets are received intermittently, and the local client goes out of sync with the server.

The debug ntp validity command indicates whether the NTP packet failed sanity or validity checks and reveals the reason for the failure. Compare this output to the sanity tests specified in RFC1305 that are used in order to test the NTP packet received from a server. Eight tests are defined:

This is sample output of from the debug ntp validity command:

You can use the debug ntp packets command in order to see the time that the peer/server gives you in the received packet. The time local machine also tells the time it knows to the peer/server in the transmitted packet.

In this sample output, the time stamps in the received packet from the server and the packet sent to another server are the same, which indicates that the client NTP is in sync.

This is an example of output when the clocks are not in sync. Notice the time difference between the xmit packet and the rcv packet. The peer dispersion can be at the max value of 16000, and the reach for the peer can show 0.

debug ntp sync and debug ntp events

The debug ntp sync command produces one-line outputs that show whether the clock has synced or the sync has changed. The command is generally enabled with debug ntp events.

The debug ntp events command shows any NTP events that occur, which helps you determine if a change in the NTP triggered an issue such as clocks that go out of sync. (In other words, if your happily synced clocks suddenly go crazy, you know to look for a change or trigger!)

This is an example of both debugs. Initially, the client clocks were synced. The debug ntp events command shows that an NTP peer stratum change occurred, and the clocks then went out of sync.

NTP Clock-period Manually Set

The Cisco.com website warns that:

"The ntp clock-period command is automatically generated to reflect the correction factor that constantly changes when the copy running-configuration startup-configuration command is entered to save the configuration to NVRAM. Do not attempt to manually use the ntp clock-period command. Ensure that you remove this command line when you copy configuration files to other devices."

The clock-period value is dependent on the hardware, so it differs for every device.

The ntp clock-period command automatically appears in the configuration when you enable NTP. The command is used in order to adjust the software clock. The 'adjustment value' compensates for the 4 msec tick interval, so that, with the minor adjustment, you have 1 second at the end of the interval.

If the device has calculated that its system clock loses time (perhaps there needs to be a frequency compensation from the base level of the router), it automatically adds this value to the system clock in order to maintain its synchronicity.

Note: This command must not be changed by the user.

The default NTP clock-period for a router is 17179869 and is essentially used in order to start the NTP process.

The conversion formula is 17179869 * 2^(-32) = 0.00399999995715916156768798828125, or approximately 4 milliseconds.

For example, the system clock for the Cisco 2611 routers (one of the Cisco 2600 Series Routers) was found to be slightly out-of-sync and could be resynchronized with this command:

This equals 17208078 * 2^(-32) = 0.0040065678767859935760498046875, or a little over 4 milliseconds.

Cisco recommends that you let the router run for a week or so in normal network conditions and then use the wr mem command in order to save the value. This gives you an accurate figure for next reboot and allows NTP to synchronize more quickly.

Use the no ntp clock-period command when you save the configuration for use on another device because this command drops the clock-period back to the default of that particular device. You can recalcuate the true value (but can reduce the accuracy of the system clock during that recalculation time period).

Remember that this value is hardware dependent, so if you copy a configuration and use it on different devices, you can cause problems. Cisco plans to replace NTP version 3 with version 4 in order to resolve this issue.

If you are not aware of these issues, you can decide to manually tinker with this value. In order to migrate from one device to another, you can decide to copy the old configuration and paste it on the new device. Unfortunately, because the ntp clock-period command appears in the running-config and startup-config, NTP clock-period is pasted on the new device. When this happens, NTP on the new client always goes out of sync with the server with a high peer dispersion value.

Instead, clear the NTP clock-period with the no ntp clock-period command, then save the configuration. The router eventually calculates a clock-period appropriate for itself.

The ntp clock-period command is no longer available in Cisco IOS software Version 15.0 or later; the parser now rejects the command with the error:

You are not allowed to configure the clock-period manually, and the clock-period is not allowed in the running-config. Since the parser rejects the command if it was in the start-up config (in earlier Cisco IOS versions such as 12.4), the parser rejects the command when it copies the start-up config to the running-config on boot-up.

The new, replacement command is ntp clear drift.

Related Information

  • Support Forum Thread: NTP clock-period not configured
  • Network Time Protocol: Best Practices White Paper
  • Troubleshoot Network Time Protocol (NTP)
  • Cisco Technical Support & Downloads

Revision History

TAC Authored

Contributed by Cisco Engineers

  • Krishna Nagavolu Cisco Software Engineering Technical Leader

Was this Document Helpful?

Feedback

Contact Cisco

login required

  • (Requires a Cisco Service Contract )

ntp round trip delay

IMAGES

  1. NTP round-trip delay

    ntp round trip delay

  2. Round trip delay via public Internet between NIST in Boulder, Colorado

    ntp round trip delay

  3. RTD 定义: 双程延迟时间

    ntp round trip delay

  4. Computing round-trip delay (RTD) from RTCP.

    ntp round trip delay

  5. Round-trip time for HTTP and CoAP using NTP server

    ntp round trip delay

  6. NTP round trip time, Chicago -Japan (NICT)

    ntp round trip delay

VIDEO

  1. Urgent Update: Delay in Social Security COLA

  2. overlap neck new trick/اوور لیپ گلہ بنانے کا نیا انداز/lace lganay ka latest trika

  3. It Takes Two Part 2

  4. trip cikampek gagal 336 brangkat als trip surabaya bruntung karna masuklojet

  5. 【KYOTO】Must-Check Japanese exotic Restaurant

  6. Songs to get you in a good mood