I am actually talking about two different sets of code for retrieving time via NTP. The first is the code at http://arduino.cc/en/Tutorial/UdpNtpClient
. This code does not work with the current version of the Arduino IDE (0022), and should be updated. I would suggest updating to the example code included in the Arduino IDE, which does work, however...
The code included with the Arduino IDE does some dangerous things. Most importantly, it polls a public server every 10 seconds!
To make matters worse, it a stratum 1 server, which are already overburdened1
. Now imagine a classroom of students with Arduinos all firing up NTP clients at the same time, or worse, the same code being embedded in a project and causing huge floods of traffic to the NTP servers for years to come2
. Now I know this is example code, and not meant to be used in production sans modification, but let's not have it use bad practices by default. The last thing I want is an excuse for people to point a finger at such an open, lauded platform for development.
So, what would I recommend changing? First and foremost, don't include a hard-coded public stratum 1 server in the code. Instead, have no default server (0.0.0.0), and include a link to a list of public stratum 2 time servers
, and inform users how to look up the IP addresses (`nslookup` on windows; `host` on everything else) of the servers on the list to hard-code it into the example. If you insist on the example working "out of the box" (aside from possibly IP, subnet, gateway, & MAC address changes), then someone at arduino.cc should set up a public time server for the purpose.
In addition, do not
have the code synchronize every 10 seconds by default, unless the people at arduino.cc are running the time server, and even then make a note that when using with other public servers the delay should be increased.
I'm all for making things easy for people, and it can still be easy while at the same time not being problematic to others. I also don't think many of the Arduino users want to a burden, and likely don't even know that they are.
1) COPING WITH OVERLOAD ON THE NETWORK TIME PROTOCOL PUBLIC SERVERS
2) Flawed Routers Flood University of Wisconsin Internet Time Server
3) Rules of Engagement