SNTP: Simple Network Time Protocol

What is SNTP?

SNTP (Simple Network Time Protocol) is a subset of NTP defined in RFC 4330 and later updated by RFC 5905. It was created to give lightweight devices a practical way to synchronize their clocks without implementing the full NTP algorithm stack. SNTP uses the exact same 48-byte packet format as NTP version 4, communicates over the same UDP port 123, and is fully interoperable with any NTP server. From the server's perspective, an SNTP client looks identical to a regular NTP client.

The key difference between SNTP and NTP is operational, not structural. An SNTP client only talks to a single time server. It does not maintain state across multiple queries, does not implement Marzullo's algorithm for intersecting time intervals from multiple sources, and skips the clock discipline algorithms that NTP uses to gradually slew the system clock. Instead, SNTP simply measures the offset between the local clock and the server's clock, then applies that correction directly. This step adjustment approach is simpler but less smooth than NTP's gradual frequency correction.

In practice, SNTP achieves accuracy within tens of milliseconds on a local network and 100 to 500 milliseconds over the public internet. That is more than sufficient for most applications that just need a reasonably correct wall clock. SNTP is widely deployed in embedded systems, microcontrollers (ESP32, STM32, Arduino with Ethernet), consumer routers, set-top boxes, and IoT sensor nodes. Windows uses w32tm in SNTP mode by default for workgroup-joined machines. If a device does not need sub-millisecond accuracy or the fault tolerance of querying multiple servers, SNTP is the right choice over full NTP.

How SNTP Time Synchronization Works

SNTP uses a single request-response exchange to measure the time difference between client and server. The entire process involves four timestamps, commonly labeled T1 through T4. The client records T1 (the Originate Timestamp) just before sending the request packet. The server records T2 (the Receive Timestamp) when the packet arrives and T3 (the Transmit Timestamp) just before sending the response. Finally, the client records T4 (the Destination Timestamp) when the response arrives back.

From these four timestamps, the client calculates two values. The clock offsettells the client how far its clock is from the server's clock: Offset = ((T2 - T1) + (T3 - T4)) / 2. The round-trip delay measures total network latency: Delay = (T4 - T1) - (T3 - T2). The offset formula works by averaging the forward and return path delays, which cancels out symmetric network latency. If the paths are asymmetric (different latency in each direction), the offset calculation will have some error, but for most networks this is negligible.

Once the offset is calculated, an SNTP client applies it directly to the local clock as a step adjustment. This means the clock jumps forward or backward by the measured offset. Full NTP, by contrast, gradually adjusts the clock frequency (slewing) to avoid sudden jumps that can confuse applications sensitive to time going backward. SNTP clients typically poll the server at a fixed interval, often every 64 to 1024 seconds depending on configuration, and repeat this single-exchange process each time.

SNTP Packet Structure

SNTP uses the same 48-byte packet format as NTP version 4. Every field is identical in layout and meaning, which is why SNTP clients can communicate with any NTP server without special handling. The first 4 bytes contain the control fields, followed by root timing information, and then four 64-bit timestamps.

The first byte is divided into three sub-fields. The Leap Indicator (LI, 2 bits) warns of an impending leap second: 0 means no warning, 1 means the last minute of the day has 61 seconds, 2 means it has 59 seconds, and 3 indicates the clock is unsynchronized. The Version Number (VN, 3 bits) is typically set to 4 for NTP v4. The Mode field (3 bits) indicates the packet type: 3 for client requests, 4 for server responses, and 5 for broadcast.

The Stratumbyte indicates the server's distance from a reference clock. Stratum 1 means the server is directly attached to a reference source like a GPS receiver or atomic clock. Stratum 2 means it synchronizes to a stratum 1 server, and so on up to stratum 15. Stratum 0 is reserved for kiss-of-death (KoD) packets, and stratum 16 means unsynchronized. The Poll Interval and Precision fields are expressed as signed integers representing powers of two in seconds. The Root Delay and Root Dispersion fields are 32-bit fixed-point values measuring the total round-trip delay and maximum clock error relative to the primary reference. The Reference Identifieris a 32-bit field that identifies the particular reference source. For stratum 1 servers, this is a four-character ASCII string like "GPS", "PPS", or "ACTS". For stratum 2 and above, it contains the IPv4 address of the upstream server.

The packet ends with four 64-bit timestamp fields. Each timestamp uses NTP's fixed-point format: 32 bits for whole seconds since January 1, 1900, and 32 bits for the fractional second. This gives a theoretical resolution of about 233 picoseconds. In an SNTP client request, most fields are zeroed except the Transmit Timestamp, which the client fills with its current time (T1). The server copies this into the Originate Timestamp of the response and fills in the Receive and Transmit timestamps.

SNTP Request and Response Examples

Below are hexadecimal breakdowns of a real SNTP exchange captured on a local network. Each packet is exactly 48 bytes. The client sends a request with most fields zeroed, and the server responds with filled timestamps and stratum information.

SNTP Client Request

The client constructs a minimal 48-byte packet with LI=0, VN=4, Mode=3, and its current time in the Transmit Timestamp field. All other fields are set to zero.

SNTP Server Response

The server fills in the stratum, root timing fields, and all four timestamps. The Originate Timestamp is copied from the client's Transmit Timestamp. The server adds its Receive (T2) and Transmit (T3) timestamps so the client can compute offset and delay.

SNTP vs NTP Comparison

SNTP and NTP share the same packet format and port, but they differ significantly in how they process time information. The table below summarizes the key differences.

Key Features of SNTP

• Same wire format as NTP: SNTP packets are byte-for-byte compatible with NTP v4. Any NTP server will accept SNTP client requests without modification, and any packet capture tool will decode them identically.
• Single server simplicity: SNTP clients only need to know the address of one time server. There is no need to configure multiple peers, manage associations, or implement server selection logic.
• Minimal resource requirements: a complete SNTP client can be implemented in a few hundred lines of C code with minimal RAM usage. This makes it ideal for microcontrollers with limited flash and memory, such as the ESP32 or STM32 families.
• Step-based clock adjustment:the client calculates the offset and applies it immediately. This avoids the complexity of NTP's PLL/FLL clock discipline loop but means the clock may jump, which some applications need to handle.
• No persistent state: each query is independent. The client does not need to store historical measurements, drift estimates, or peer statistics between polling intervals. This simplifies both implementation and recovery from restarts.
• Works with any NTP server:public NTP pools like pool.ntp.org, Google's time.google.com, and Cloudflare's time.cloudflare.com all work perfectly with SNTP clients.

Common Use Cases

• Embedded systems and microcontrollers: devices like ESP32, Raspberry Pi Pico, and Arduino with Ethernet shields use SNTP to set their real-time clocks on boot. Many embedded RTOS platforms (FreeRTOS, Zephyr) include built-in SNTP clients.
• IoT sensor nodes: battery-powered sensors that wake periodically to take readings need accurate timestamps for their data. SNTP provides the time with minimal power consumption since it only requires a single UDP exchange.
• Consumer routers and access points: home and small office routers from manufacturers like Netgear, TP-Link, and ASUS use SNTP to synchronize their internal clocks for accurate log timestamps and scheduled operations like firmware updates.
• Set-top boxes and media devices: cable boxes, streaming devices, and smart TVs use SNTP to display the correct time on screen and to validate TLS certificates, which require accurate system time for expiration checks.
• Point-of-sale terminals: POS systems need correct timestamps on receipts and transaction records. SNTP provides sufficient accuracy for these purposes without the overhead of a full NTP implementation.
• Any device needing approximate time: if a device just needs to know the current time within a few hundred milliseconds and does not require the fault tolerance or precision of full NTP, SNTP is the practical choice. It keeps code small, uses minimal bandwidth (a single 48-byte UDP packet each way), and requires no ongoing state management.

Frequently Asked Questions About SNTP

What is the difference between SNTP and NTP?

SNTP and NTP use the exact same packet format and port (UDP 123). The difference is in the client implementation. NTP clients query multiple servers, apply statistical filtering (Marzullo's algorithm), and gradually slew the clock using a feedback loop to maintain sub-millisecond accuracy. SNTP clients query a single server and apply the measured offset as a direct step adjustment. SNTP is simpler but less accurate and less resilient to a rogue or unreachable server.

Is SNTP accurate enough for production use?

It depends on what you mean by production use. For logging, timestamping sensor data, displaying the time on a screen, or validating TLS certificates, SNTP's accuracy of 10-50 ms on a LAN is more than adequate. For applications requiring sub-millisecond precision, such as financial trading systems, distributed database consensus, or telecom billing, full NTP (or PTP/IEEE 1588) is necessary. Most embedded and IoT deployments use SNTP successfully in production.

Can SNTP clients talk to NTP servers?

Yes. SNTP uses the identical packet format as NTP, so any NTP server will respond to SNTP requests without knowing the difference. You can point an SNTP client at pool.ntp.org, time.google.com, time.nist.gov, or any other NTP server. The server processes the request the same way it would for a full NTP client.

What port does SNTP use?

SNTP uses UDP port 123, the same port as NTP. The server listens on port 123, and the client typically sends from a random ephemeral port. If you are running an SNTP client behind a firewall, you need to allow outbound UDP traffic to port 123. Some networks block this port, in which case NTP over TLS (NTS, RFC 8915) on port 4460 is an alternative if the client supports it.

Is SNTP secure?

Basic SNTP has no built-in authentication or encryption. The packets are sent as plaintext UDP, which means they can be spoofed or modified in transit. An attacker could send false time responses to shift a device's clock, potentially breaking TLS certificate validation or disrupting time-dependent logic. NTP supports symmetric key authentication (RFC 5905) and the newer Network Time Security (NTS, RFC 8915) protocol for authenticated, encrypted time synchronization. For environments where time integrity matters, use an NTP client with NTS support rather than plain SNTP.

Should I use SNTP or NTP?

Use SNTP when you have a resource-constrained device (microcontroller, IoT node, consumer appliance) that just needs a reasonably accurate clock. Use full NTP when you need high accuracy, fault tolerance from multiple sources, gradual clock slewing, or when your system depends on precise time (databases, distributed systems, security infrastructure). If your device runs Linux and has enough resources, chrony or systemd-timesyncd provide lightweight NTP client implementations that are only marginally more complex than SNTP but offer significantly better accuracy and resilience.

Related Protocols

• NTP: the full Network Time Protocol that SNTP is based on, with multi-server support, clock discipline algorithms, and sub-millisecond accuracy
• UDP: the transport protocol used by SNTP for its lightweight, connectionless time queries on port 123
• MQTT: another lightweight protocol commonly used alongside SNTP in IoT deployments for messaging and telemetry