synch clock using SNTP

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

I need to timestamp some data and store it in the EEPROM of a ATMega128
chip. I'm using Nut/OS to program a mobile device.

Can someone guide me as to what SNTP servers are publicly available and
how I can do my timestamping bit efficiently? I was thinking.. once the
device starts, I can get the time of day using SNTP and then use an
internal clock to synchronize this time, i.e. I won't need to query the
SNTP again and again and simply use the internal clock (Nut/OS provides
the resolution of a second) and calculate the current time of day. Does
that seem like a good idea? Any suggestions are appreciated. Thanks


Re: synch clock using SNTP
Quoted text here. Click to load it

Whoa, Silver! Hardcoding names and/or addresses of public servers
(that you don't maintain) into an embedded application is a Very Bad
Thing. To see just how much of a Bad Thing it can be, particularly
when combined with the additional evils of firmware bugs and a huge
userbase, refer to this recent story (this story made it into
mainstream press, too):
< .

If your application relies on NTP services, I suggest you maintain a
server of your own.

As a secondary possibility, maintain a textfile on web space you
control, which points to currently-accessible NTP servers. So your app
fetches , and parses the textfile
to ascertain the SNTP server du jour. At least this way, you can make
ex post facto changes.

Re: synch clock using SNTP

Quoted text here. Click to load it

Thanks Lewin :) Those were some wonderful suggestions.. I'll definitely
fix my design. BTW, what do you think about the idea of not querying
SNTP again and again?



Re: synch clock using SNTP on embedded system
[cross-posted to ntp newsgroup after reconstructing original post]

Quoted text here. Click to load it

Only query it when you think your clock has drifted too much for your
application. And don't pound a server for an answer if it's not
responding. Use exponential back off.

BTW, I just recently learned of a new NTP service: /

This is intended for systems that don't need "close" servers for ultra-
accurate time, and don't want to hard-code a server name.

I'd also favor the CNAME solution (, pointing initially
at the pool server. This eliminates your product's vulnerability to a
change in management or policy at As long as you keep your own
domain registered, you'll control where your CNAME is pointing.

How are you finding your DNS server? DHCP? If so, check for an NTP server
option set on the DHCP server and use that in preference to your hard-
wired name. I supply that option from my DHCP servers, pointing at the
NTP server on my LAN.

Another idea: (I don't know what downsides there are to this. NTP gurus?)
If the above ideas fail, as a last resort, traceroute to a well-known
public server and look for NTP service on each router along the way,
using that of the closest router. It's also not uncommon to run NTP on
DNS servers, so you could look for it on your configured DNS server.

Kenneth Porter /

Re: synch clock using SNTP
Quoted text here. Click to load it

Repeatedly and unnecessarily querying someone else's SNTP server is
quite rude.  Don't. Repeatedly and unnecessarily querying your own
SNTP server merely costs you the extra money required to support the
excess load, both in server resources and bandwidth.

Re: synch clock using SNTP (Robert Wessel) writes:

Quoted text here. Click to load it

Don't do this especially if you are a router manufacturer like say,

See: /

for all the sordid details, but suffice it to say that having your box
hit a fixed address for a NTP server every time it boots and then
polling said server every second until it gets service is a bad, bad

Brian K. Ogilvie  (remove the no spam please to email)

Re: synch clock using SNTP (Lewin A.R.W. Edwards) wrote in message
Quoted text here. Click to load it

Easiest of all may be making "" a CNAME for
the real NTP server.

Re: synch clock using SNTP
Hi Robert,

Quoted text here. Click to load it

Yes... I had some vague idea similar to this in the back of my head,
but how does this scenario handle fallback if the site you're
directing to is down? (I don't know a whole lot about DNS internals).

Also, how do you handle load balancing to multiple NTP servers? (Given
that you are not going to be able to flush everyone's DNS cache
upstream, there is no way for you to interleave lookups to point at
different servers - and it might not even be possible if you're using
virtual hosting, as it would require your presence provider to install
truly clever software on their NS machines).

If your embedded app downloads a list, it's slightly more network
traffic but allows a lot more flexibility IMHO.

Re: synch clock using SNTP
Quoted text here. Click to load it

IMHO the original poster wanted to initialize the devices clock ONCE
hence there is not much load to expect - unless they of course would
sell hundred thousands of units per day.

To me - given the initialize only once scenario - the CNAME "trick"
sounds fairly good. Otherwise it also depends on the kind of device
the OP is having in mind. If it's configurable, the NTP (or SNTP)
server could (should) be one of those parameters.

Having the device donlowad a list of servers is IMHO only then needed
if there is a querying interval planned. If so then surely a good
idea. One could also create a website containing only those
timerserver strings. This would have the aditional benefith of a)
human readability and b) less likely that the device - if sitting
behind a firewall - would not be blocked from reading the list since
port 80 is likely not to be blocked for outgoing traffic.

Even with only one single qurey per day the load should not become
dramatic if the point in time of the day is choose wisely (i.e.
depending on the MAC address or every 24 hours after booting etc.)

Just my 2


Re: synch clock using SNTP (Lewin A.R.W. Edwards) wrote in message
Quoted text here. Click to load it

Handling down servers either requires some work at the client or at
the DNS server.  If the client accepts several results for a DNS
query, and the first one it tries doesn't respond, it can move on to
try the others.  Multiple results are standard in DNS, but many
clients only pick the first one, so a bit of extra work may be
required there.

Alternatively, if you update the DNS server promptly so that only
active NTP servers are in the list, and keep the TTLs pretty short,
the client can just pick the first entry returned with some assurance
that the server is up.  This requires some additional work at the DNS
end, but any of the DNS load-balancing/fail-over packages/appliances
will do the trick if you set them to monitor the servers in question.
You can also roll your own without much trouble - just have a deamon
running that monitors the NTP servers, and recreates the zone file if
the list changes and then executes "ndc reload" (assuming BIND, other
DNS server will vary a bit).  Or just monitor the servers in some
fashion and update the zone files manually as needed.  Again, keeping
the TTL's short is necessary to keep pointers to dead NTP servers from
floating around too long.

Load balancing can be trivial or fairly hard depending on what you
want to do.  In the simplest case, just define more than one "A"
record for "" (these would be the IP addresses of the
public NTP servers you want to use), and most DNS servers will rotate
the order in which the results are returned by default, on those where
it's not the default, there's usually an option to make it happen.
Clients typically just grab the first result, so if the list is
rotated on each query, they'll get distributed. DNS
load-balancing/fail-over packages/appliances can do a more
sophisticated job.

Combining some smarts at the client and at the DNS server can be the
best approach.  If the client will work through the received list of
potential NTP servers, having a dead server in the list isn't nearly
as bad a problem.  Combined with semi-prompt DNS updates if a server
does go down, your clients almost always avoid the dead servers in the
first place, so performance stays good (assuming that a dead server
results in a delay while waiting for the timeout at the client).

The exact options depend on the DNS server in use and how much control
you have over it.  For example, the DNS server at a typical hosting
site or ISP, will limit you to basic round-robin DNS results (the
multiple "A" record approach), with "real" load-balancing available at
some sites for extra money.

Re: synch clock using SNTP
Quoted text here. Click to load it

I'm assuming from the nature of the question that the OP probably
doesn't run his own DNS. If he did, then he could run his own NTP and
that would likely have been his first idea. So in order to support
this tricky stuff requires getting a virtual hosting provider to
implement it - which might not be easy!

Quoted text here. Click to load it

Interesting. I must file this for future reference.

Quoted text here. Click to load it

Ah. None of the providers I've dealt with support multiple records for
subdomains. They basically implement subdomains primarily to allow you
to have "" redirecting to
"". But then, I do tend to shop on price... :)

Re: synch clock using SNTP (Lewin A.R.W. Edwards) wrote in message
Quoted text here. Click to load it

Round-robin is commonly available on "real" DNS services.  For

will host a single zone for $10/yr.  (Link for illustration only, not
a recommendation one way or another).

It's also included in most business class ISP services (eg. SDSL,

Re: synch clock using SNTP (Robert Wessel) wrote in

Quoted text here. Click to load it

For comparison, ZoneEdit ( /) will host 5 low-traffic
zones (just the DNS records) free. I use them for secondary service.

Obviously this would be unsuitable for a consumer product sold in the
thousands, unless you could be sure it always contacted a local DNS and
depended on DNS caching to avoid hitting your zone's authoritative servers
every time.

Kenneth Porter /

Re: synch clock using SNTP
Quoted text here. Click to load it
Are you going to collect the data from the unit? If so, why not just set the
time then? What resolution do you need your timestamping to be? You should
be  able to calculate your clock drift to see how often you do need to


Re: synch clock using SNTP
Thanks for all the suggestions guys!

One question though.. seems to be a good SNTP time server
that's available to the public. Should I connect to a SNTP server using
a TCP connection? Or do I send a UDP packet and expect a UDP packet?
where can I find out about these programmatic details? Thanks


Re: synch clock using SNTP

Quoted text here. Click to load it

Get the SNTP RFC.

NTP and SNTP are using UDP (port 123).

Tauno Voipio
tauno voipio @ iki fi

Re: synch clock using SNTP

Quoted text here. Click to load it

Nope, see Brad Knowles' reply to this thread over in
comp.protocols.time.ntp (mirrored from the ntp-questions mailing list):

Use your own server, or a server for which you've acquired permission to
point your devices at.

Kenneth Porter /

Site Timeline