What does an SNTP client leave out compared with a full NTPv4 implementation, and where in a time hierarchy is SNTP an acceptable choice?
answer
- same packet, less machinery
- one upstream server, no dependants
- what if its only server is wrong
- RFC 5905 section 14 absorbed it
basics
~20 sSNTP sends the same NTPv4 packets on UDP 123 but need not run the mitigation algorithms: clock filter, source selection and the discipline loop. RFC 5905 intends it for leaf clients with one server and no dependants, and for single-reference primary servers.
solid answer
~50 sSNTP is not a separate wire protocol. RFC 5905, which obsoleted the old SNTP document RFC 4330, defines SNTPv4 in its Section 14 as a subset of NTPv4: the same packets in client mode 3 and server mode 4 on UDP port 123, without the mitigation algorithms — the clock filter, source selection and clustering, and the clock discipline loop. An SNTP client trusts one server and typically sets its clock from a single sample; RFC 5905 even allows the simplest client to read only the server's transmit timestamp. That suits the edge of the hierarchy: RFC 5905 intends SNTP for clients with a single upstream server and no dependent clients, and for primary servers with a single reference clock. It is the wrong choice anywhere other hosts take time from you, or where a wrong server has to be outvoted.
go deeper
Recall that SNTP is the same NTP packet on UDP 123 with the algorithms stripped out, meant for leaf clients with one server and nobody depending on them.
Explain what is missing - clock filter, source selection, discipline loop - and what each absence costs: no defence against a wrong server and a clock that free-runs between samples.
Show where you would allow SNTP in an estate, such as battery sensors and single-reference primaries, and where you would forbid it: any host that serves time or must detect a lying source.
Frame it as cost against assurance: SNTP saves power and code across a large fleet, but every such client trusts one server, so the server tier must carry the redundancy and rate limits.
## SNTP is a subset, not a separate protocol The **Simple Network Time Protocol (SNTP)** once had its own document, RFC 4330 (SNTPv4, Informational). **RFC 5905**, the NTPv4 specification, obsoleted RFC 4330 and absorbed SNTP as its Section 14, calling SNTPv4 "a subset of NTPv4". Three consequences follow: - An SNTP client sends the same packet a full client sends — `Mode` 3 (client) to UDP port 123 — and reads a `Mode` 4 (server) reply. - A server cannot tell an SNTP client from a full one, and does not need to: RFC 5905 says NTP and SNTP servers and clients are completely interoperable and can be intermixed in one NTP subnet. - SNTP is a role, not only a client. An **SNTP primary server** with a single reference clock answers requests exactly as an NTP primary server does; RFC 5905 calls the two indistinguishable in principle. ## What an SNTP client leaves out Full NTPv4 is built for a host that listens to several servers and may serve others in turn. Everything RFC 5905 describes from its Section 9 onward — the **mitigation algorithms** — is what an SNTP implementation need not run: | Function | Full NTPv4 client | SNTP client | |---|---|---| | Upstream servers | several associations at once | one server | | Clock filter | keeps recent samples per server and prefers the best | not required | | Source selection and clustering | finds the servers that agree and discards the ones that do not | none: whatever its one server says is the time | | Clock discipline | a feedback loop steering both phase and frequency | not required; how the clock is set is up to the implementation | | Dependent clients | may serve them | none | RFC 5905 goes further: an SNTP client "can operate with any subset of the NTP on-wire protocol", the simplest approach using only the server's **transmit timestamp** and ignoring every other field. Such a client never measures the round trip, so its error includes the whole one-way delay and the time the server spent between stamping and sending — small on a LAN, tens of milliseconds or more over a congested WAN path. RFC 5905 notes the full four-timestamp exchange costs little extra and encourages it; a client that runs it can correct for delay, although it still has no second opinion about the server. ## Where SNTP is the right tool 1. **Leaf devices with loose requirements.** A battery-powered sensor that stamps readings to the nearest second, wakes briefly, asks one local server and sleeps again gains nothing from a continuously running discipline loop, and the loop would cost power and code. 2. **Single-reference primary servers.** A stratum 1 server wired to one reference clock has nothing to choose between, so selection adds nothing. 3. **Small firmware** that cannot carry the full algorithms — provided the device serves time to nobody. ## Where it is the wrong tool - **Anything others synchronise to.** RFC 5905 intends SNTP clients for "a single upstream server and no dependent clients". An SNTP client that re-serves time hands on one unvetted sample, unfiltered. - **Hosts where correctness must be defended.** With one source there is no way to notice that the source is wrong. Full NTP's selection step exists to outvote a wrong server (a falseticker), and it needs several servers to do so. - **Tight requirements.** Without a discipline loop the clock free-runs between samples at whatever rate its oscillator drifts, and unless the implementation adds its own smoothing, each correction lands as a jump. ## What a simple client still owes its server Being simple does not license being rude to the server tier: - **Kiss-o'-death.** A reply with stratum 0 carries a kiss code in its reference ID; RFC 5905 says kiss codes are useful to "either NTPv4 or SNTPv4" clients and that recipients MUST act on `DENY`, `RSTR` and `RATE`. - **Polling restraint.** The obsoleted RFC 4330 set a floor of 15 seconds between requests and asked for exponential backoff. RFC 8633's section on embedded devices asks vendors to choose preconfigured servers carefully and to let the server list be updated, and points to a catalogue of server abuse incidents involving such devices. - **Unsynchronised servers.** A reply whose leap indicator is 3 ("clock unsynchronized") or whose stratum is 16 should not be used to set the clock: the server is saying it has no good time to give. The selection, filtering and discipline algorithms themselves, and how a full client steps or slews, belong to the leaves on source selection and clock discipline; this question is only about what SNTP drops and where that is acceptable.
- Can an NTPv4 server tell that a request came from an SNTP client?No, and it does not need to. The request is an ordinary `Mode` 3 packet to UDP 123, and RFC 5905 says NTP and SNTP servers and clients are completely interoperable. The server answers both the same way; what differs is what the client does with the reply.
- Why is it risky to let an SNTP client serve time to other devices?It has one source and no selection, so a wrong server becomes a wrong clock for every device below it, and with no filtering each jitter spike is passed on. RFC 5905 intends SNTP clients for a single upstream server and no dependent clients; a host that serves time should run full NTPv4 with several sources.
- If an SNTP client reads only the server's transmit timestamp, what error can it not remove?The one-way delay from server to client, plus any gap between the server stamping and sending, because it never measures the round trip and so has nothing to subtract. On a LAN that is small; across a congested WAN it can reach tens of milliseconds. Using all four timestamps removes most of it.
saying these in an interview costs you the question
- SNTP has its own packet format and port, separate from NTP.
- SNTP is client-only; there is no such thing as an SNTP server.
- An SNTP client is fine on a server that hands time to other hosts.
- RFC 4330 is the current SNTP standard.
- A simple SNTP client may ignore kiss-o'-death replies.