emWin upgrade     Trade-In program     Web shop

embOS/IP SNTP Client

The embOS/IP SNTP client implementation is an optional extension which can be integrated into your application seamlessly. It combines a maximum of performance with a small memory footprint. The SNTP client implementation allows an embedded system to use real timestamps from a remote NTP server without using a RTC or to initialize a RTC. The SNTP protocol is based on SNTP v4.

The SNTP client module implements the relevant parts of the following Request For Comments (RFC).

RFC# Description
[RFC 4330] Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
Direct download:
[RFC 1305] Network Time Protocol (Version 3) - Specification, Implementation and Analysis
Direct download:



  • Low memory footprint.
  • Seamless integration with the embOS/IP stack.
  • Time synchronization with a remote NTP server.


TCP/IP stack

The embOS/IP SNTPc implementation requires the embOS/IP TCP/IP stack.


SNTP backgrounds

The SNTP protocol is an API on top of the TCP/IP protocol, it provides a way of synchronizing the target time with a local or remote NTP server over the network.



Using SNTP, an embOS/IP application can synchronize its time with an NTP server either in the local network or in a remote network to use a timestamp with the current date and time or to initialize its own RTC with a good start value.

The NTP timestamp

The NTP timestamp used is represented by a 64-bit value consisting of two 32-bit fields. The first 32-bit field contains the complete seconds passed since January 1st 1900. The second 32-bit field contains fractions of a second in 232 picoseconds.

More information about the NTP timestamp can be found in RFC 1305.

The epoch problem (year 2036 problem)

The NTP timestamp reserves only 32-bit for full seconds passed which equals a little bit more than 136 years. As the NTP time is based on January 1st 1900 this means that the timestamp will overlap back to 0 some time in 2036. A timestamp older than a reference timestamp can be interpreted as valid time, too, as long as it does not count up to the reference timestamp.

Based on this solution there are several possible ways of extending this period even more:

  • The easiest solution to extend the timestamp to be used for around 136 years is for the target to remember the date it was built or had its firmware changed. It can then use this timestamp as reference extending the NTP timestamp for further 136 years.
  • Storing the current year in non volatile memory using it as reference in which epoch the target runs.
  • Using other sources as reference for the epoch such as timestamps from other sources.

Resource usage

The ROM usage depends on the compiler options, the compiler version and the used CPU. The memory requirements of the SNTP Client module presented in the tables below have been measured on an ARM7 and a Cortex-M3 system. Details about the further configuration can be found in the sections of the specific example.

ROM usage on an ARM7 system

The following resource usage has been measured on an ARM7 system using IAR Embedded Workbench V6.30.6, Thumb mode, no interwork, size optimization.

Add-on ROM
embOS/IP SNTP Client module Approximately 0.5 KByte

ROM usage on a Cortex-M3 system

The following resource usage has been measured on a Cortex-M3 system using IAR Embedded Workbench V6.30.6, size optimization.

Add-on ROM
embOS/IP SNTP Client module Approximately 0.5 KByte

RAM usage

Add-on RAM
embOS/IP SNTP Client module Approximately 24 Byte