skip to content

A cluster's NTP servers must cross a leap second; how does inserting the second differ from smearing it, and why must clients never mix the two?

level: seniorimportance: should knowfreq 22%

answer

  1. a 61-second minute versus a slow drift
  2. two bits in every NTP header
  3. hours of a small frequency offset
  4. RFC 8633 on mixed sources

basics

~20 s

Inserting adds a 61st second to the month's final minute, announced by NTP's leap indicator. Smearing runs servers slightly slow for hours, so no second repeats. Mixed sources disagree by up to a second, which RFC 8633 forbids.

solid answer

~50 s

A **leap second** keeps UTC within 0.9 s of Earth-rotation time. NTPv4 announces one with the 2-bit **leap indicator**: 1 means the last minute of the day has 61 seconds, 2 that it has 59, and RFC 5905 applies it only at the end of a month. Some systems mishandle a 61-second minute, so some operators **smear** instead: servers stretch the extra second over a window of hours, which RFC 8633 says has run from two to twenty-four hours, so clients follow slightly slow time and nothing repeats, at the cost of being up to a second off UTC. RFC 8633 says clients of smearing servers MUST NOT apply leap seconds, a client MUST NOT mix smeared and unsmeared servers, and public servers MUST NOT smear, because they would disagree with UTC and nothing in NTPv4 lets a client detect smearing.

go deeper

for a junior

Recall what a leap second is, that NTP carries a leap indicator in every packet, and that smearing spreads the second out instead of inserting it.

for a middle

Explain the four leap indicator values, when a leap second is applied, and how a smear turns one second into a small frequency offset over hours.

for a senior

Plan a leap-second event for a fleet: one consistent policy, no mixed sources, no smearing on public servers, and monitoring for clients that disagree.

for a principal

Weigh UTC traceability against application robustness, and decide whether an organisation's time service should smear at all given audit and regulatory obligations.

## What a leap second is UTC is an atomic timescale, while UT1 follows the Earth's rotation, which slowly varies. To keep the two within **0.9 s** of each other, a **leap second** is occasionally inserted, or in principle deleted, at the end of a month; the IERS announces each one in advance. RFC 8633 notes that every leap second since the practice began in 1972 has been positive. In UTC notation the inserted second is written 23:59:60. ## How NTPv4 announces and applies one Every NTPv4 header (RFC 5905) carries a 2-bit **leap indicator (LI)**: | LI | Meaning | |---|---| | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronised) | RFC 5905 describes the warning as applying to the last minute of the current month. RFC 8633, the NTP Best Current Practice, adds operational rules: - Because some older clients applied a pending leap at the end of the current day, servers are RECOMMENDED to wait until the **last day of the month** before announcing it. - Clients should therefore not poll less often than once every **24 hours**, or they can miss the announcement. - A server without an automated leap source can load a published leap-second list. At the moment itself a system clock either repeats a second or holds still for one; either way, some applications and some operating systems have had problems with a 61-second minute. ## Leap smearing **Smearing** avoids the 61-second minute. Instead of inserting a second, the server adjusts its time in small increments across a **smear interval** around the event. RFC 8633 reports intervals from two to twenty-four hours used successfully. During the window clients may be off UTC by as much as a full second, depending on the implementation, but they agree with each other. The arithmetic: absorbing one second over a 24-hour linear smear means running slow by 1 / 86,400, about **11.6 ppm**; over two hours it is 1 / 7,200, about **139 ppm**. A short smear is a large frequency excursion that clients must be willing to follow. ## Why mixing breaks clients RFC 8633 records what happened around the June 2015 leap second: some operators smeared, others did not, and many clients with four sources found two giving consistent UTC and two giving consistent smeared time. Source selection, the step that decides which servers to trust, finds no majority it can believe when two cliques disagree by up to a second. The client may refuse to synchronise, or follow the wrong group. So RFC 8633 sets hard rules: 1. Clients of smearing servers MUST NOT apply standard leap-second handling, must never have a leap-second file loaded, and smearing servers must never announce a pending leap to them. 2. Individual clients MUST NOT be configured with a mixture of smeared and non-smeared servers; all of a client's servers must share the same smear configuration. 3. Leap smearing MUST NOT be used for public-facing NTP servers, because they would disagree with non-smearing servers and with UTC, and there is no standardised way in NTPv4 for a client to detect it. 4. Operators with legal or other strong requirements for UTC traceability SHOULD NOT smear. ## Choosing | | Insert | Smear | |---|---|---| | Time during the event | exact UTC, with a 61-second minute | up to about a second off UTC | | Applications see | a repeated or held second | slightly slow time, no repeats | | Traceable to UTC | yes | not during the window | | Where it belongs | anywhere, including public servers | one controlled environment only | | Client configuration | apply the leap indicator | never apply leap seconds | ## What NTPv5 changes The NTPv5 Internet-Draft, draft-ietf-ntp-ntpv5-09, still a draft and not an RFC, adds a **Timescale** field whose values are UTC, TAI, UT1 and leap-smeared UTC (3). A server answering in the smeared timescale sends a leap indicator of 0, and the client is not expected to handle leap seconds. That makes smearing visible on the wire, which NTPv4 cannot do. ## Common mistakes - Smearing public servers because it seems kinder to clients. - Believing an NTPv4 client can tell from a packet that a server smears. - Expecting a mix of smeared and unsmeared sources to average out. - Reading LI 3 as an announcement rather than unsynchronised.

  • When is smearing the right choice for an operator?
    Inside one controlled environment whose applications mishandle a 61-second minute, with every server and client configured identically and no client applying leap seconds. RFC 8633 says operators with legal or strong UTC-traceability requirements SHOULD NOT smear, and public-facing servers MUST NOT.
  • Why does RFC 8633 recommend that NTP servers announce a leap second only on the last day of the month?
    Some older clients applied a pending leap at the end of the current day rather than the month. Announcing only on the last day makes both readings coincide. Clients then must poll at least once every 24 hours, or they may miss the announcement.
  • How does the NTPv5 draft change leap-smearing?
    draft-ietf-ntp-ntpv5-09 adds a Timescale field whose values include leap-smeared UTC, so a client can see that a server smears; such a server sends a leap indicator of 0. It remains an Internet-Draft, so NTPv4 deployments still cannot rely on it.

saying these in an interview costs you the question

  • Leap smearing is fine on public NTP servers because it avoids 23:59:60
  • An NTPv4 client can detect a smearing server from its packets
  • Mixing smeared and unsmeared servers averages out to the right time
  • A leap indicator of 3 announces that a leap second will be inserted
  • Leap seconds are applied at the end of whichever day the server announces them