Computer NetworksNTP

Network Time Protocol (NTP)

LevelIntermediate

Duration60 mins

TopicNTP

3 / 5

Stratum Levels

Quantifying Distance from Truth

In the NTP hierarchy, stratum is a deceptively simple concept with profound implications. At first glance, it appears to be just a number from 0 to 16 indicating how 'far' a server is from the authoritative time source. But beneath this simplicity lies a sophisticated system for expressing trust, managing failures, and preventing synchronization loops.

Understanding stratum deeply is essential for anyone designing, configuring, or troubleshooting NTP deployments. A misconfigured stratum can cause time loops, synchronization failures, or subtle accuracy degradation that may not manifest until critical systems fail.

What You Will Learn

By the end of this page, you will understand the precise definition and semantics of each stratum level, how stratum values are calculated, propagated, and used in server selection, the special cases (stratum 0, stratum 16, orphan mode), common stratum-related misconfigurations, and how to verify and interpret stratum information from NTP tools.

Formal Definition of Stratum

Stratum is an 8-bit unsigned integer field in the NTP packet that indicates the hierarchical distance of a time server from the reference clock. It represents the number of NTP hops from the ultimate time source.

Complete Stratum Value Reference
Stratum	Name	Meaning	Source Type
0	Unspecified / Invalid	Reference clock itself (not an NTP server); kiss-of-death in some contexts	Hardware time source
1	Primary Reference	Server directly connected to stratum 0 reference clock	GPS, atomic, radio clock
2	Secondary Reference	Server synchronized to stratum 1 server(s)	NTP from stratum 1
3	Tertiary Reference	Server synchronized to stratum 2 server(s)	NTP from stratum 2
4-14	Lower Reference	Each level adds one hop from reference	NTP from level above
15	Maximum Valid	Last usable stratum; avoid in practice	NTP from stratum 14
16	Unsynchronized	Server is not synchronized to any valid source	No source / local clock only

The stratum calculation rule is simple:

My Stratum = Upstream Peer's Stratum + 1

If a server synchronizes to a stratum 2 peer, it becomes stratum 3. If it synchronizes to multiple peers at different strata, it uses the stratum of the selected system peer (the one actually used for clock discipline) plus one.

Stratum boundaries:

Minimum (excluding reference clocks): 1
Maximum useful: 15 (avoid in practice; most deployments stay at 4 or below)
Invalid/unsynchronized: 16

Why 16 = unsynchronized:

Stratum 16 is used to indicate that a server cannot provide valid time. This happens when:

The server has just started and hasn't synchronized yet
All configured sources are unreachable
All sources have been rejected as falsetickers
The administrator has explicitly set the server to unsynchronized

Stratum 0 Is Special

You will never see stratum 0 in an NTP packet's stratum field during normal operation. Stratum 0 is reserved for reference clocks (hardware), which don't communicate via NTP. In certain error conditions (kiss-of-death packets), stratum 0 indicates a special response. If you see stratum 0 from a supposed NTP server, something is wrong.

Stratum Levels in Detail

Let's examine each stratum level's characteristics, typical accuracy, and common deployment scenarios.

stratum_levels_detail.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
Stratum Level Characteristics
══════════════════════════════════════════════════════════════════════════
 
STRATUM 0: REFERENCE CLOCKS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: The hardware time source itself—not an NTP server
Examples:   GPS satellite system (atomic clocks in orbit)
            Cesium beam frequency standard
            Hydrogen maser
            WWVB radio transmitter
 
Accuracy:   GPS: ~10-40 ns (satellites)
            Cesium: <1 ns (primary standard)
            Rubidium: ~100 ns (secondary standard)
 
Note: Stratum 0 devices don't speak NTP. They provide time through:
      - Pulse Per Second (PPS) signals
      - Serial data (NMEA, proprietary formats)
      - IRIG time codes
      - Direct hardware interfaces
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 1: PRIMARY SERVERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Servers with direct hardware connection to stratum 0
Examples:   NIST time servers (connected to cesium fountains)
            Observatory NTP servers (GPS-synchronized)
            Major ISP stratum 1 servers
 
Accuracy:   Typically <10 μs from UTC
            Best cases: <1 μs with PPS and careful configuration
 
Typical Count: ~500-1,000 public stratum 1 servers worldwide
 
Reference ID: Four-character ASCII string identifying source:
              GPS   - GPS receiver
              ATOM  - Atomic clock
              PPS   - Pulse Per Second source
              CHU   - CHU radio station (Canada)
              WWVB  - WWVB radio station (USA)
              DCF   - DCF77 radio station (Germany)
              MSF   - MSF radio station (UK)
 
Considerations:
- Expensive to operate (reference clock cost, maintenance)
- High responsibility (many downstream systems depend on you)
- Should never be pointed at by typical clients directly
- Usually operated by national labs, major ISPs, cloud providers
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 2: SECONDARY SERVERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Servers synchronized via NTP to stratum 1 servers
Examples:   pool.ntp.org members
            ISP customer-facing NTP servers
            Cloud provider time services
            Large enterprise internal servers
 
Accuracy:   Typically <100 μs from UTC on well-connected networks
            Can achieve <10 μs on LANs with good stratum 1 sources
 
Typical Count: ~10,000-50,000 public stratum 2 servers
 
Reference ID: IP address of the stratum 1 system peer (IPv4)
              First 4 bytes of MD5 hash for IPv6
 
Considerations:
- Primary target for most client configurations
- Should sync to multiple (3-4) stratum 1 sources
- May peer with other stratum 2 servers for redundancy
- pool.ntp.org primarily consists of stratum 2 servers
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 3: TERTIARY SERVERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Servers synchronized via NTP to stratum 2 servers
Examples:   Corporate data center NTP servers
            University department servers
            Regional/branch office servers
            Home router NTP servers
 
Accuracy:   Typically <1 ms from UTC
            Can be better on low-latency networks
 
Common Use: Internal enterprise time distribution
            Where direct stratum 2 access is impractical
            Reducing load on public NTP infrastructure
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 4-15: LOWER STRATA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Practical Range: Most deployments should stay at stratum 4 or below
 
Stratum 4:  End-user devices (desktops, laptops, servers)
            Typical for clients syncing to stratum 3 servers
            Accuracy: typically <10 ms
 
Stratum 5+: Generally indicates suboptimal configuration
            May occur in deep networks with many hops
            Each stratum adds potential error and delay
 
Stratum 15: Maximum valid stratum—avoid reaching this
            Indicates very deep hierarchy or misconfiguration
            Some implementations warn or refuse to use stratum 15
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 16: UNSYNCHRONIZED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Server is not synchronized to any valid time source
Causes:     - Just started, initial sync pending
            - All configured sources unreachable
            - All sources rejected as falsetickers
            - Manual configuration (local clock only)
            - ntp.conf misconfiguration
 
Behavior:   Clients SHOULD NOT sync to stratum 16 servers
            Server will not respond to client queries (typically)
            Used to indicate "I don't have valid time"
 
Monitoring: Stratum 16 should trigger alerts in monitoring systems
            Indicates a time synchronization failure

Stratum in Practice

In well-designed deployments, you should rarely see stratum above 4. If you're seeing stratum 6, 7, or higher, examine your NTP architecture—you may have unnecessary intermediate servers or a misconfiguration creating a deeper-than-needed hierarchy.

Reference ID: Identifying the Source

The Reference ID is a 32-bit field in the NTP packet that identifies the time source. Its interpretation depends on the stratum level of the server.

Reference ID encoding by stratum:

Reference ID Interpretation by Stratum
Stratum	Reference ID Meaning	Example
0 (KoD)	Kiss-of-death code	'RATE' (rate limit exceeded)
1	Four-character ASCII source ID	'GPS', 'PPS', 'ATOM'
2-15 (IPv4)	IPv4 address of system peer	192.0.2.1 → 0xC0000201
2-15 (IPv6)	First 4 bytes of MD5(IPv6)	Hash of peer address
16	Undefined / not meaningful	May be zero or previous value

Common stratum 1 reference identifiers:

reference_identifiers.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
Stratum 1 Reference Identifiers
══════════════════════════════════════════════════════════════════════════
 
GPS-BASED SOURCES
  GPS   - Global Positioning System
  PPS   - Pulse Per Second (generic, often from GPS)
  GPSD  - GPS Daemon (gpsd)
  
ATOMIC/LABORATORY SOURCES  
  ATOM  - Atomic clock (cesium, rubidium, hydrogen)
  CESM  - Cesium beam frequency standard
  RBDM  - Rubidium frequency standard
  PTB   - Physikalisch-Technische Bundesanstalt (Germany)
  NIST  - National Institute of Standards and Technology (USA)
  USNO  - United States Naval Observatory
  
RADIO TIME SOURCES
  WWVB  - NIST radio station, Colorado (60 kHz)
  WWVH  - NIST radio station, Hawaii
  CHU   - National Research Council, Canada
  DCF   - DCF77, Germany (77.5 kHz)
  MSF   - National Physical Laboratory, UK (60 kHz)
  JJY   - Japanese radio station (40/60 kHz)
  LORC  - LORAN-C (now largely discontinued)
  
NETWORK/PROTOCOL SOURCES
  PTP   - Precision Time Protocol (IEEE 1588)
  NTS   - Network Time Security
  
CELLULAR/SATELLITE
  CDMA  - CDMA cellular timing
  GAL   - Galileo (European GNSS)
  GLO   - GLONASS (Russian GNSS)
  BDS   - BeiDou (Chinese GNSS)
 
══════════════════════════════════════════════════════════════════════════
 
LOOP DETECTION USING REFERENCE ID
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
For stratum 2+, the Reference ID contains the IP address (or hash) of
the system peer. This enables loop detection:
 
Example of a loop:
  
  Server A (192.168.1.1) ──────► syncs to ──────► Server B (192.168.1.2)
       ▲                                             │
       │                                             │
       └─────────────────────────────────────────────┘
                   syncs to (LOOP!)
 
Detection: Server A sees Server B's Reference ID = 192.168.1.1 (A's IP)
           This indicates B is syncing to A → Loop detected!
           Server A rejects B as a potential source.
 
The ntpd/chrony implementations check:
  IF peer.reference_id == my_ip_address THEN
      reject_as_loop()
  ENDIF

Reading Reference IDs in Practice

When troubleshooting, the reference ID tells you exactly where time is coming from. On a stratum 1 server, you'll see codes like 'GPS' or 'PPS'. On stratum 2+, you'll see an IP address. If you see 'LOCL' or 'LOCAL', the server is using its local clock only—a warning sign unless intentional.

Stratum Dynamics: Changes and Transitions

Stratum is not static—it changes as network conditions evolve, sources become available or unavailable, and the selection algorithm chooses different system peers. Understanding these dynamics is crucial for anticipating and debugging NTP behavior.

When stratum changes:

Stratum Increase Scenarios

•Primary source becomes unreachable — If your stratum 2 source goes offline and you fall back to a stratum 3 source, you become stratum 4
•Network partition — If connectivity to low-stratum servers is lost, the server may sync to a higher-stratum backup
•Source selection change — If the algorithm selects a different system peer with a higher stratum, your stratum increases accordingly
•All sources fail — If no valid sources remain, stratum increases to 16 (unsynchronized)
•Orphan mode activation — When using the local directive and external sources fail, the server uses its local clock at the configured stratum

Stratum Decrease Scenarios

•Better source becomes available — If a stratum 1 source comes online and is selected, you become stratum 2
•Network recovery — Connectivity to low-stratum servers restored
•Initial synchronization — After startup, stratum decreases from 16 as synchronization completes
•Direct reference clock — If you connect your own GPS/atomic clock, you become stratum 1

stratum_transition_example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Stratum Transition Timeline Example
══════════════════════════════════════════════════════════════════════════
 
Scenario: Enterprise NTP server with multiple upstream sources
 
Time     Event                                    Server Stratum
─────────────────────────────────────────────────────────────────────────
00:00    Server starts (ntpd/chronyd)              16 (unsync)
00:01    Initial NTP exchange with sources          [calculating]
00:02    Synchronized to stratum 2 pool server     3
         └─ Reference: pool0.ntp.org (stratum 2)
         
08:30    pool0.ntp.org becomes unreachable         [selecting...]
08:31    Selects backup stratum 3 source           4
         └─ Reference: internal-ntp.corp.com (stratum 3)
         
08:45    pool0.ntp.org returns                     3
         └─ Selection returns to stratum 2 source
         
15:00    Network maintenance: all external down    [selecting...]
15:01    No valid sources, orphan mode activates   10  ← local clock
         └─ Reference: LOCAL (local clock at stratum 10)
         └─ NOTE: Still serving time, but lower quality
         
15:30    External connectivity restored            [selecting...]
15:32    Synchronized to stratum 2 source again    3
         └─ Reference: pool1.ntp.org (stratum 2)
 
══════════════════════════════════════════════════════════════════════════
 
Stratum Timeline Visualization:
 
Stratum │
   16   │ ●                                              Initial startup
   15   │
   14   │
   ...  │
   10   │                                  ●──────●       Orphan mode
    9   │
    ...
    4   │              ●─────────●                        Backup source
    3   │   ●──────────●         ●─────────●     ●─────►  Normal operation
    2   │
    1   │
        └───┬───────────┬─────────┬─────────┬─────┬────► Time
         00:02       08:31     08:45     15:01   15:32

Stratum Instability

Frequent stratum changes ('stratum flapping') can indicate network instability, misconfigured sources, or marginal source quality. If you observe stratum changing frequently, investigate the root cause—it often indicates a problem that could lead to time errors.

Orphan Mode and Local Clock

A critical question arises: What happens when a server loses contact with all external time sources? Should it stop serving time entirely, or should it continue using its local clock—potentially drifting but at least providing some time reference?

NTP addresses this with orphan mode (or the 'local' clock driver), which allows a server to fall back to its own clock when external sources are unavailable.

orphan_mode_configuration.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
Orphan Mode Configuration
══════════════════════════════════════════════════════════════════════════
 
CHRONY CONFIGURATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# /etc/chrony/chrony.conf
 
# Normal external sources
server time.google.com iburst
pool pool.ntp.org iburst maxsources 4
 
# Local clock fallback - only activate if external sources fail
# Stratum 10 tells clients "this is low quality time"
local stratum 10 orphan
 
# 'orphan' keyword means:
#   - Only use local clock if NO other source is available
#   - Without 'orphan': would immediately use local clock
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
NTPD CONFIGURATION (LEGACY)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# /etc/ntp.conf
 
# Normal sources
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
 
# Local clock at stratum 10 - use when external sources unavailable
server 127.127.1.0         # Local clock driver
fudge 127.127.1.0 stratum 10
 
# The 'tos orphan' command enables orphan mode
tos orphan 7    # Orphan stratum (typically set to avoid conflicts)
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
ORPHAN MODE BEHAVIOR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Normal operation:
  External sources available → Server uses them → Stratum = source + 1
  
Orphan mode triggered:
  All external sources FAIL → Server uses local clock → Stratum = 10
  
                    ┌────────────────────────────────────┐
                    │         EXTERNAL SOURCES          │
                    │       (stratum 1, 2, etc.)        │
                    │                                    │
                    │    ┌────┐  ┌────┐  ┌────┐         │
                    │    │fail│  │fail│  │fail│         │
                    │    └──┬─┘  └──┬─┘  └──┬─┘         │
                    └───────┼──────┼──────┼────────────┘
                            │      │      │
                            ▼      ▼      ▼
                         ALL SOURCES UNREACHABLE
                                   │
                                   ▼
                    ┌─────────────────────────────────┐
                    │         ORPHAN MODE              │
                    │                                  │
                    │  Server uses local clock         │
                    │  Stratum = configured (e.g., 10) │
                    │  Reference ID = "LOCL"           │
                    │                                  │
                    │  Still serves time to clients    │
                    │  Clients see high stratum        │
                    │  Time may drift without external │
                    └─────────────────────────────────┘
 
CHOOSING ORPHAN STRATUM
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Stratum 10 is a common choice because:
- High enough that clients prefer any real external source
- Low enough that clients will still sync (vs stratum 16)
- Provides clear signal that this is fallback time
 
If you have multiple internal servers with orphan mode:
- They should all use the same orphan stratum
- NTP's selection algorithm will break ties
- Consider which server has the best local clock

Orphan Mode Advantages

•Maintains time service during outages
•Clients continue functioning
•High stratum signals lower quality
•Automatic recovery when sources return
•Better than complete time failure

Orphan Mode Risks

•Time may drift significantly
•Clients may trust inaccurate time
•Extended outages compound drift
•May mask configuration problems
•Can cause issues when sources return

Monitoring Orphan Mode

Your monitoring system should alert when servers enter orphan mode. An extended period in orphan mode indicates a serious infrastructure problem—either your external sources are down or your network connectivity is broken. Use stratum monitoring (alert on stratum ≥ 10) to catch these situations early.

Kiss-of-Death (KoD) Packets

NTP uses stratum 0 in a special context: Kiss-of-Death (KoD) packets. These are response packets from a server that indicate the client should stop or change its behavior. The reference ID field contains a four-character ASCII code indicating the reason.

KoD packets have:

Stratum = 0
Leap Indicator = 3 (clock not synchronized)
Reference ID = four-character 'kiss code'

Kiss-of-Death (KoD) Codes
Code	Meaning	Client Action
RATE	Rate limit exceeded	Reduce polling frequency; wait before retrying
DENY	Access denied	Stop querying this server (blocked)
RSTR	Access restricted	Stop querying this server (filtered)
RMOT	Alteration of association	Remove this server from configuration
STEP	Step time change required	Make a step adjustment, then retry
NKEY	No key found	Authentication key not found
AUTH	Authentication failed	Check authentication configuration
INIT	Server initializing	Wait for server to synchronize
MCST	Multicast server	Client should switch to multicast mode
BCST	Broadcast server	Client should switch to broadcast mode

Handling RATE KoD:

The RATE kiss code is the most common and indicates you're polling the server too frequently. When a client receives a RATE KoD, it should:

Back off from this server for a period (typically 2x the previous poll interval)
Increase the poll interval for future queries
Never query below the server's minimum allowed rate

This is particularly important for pool.ntp.org, where aggressive clients can be banned. The NTP pool project monitors abusive clients and may stop responding to persistent offenders.

kod_example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
KoD Packet Example (RATE limit exceeded)
══════════════════════════════════════════════════════════════════════════
 
NTP Response Packet:
  Leap Indicator:      3 (clock not synchronized)
  Version:             4
  Mode:                4 (server)
  Stratum:             0   ← STRATUM 0 = Kiss-of-Death
  Poll:                4   (16 seconds)
  Precision:           0
  Root Delay:          0
  Root Dispersion:     0
  Reference ID:        0x52415445 = "RATE"  ← You're polling too fast!
  Reference Timestamp: 0
  Origin Timestamp:    [client's transmit timestamp echoed]
  Receive Timestamp:   0
  Transmit Timestamp:  0
 
Client Response:
  1. Log the KoD event
  2. Back off from this server for exponential backoff period
  3. Increase minimum poll interval for this server
  4. Try alternative servers in the meantime
 
Sample log entry:
  chronyd[1234]: Source 192.0.2.1 replied with KoD RATE and unreachable
 
════════════════════════════════════════════════════════════════════════

Respecting KoD Packets

Ignoring KoD packets is antisocial behavior. Servers that send RATE KoD are protecting themselves from overload. Clients that ignore these signals and continue aggressive polling may find themselves permanently blocked—not just by that server, but potentially by entire NTP pools that share abuse information.

Practical Stratum Investigation

Understanding stratum is not just theoretical—you'll need to query, interpret, and troubleshoot stratum values in real systems. Here are the tools and techniques for practical stratum investigation.

stratum_investigation_commands.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
Stratum Investigation Commands
══════════════════════════════════════════════════════════════════════════
 
CHRONY (modern Linux systems)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Show all sources with stratum
$ chronyc sources -v
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.google.com              1   6   377    23   +234us[+567us] +/-   15ms
^+ ntp.ubuntu.com               2   6   377    24   -456us[-789us] +/-   22ms
^- 45.33.84.208                 3   6   377    25   +1.2ms[ +1.5ms] +/-   45ms
 
# Legend:
#   ^*  = Current sync source (system peer)
#   ^+  = Acceptable, could be used
#   ^-  = Outlier, currently rejected
#   ^?  = Unreachable
#   ^x  = Designated as falseticker
 
# Show detailed tracking info (includes our stratum)
$ chronyc tracking
Reference ID    : D8EF2308 (time.google.com)
Stratum         : 2     ← OUR STRATUM (source stratum + 1)
Ref time (UTC)  : Fri Jan 17 06:30:00 2026
System time     : 0.000000234 seconds fast of NTP time
Last offset     : +0.000000234 seconds
RMS offset      : 0.000000456 seconds
Frequency       : 12.345 ppm slow
Root delay      : 0.015234567 seconds
Root dispersion : 0.000234567 seconds
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
NTPQ (traditional ntpd systems)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Show peers with stratum (st column)
$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*time.google.com .GOOG.           1 u   23   64  377   15.234    0.567   0.123
+ntp.ubuntu.com  17.253.34.253    2 u   24   64  377   22.456   -0.789   0.234
-45.33.84.208    108.61.56.35     3 u   25   64  377   45.678    1.234   0.567
 
# Legend: st = stratum
#   * = system peer (clock source)
#   + = candidate
#   - = outlier
#   x = designated falseticker
 
# Check our own stratum
$ ntpq -c "rv 0 stratum"
stratum=2
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
QUERY A REMOTE SERVER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Query a remote NTP server directly
$ ntpdate -q time.google.com
server 216.239.35.8, stratum 1, offset -0.000234, delay 0.01534
 
# Or using sntp
$ sntp time.google.com
2026-01-17 06:30:00.123456 (+0.000234) +/- 0.015000 time.google.com 216.239.35.8
 
# Detailed query with ntpq
$ ntpq -c "rv 0" time.google.com  # Requires ntpq access enabled on server
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
WINDOWS SYSTEMS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Query W32Time status
> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Reference ID: 0xC0A80101 (source IP: 192.168.1.1)
Last Successful Sync Time: 1/17/2026 6:30:00 AM
 
# Query specific source
> w32tm /query /source
time.google.com
 
# Monitor configuration
> w32tm /query /configuration

Stratum Monitoring Best Practice

Set up monitoring that alerts on: (1) Stratum increase (e.g., your server was stratum 3, now stratum 5); (2) Stratum reaching 10+ (orphan mode); (3) Stratum reaching 16 (completely unsynchronized). These early warnings help you fix time problems before they cascade into application failures.

Summary: Stratum Levels

Stratum is a deceptively simple concept that underpins NTP's hierarchical trust model. Let's consolidate the key insights:

Key Takeaways

•Stratum indicates hierarchical distance — Each hop from the reference clock adds 1 to the stratum; servers always report source stratum + 1.
•Valid strata range from 1 to 15 — Stratum 0 is reserved for reference clocks and KoD packets; stratum 16 indicates unsynchronized.
•Reference ID identifies the source — For stratum 1, it's a four-character code like 'GPS'; for stratum 2+, it's the peer's IP address or hash.
•Stratum changes dynamically — As sources come and go, stratum adjusts automatically; monitoring stratum helps detect problems early.
•Orphan mode provides fallback — When external sources fail, a server can use its local clock at a configured high stratum (commonly 10).
•Kiss-of-Death uses stratum 0 — KoD packets signal clients to back off, stop, or change behavior; always respect these signals.
•Use tools to investigate stratum — chronyc, ntpq, and w32tm let you query and monitor stratum in real systems.

What's next:

With a solid understanding of stratum levels, we're now ready to explore how NTP actually synchronizes clocks. The next page examines the clock discipline algorithms—the sophisticated control systems that measure offset, filter noise, and steer the local clock to maintain accuracy over time.

Page Complete

You now have a thorough understanding of NTP stratum levels—their definition, semantics, dynamics, and practical investigation. This knowledge is essential for configuring, monitoring, and troubleshooting NTP in any environment.

3 / 5

Loading learning content...

Computer NetworksNTP

Network Time Protocol (NTP)

LevelIntermediate

Duration60 mins

TopicNTP

3 / 5

Stratum Levels

Quantifying Distance from Truth

What You Will Learn

Formal Definition of Stratum

Complete Stratum Value Reference
Stratum	Name	Meaning	Source Type
0	Unspecified / Invalid	Reference clock itself (not an NTP server); kiss-of-death in some contexts	Hardware time source
1	Primary Reference	Server directly connected to stratum 0 reference clock	GPS, atomic, radio clock
2	Secondary Reference	Server synchronized to stratum 1 server(s)	NTP from stratum 1
3	Tertiary Reference	Server synchronized to stratum 2 server(s)	NTP from stratum 2
4-14	Lower Reference	Each level adds one hop from reference	NTP from level above
15	Maximum Valid	Last usable stratum; avoid in practice	NTP from stratum 14
16	Unsynchronized	Server is not synchronized to any valid source	No source / local clock only

The stratum calculation rule is simple:

My Stratum = Upstream Peer's Stratum + 1

Stratum boundaries:

Minimum (excluding reference clocks): 1
Maximum useful: 15 (avoid in practice; most deployments stay at 4 or below)
Invalid/unsynchronized: 16

Why 16 = unsynchronized:

Stratum 16 is used to indicate that a server cannot provide valid time. This happens when:

The server has just started and hasn't synchronized yet
All configured sources are unreachable
All sources have been rejected as falsetickers
The administrator has explicitly set the server to unsynchronized

Stratum 0 Is Special

Stratum Levels in Detail

Let's examine each stratum level's characteristics, typical accuracy, and common deployment scenarios.

stratum_levels_detail.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
Stratum Level Characteristics
══════════════════════════════════════════════════════════════════════════
 
STRATUM 0: REFERENCE CLOCKS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: The hardware time source itself—not an NTP server
Examples:   GPS satellite system (atomic clocks in orbit)
            Cesium beam frequency standard
            Hydrogen maser
            WWVB radio transmitter
 
Accuracy:   GPS: ~10-40 ns (satellites)
            Cesium: <1 ns (primary standard)
            Rubidium: ~100 ns (secondary standard)
 
Note: Stratum 0 devices don't speak NTP. They provide time through:
      - Pulse Per Second (PPS) signals
      - Serial data (NMEA, proprietary formats)
      - IRIG time codes
      - Direct hardware interfaces
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 1: PRIMARY SERVERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Servers with direct hardware connection to stratum 0
Examples:   NIST time servers (connected to cesium fountains)
            Observatory NTP servers (GPS-synchronized)
            Major ISP stratum 1 servers
 
Accuracy:   Typically <10 μs from UTC
            Best cases: <1 μs with PPS and careful configuration
 
Typical Count: ~500-1,000 public stratum 1 servers worldwide
 
Reference ID: Four-character ASCII string identifying source:
              GPS   - GPS receiver
              ATOM  - Atomic clock
              PPS   - Pulse Per Second source
              CHU   - CHU radio station (Canada)
              WWVB  - WWVB radio station (USA)
              DCF   - DCF77 radio station (Germany)
              MSF   - MSF radio station (UK)
 
Considerations:
- Expensive to operate (reference clock cost, maintenance)
- High responsibility (many downstream systems depend on you)
- Should never be pointed at by typical clients directly
- Usually operated by national labs, major ISPs, cloud providers
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 2: SECONDARY SERVERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Servers synchronized via NTP to stratum 1 servers
Examples:   pool.ntp.org members
            ISP customer-facing NTP servers
            Cloud provider time services
            Large enterprise internal servers
 
Accuracy:   Typically <100 μs from UTC on well-connected networks
            Can achieve <10 μs on LANs with good stratum 1 sources
 
Typical Count: ~10,000-50,000 public stratum 2 servers
 
Reference ID: IP address of the stratum 1 system peer (IPv4)
              First 4 bytes of MD5 hash for IPv6
 
Considerations:
- Primary target for most client configurations
- Should sync to multiple (3-4) stratum 1 sources
- May peer with other stratum 2 servers for redundancy
- pool.ntp.org primarily consists of stratum 2 servers
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 3: TERTIARY SERVERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Servers synchronized via NTP to stratum 2 servers
Examples:   Corporate data center NTP servers
            University department servers
            Regional/branch office servers
            Home router NTP servers
 
Accuracy:   Typically <1 ms from UTC
            Can be better on low-latency networks
 
Common Use: Internal enterprise time distribution
            Where direct stratum 2 access is impractical
            Reducing load on public NTP infrastructure
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 4-15: LOWER STRATA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Practical Range: Most deployments should stay at stratum 4 or below
 
Stratum 4:  End-user devices (desktops, laptops, servers)
            Typical for clients syncing to stratum 3 servers
            Accuracy: typically <10 ms
 
Stratum 5+: Generally indicates suboptimal configuration
            May occur in deep networks with many hops
            Each stratum adds potential error and delay
 
Stratum 15: Maximum valid stratum—avoid reaching this
            Indicates very deep hierarchy or misconfiguration
            Some implementations warn or refuse to use stratum 15
 
══════════════════════════════════════════════════════════════════════════
 
STRATUM 16: UNSYNCHRONIZED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Definition: Server is not synchronized to any valid time source
Causes:     - Just started, initial sync pending
            - All configured sources unreachable
            - All sources rejected as falsetickers
            - Manual configuration (local clock only)
            - ntp.conf misconfiguration
 
Behavior:   Clients SHOULD NOT sync to stratum 16 servers
            Server will not respond to client queries (typically)
            Used to indicate "I don't have valid time"
 
Monitoring: Stratum 16 should trigger alerts in monitoring systems
            Indicates a time synchronization failure

Stratum in Practice

Reference ID: Identifying the Source

The Reference ID is a 32-bit field in the NTP packet that identifies the time source. Its interpretation depends on the stratum level of the server.

Reference ID encoding by stratum:

Reference ID Interpretation by Stratum
Stratum	Reference ID Meaning	Example
0 (KoD)	Kiss-of-death code	'RATE' (rate limit exceeded)
1	Four-character ASCII source ID	'GPS', 'PPS', 'ATOM'
2-15 (IPv4)	IPv4 address of system peer	192.0.2.1 → 0xC0000201
2-15 (IPv6)	First 4 bytes of MD5(IPv6)	Hash of peer address
16	Undefined / not meaningful	May be zero or previous value

Common stratum 1 reference identifiers:

reference_identifiers.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
Stratum 1 Reference Identifiers
══════════════════════════════════════════════════════════════════════════
 
GPS-BASED SOURCES
  GPS   - Global Positioning System
  PPS   - Pulse Per Second (generic, often from GPS)
  GPSD  - GPS Daemon (gpsd)
  
ATOMIC/LABORATORY SOURCES  
  ATOM  - Atomic clock (cesium, rubidium, hydrogen)
  CESM  - Cesium beam frequency standard
  RBDM  - Rubidium frequency standard
  PTB   - Physikalisch-Technische Bundesanstalt (Germany)
  NIST  - National Institute of Standards and Technology (USA)
  USNO  - United States Naval Observatory
  
RADIO TIME SOURCES
  WWVB  - NIST radio station, Colorado (60 kHz)
  WWVH  - NIST radio station, Hawaii
  CHU   - National Research Council, Canada
  DCF   - DCF77, Germany (77.5 kHz)
  MSF   - National Physical Laboratory, UK (60 kHz)
  JJY   - Japanese radio station (40/60 kHz)
  LORC  - LORAN-C (now largely discontinued)
  
NETWORK/PROTOCOL SOURCES
  PTP   - Precision Time Protocol (IEEE 1588)
  NTS   - Network Time Security
  
CELLULAR/SATELLITE
  CDMA  - CDMA cellular timing
  GAL   - Galileo (European GNSS)
  GLO   - GLONASS (Russian GNSS)
  BDS   - BeiDou (Chinese GNSS)
 
══════════════════════════════════════════════════════════════════════════
 
LOOP DETECTION USING REFERENCE ID
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
For stratum 2+, the Reference ID contains the IP address (or hash) of
the system peer. This enables loop detection:
 
Example of a loop:
  
  Server A (192.168.1.1) ──────► syncs to ──────► Server B (192.168.1.2)
       ▲                                             │
       │                                             │
       └─────────────────────────────────────────────┘
                   syncs to (LOOP!)
 
Detection: Server A sees Server B's Reference ID = 192.168.1.1 (A's IP)
           This indicates B is syncing to A → Loop detected!
           Server A rejects B as a potential source.
 
The ntpd/chrony implementations check:
  IF peer.reference_id == my_ip_address THEN
      reject_as_loop()
  ENDIF

Reading Reference IDs in Practice

Stratum Dynamics: Changes and Transitions

When stratum changes:

Stratum Increase Scenarios

•Primary source becomes unreachable — If your stratum 2 source goes offline and you fall back to a stratum 3 source, you become stratum 4
•Network partition — If connectivity to low-stratum servers is lost, the server may sync to a higher-stratum backup
•Source selection change — If the algorithm selects a different system peer with a higher stratum, your stratum increases accordingly
•All sources fail — If no valid sources remain, stratum increases to 16 (unsynchronized)
•Orphan mode activation — When using the local directive and external sources fail, the server uses its local clock at the configured stratum

Stratum Decrease Scenarios

•Better source becomes available — If a stratum 1 source comes online and is selected, you become stratum 2
•Network recovery — Connectivity to low-stratum servers restored
•Initial synchronization — After startup, stratum decreases from 16 as synchronization completes
•Direct reference clock — If you connect your own GPS/atomic clock, you become stratum 1

stratum_transition_example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Stratum Transition Timeline Example
══════════════════════════════════════════════════════════════════════════
 
Scenario: Enterprise NTP server with multiple upstream sources
 
Time     Event                                    Server Stratum
─────────────────────────────────────────────────────────────────────────
00:00    Server starts (ntpd/chronyd)              16 (unsync)
00:01    Initial NTP exchange with sources          [calculating]
00:02    Synchronized to stratum 2 pool server     3
         └─ Reference: pool0.ntp.org (stratum 2)
         
08:30    pool0.ntp.org becomes unreachable         [selecting...]
08:31    Selects backup stratum 3 source           4
         └─ Reference: internal-ntp.corp.com (stratum 3)
         
08:45    pool0.ntp.org returns                     3
         └─ Selection returns to stratum 2 source
         
15:00    Network maintenance: all external down    [selecting...]
15:01    No valid sources, orphan mode activates   10  ← local clock
         └─ Reference: LOCAL (local clock at stratum 10)
         └─ NOTE: Still serving time, but lower quality
         
15:30    External connectivity restored            [selecting...]
15:32    Synchronized to stratum 2 source again    3
         └─ Reference: pool1.ntp.org (stratum 2)
 
══════════════════════════════════════════════════════════════════════════
 
Stratum Timeline Visualization:
 
Stratum │
   16   │ ●                                              Initial startup
   15   │
   14   │
   ...  │
   10   │                                  ●──────●       Orphan mode
    9   │
    ...
    4   │              ●─────────●                        Backup source
    3   │   ●──────────●         ●─────────●     ●─────►  Normal operation
    2   │
    1   │
        └───┬───────────┬─────────┬─────────┬─────┬────► Time
         00:02       08:31     08:45     15:01   15:32

Stratum Instability

Orphan Mode and Local Clock

NTP addresses this with orphan mode (or the 'local' clock driver), which allows a server to fall back to its own clock when external sources are unavailable.

orphan_mode_configuration.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
Orphan Mode Configuration
══════════════════════════════════════════════════════════════════════════
 
CHRONY CONFIGURATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# /etc/chrony/chrony.conf
 
# Normal external sources
server time.google.com iburst
pool pool.ntp.org iburst maxsources 4
 
# Local clock fallback - only activate if external sources fail
# Stratum 10 tells clients "this is low quality time"
local stratum 10 orphan
 
# 'orphan' keyword means:
#   - Only use local clock if NO other source is available
#   - Without 'orphan': would immediately use local clock
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
NTPD CONFIGURATION (LEGACY)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# /etc/ntp.conf
 
# Normal sources
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
 
# Local clock at stratum 10 - use when external sources unavailable
server 127.127.1.0         # Local clock driver
fudge 127.127.1.0 stratum 10
 
# The 'tos orphan' command enables orphan mode
tos orphan 7    # Orphan stratum (typically set to avoid conflicts)
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
ORPHAN MODE BEHAVIOR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Normal operation:
  External sources available → Server uses them → Stratum = source + 1
  
Orphan mode triggered:
  All external sources FAIL → Server uses local clock → Stratum = 10
  
                    ┌────────────────────────────────────┐
                    │         EXTERNAL SOURCES          │
                    │       (stratum 1, 2, etc.)        │
                    │                                    │
                    │    ┌────┐  ┌────┐  ┌────┐         │
                    │    │fail│  │fail│  │fail│         │
                    │    └──┬─┘  └──┬─┘  └──┬─┘         │
                    └───────┼──────┼──────┼────────────┘
                            │      │      │
                            ▼      ▼      ▼
                         ALL SOURCES UNREACHABLE
                                   │
                                   ▼
                    ┌─────────────────────────────────┐
                    │         ORPHAN MODE              │
                    │                                  │
                    │  Server uses local clock         │
                    │  Stratum = configured (e.g., 10) │
                    │  Reference ID = "LOCL"           │
                    │                                  │
                    │  Still serves time to clients    │
                    │  Clients see high stratum        │
                    │  Time may drift without external │
                    └─────────────────────────────────┘
 
CHOOSING ORPHAN STRATUM
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Stratum 10 is a common choice because:
- High enough that clients prefer any real external source
- Low enough that clients will still sync (vs stratum 16)
- Provides clear signal that this is fallback time
 
If you have multiple internal servers with orphan mode:
- They should all use the same orphan stratum
- NTP's selection algorithm will break ties
- Consider which server has the best local clock

Orphan Mode Advantages

•Maintains time service during outages
•Clients continue functioning
•High stratum signals lower quality
•Automatic recovery when sources return
•Better than complete time failure

Orphan Mode Risks

•Time may drift significantly
•Clients may trust inaccurate time
•Extended outages compound drift
•May mask configuration problems
•Can cause issues when sources return

Monitoring Orphan Mode

Kiss-of-Death (KoD) Packets

KoD packets have:

Stratum = 0
Leap Indicator = 3 (clock not synchronized)
Reference ID = four-character 'kiss code'

Kiss-of-Death (KoD) Codes
Code	Meaning	Client Action
RATE	Rate limit exceeded	Reduce polling frequency; wait before retrying
DENY	Access denied	Stop querying this server (blocked)
RSTR	Access restricted	Stop querying this server (filtered)
RMOT	Alteration of association	Remove this server from configuration
STEP	Step time change required	Make a step adjustment, then retry
NKEY	No key found	Authentication key not found
AUTH	Authentication failed	Check authentication configuration
INIT	Server initializing	Wait for server to synchronize
MCST	Multicast server	Client should switch to multicast mode
BCST	Broadcast server	Client should switch to broadcast mode

Handling RATE KoD:

The RATE kiss code is the most common and indicates you're polling the server too frequently. When a client receives a RATE KoD, it should:

Back off from this server for a period (typically 2x the previous poll interval)
Increase the poll interval for future queries
Never query below the server's minimum allowed rate

This is particularly important for pool.ntp.org, where aggressive clients can be banned. The NTP pool project monitors abusive clients and may stop responding to persistent offenders.

kod_example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
KoD Packet Example (RATE limit exceeded)
══════════════════════════════════════════════════════════════════════════
 
NTP Response Packet:
  Leap Indicator:      3 (clock not synchronized)
  Version:             4
  Mode:                4 (server)
  Stratum:             0   ← STRATUM 0 = Kiss-of-Death
  Poll:                4   (16 seconds)
  Precision:           0
  Root Delay:          0
  Root Dispersion:     0
  Reference ID:        0x52415445 = "RATE"  ← You're polling too fast!
  Reference Timestamp: 0
  Origin Timestamp:    [client's transmit timestamp echoed]
  Receive Timestamp:   0
  Transmit Timestamp:  0
 
Client Response:
  1. Log the KoD event
  2. Back off from this server for exponential backoff period
  3. Increase minimum poll interval for this server
  4. Try alternative servers in the meantime
 
Sample log entry:
  chronyd[1234]: Source 192.0.2.1 replied with KoD RATE and unreachable
 
════════════════════════════════════════════════════════════════════════

Respecting KoD Packets

Practical Stratum Investigation

stratum_investigation_commands.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
Stratum Investigation Commands
══════════════════════════════════════════════════════════════════════════
 
CHRONY (modern Linux systems)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Show all sources with stratum
$ chronyc sources -v
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.google.com              1   6   377    23   +234us[+567us] +/-   15ms
^+ ntp.ubuntu.com               2   6   377    24   -456us[-789us] +/-   22ms
^- 45.33.84.208                 3   6   377    25   +1.2ms[ +1.5ms] +/-   45ms
 
# Legend:
#   ^*  = Current sync source (system peer)
#   ^+  = Acceptable, could be used
#   ^-  = Outlier, currently rejected
#   ^?  = Unreachable
#   ^x  = Designated as falseticker
 
# Show detailed tracking info (includes our stratum)
$ chronyc tracking
Reference ID    : D8EF2308 (time.google.com)
Stratum         : 2     ← OUR STRATUM (source stratum + 1)
Ref time (UTC)  : Fri Jan 17 06:30:00 2026
System time     : 0.000000234 seconds fast of NTP time
Last offset     : +0.000000234 seconds
RMS offset      : 0.000000456 seconds
Frequency       : 12.345 ppm slow
Root delay      : 0.015234567 seconds
Root dispersion : 0.000234567 seconds
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
NTPQ (traditional ntpd systems)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Show peers with stratum (st column)
$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*time.google.com .GOOG.           1 u   23   64  377   15.234    0.567   0.123
+ntp.ubuntu.com  17.253.34.253    2 u   24   64  377   22.456   -0.789   0.234
-45.33.84.208    108.61.56.35     3 u   25   64  377   45.678    1.234   0.567
 
# Legend: st = stratum
#   * = system peer (clock source)
#   + = candidate
#   - = outlier
#   x = designated falseticker
 
# Check our own stratum
$ ntpq -c "rv 0 stratum"
stratum=2
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
QUERY A REMOTE SERVER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Query a remote NTP server directly
$ ntpdate -q time.google.com
server 216.239.35.8, stratum 1, offset -0.000234, delay 0.01534
 
# Or using sntp
$ sntp time.google.com
2026-01-17 06:30:00.123456 (+0.000234) +/- 0.015000 time.google.com 216.239.35.8
 
# Detailed query with ntpq
$ ntpq -c "rv 0" time.google.com  # Requires ntpq access enabled on server
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
WINDOWS SYSTEMS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# Query W32Time status
> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Reference ID: 0xC0A80101 (source IP: 192.168.1.1)
Last Successful Sync Time: 1/17/2026 6:30:00 AM
 
# Query specific source
> w32tm /query /source
time.google.com
 
# Monitor configuration
> w32tm /query /configuration

Stratum Monitoring Best Practice

Summary: Stratum Levels

Stratum is a deceptively simple concept that underpins NTP's hierarchical trust model. Let's consolidate the key insights:

Key Takeaways

•Stratum indicates hierarchical distance — Each hop from the reference clock adds 1 to the stratum; servers always report source stratum + 1.
•Valid strata range from 1 to 15 — Stratum 0 is reserved for reference clocks and KoD packets; stratum 16 indicates unsynchronized.
•Reference ID identifies the source — For stratum 1, it's a four-character code like 'GPS'; for stratum 2+, it's the peer's IP address or hash.
•Stratum changes dynamically — As sources come and go, stratum adjusts automatically; monitoring stratum helps detect problems early.
•Orphan mode provides fallback — When external sources fail, a server can use its local clock at a configured high stratum (commonly 10).
•Kiss-of-Death uses stratum 0 — KoD packets signal clients to back off, stop, or change behavior; always respect these signals.
•Use tools to investigate stratum — chronyc, ntpq, and w32tm let you query and monitor stratum in real systems.

What's next:

Page Complete

3 / 5