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
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
formatting link
and parses the textfile to ascertain the SNTP server du jour. At least this way, you can make ex post facto changes.
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?
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 resynchronise.
[cross-posted to ntp newsgroup after reconstructing original post]
Rick wrote in news:3f8d737a$ snipped-for-privacy@clarion.carno.net.au:
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:
formatting link
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 (ntp.mydomain.com), pointing initially at the pool server. This eliminates your product's vulnerability to a change in management or policy at ntp.org. 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.
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.
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.
One question though.. time.nist.gov 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
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.)
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 "ntp.mydomain.com" (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.
Don't do this especially if you are a router manufacturer like say, Netgear!
See:
formatting link
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 idea.
-- Brian K. Ogilvie snipped-for-privacy@ieee.org (remove the no spam please to email)
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!
Interesting. I must file this for future reference.
Ah. None of the providers I've dealt with support multiple records for subdomains. They basically implement subdomains primarily to allow you to have "subsite.mydomain.com" redirecting to "mydomain.com/subsite-dir". But then, I do tend to shop on price... :)
snipped-for-privacy@yahoo.com (Robert Wessel) wrote in news: snipped-for-privacy@posting.google.com:
For comparison, ZoneEdit
formatting link
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.