The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. NTP uses UDP port 123 as its transport layer. It is designed particularly to resist the effects of variable latency (jitter). Source: Wikipedia
NTP Service on WiFi "ui-rise" Network
When users are connected to the ui-rise network during a mission, computer requests for major NTP servers are intercepted and processed by the router the user is connected to. This is done because no internet connection is available during a mission and the NTP request would be unsuccessful otherwise. It also ensures that computers on the ui-rise network are properly time-synced so that the mission data can be analyzed easily after the mission.
NTP Stratum Source (what is stratum)
Ideally our routers are stratum 1 devices because they get their time directly from a GPS device. But compared to other stratum 1 servers maintained by NIST or other organizations our routers will not be very accurate. Our primary goal is to have consistent time across all network devices so that time-stamped data collected by different computers can be readily combined without temporal errors causing odd effects. Since we already collect GPS position data, we decided that it wouldn't be too difficult to use GPS time data to set the clock.
When connected to the NTP server with the NTP Query program (ntpq) you can determine if a time source is being used by the NTP server to provide the time by looking for an astrik (*). In the image at the right, notice the astrik on the lower tables of data. Also notice that the first table of data lacks an astrik. Once the source is locked, you should be able to successfully synchronize with the router's NTP server.
Problems on an Embedded Device
The Linksys WRT-54G routers don't actually have a clock built into them. Instead they keep track of time by keeping track of processor cycles. As a result they can't keep track of time when turned off or rebooted. Since a VAST mission usually doesn't have internet access, it isn't possible for the router to sync to an internet time server. As a result GPS is the only place to get this data.
GPSd has a functionality to provide NTPd with time data. But we aren't sure when that was added, or if it was even enabled when it was cross-compiled for OpenWRT. We also don't know how NTPd (or even OpenNTPd) was compiled for the router. As a result we are having difficulties determining how to read the time from GPS data.
We have been able to get OpenNTPd running on the router, but ran into a unique problem. We couldn't get it to work by reading the time from the GPS, so we wrote a script to set the system time to that from the GPS. OpenNTPd doesn't accept this as an accurate time source (and we don't blame it, we just wish there was another way around it), and as a result reports a high stratum. Most computers won't synchronize with a high stratum server because it represents inaccuracy, and our time reported by the NTP server is ignored by the computers that we need to set the time on. As a result this method with OpenNTPd is a dead end.
We will look into determining how GPSd and NTPd were compiled for OpenWRT and see if a solution can be found that allows computers to synchronize with the router.
Current Situation Updated 10/20/2007
We have NTPd running and pulling data from GPSd. But it takes several (6?) poll cycles spaced in 16 second intervals to 'lock' the time. This is above and beyond the time required to establish a GPS lock. As a result NTPd can take as much as 5 minutes to get working depending on GPS signal strengths. To deal with this problem we need to ensure the GPS antenna gets clear and strong signals, and we must make sure the router is not accidentally power-cycled.
There are other issues with NTPd. Right now it appears to crash after 10 minutes or so of operation. We haven't figured out where error messages are being written, but we will be investigating this behavior. After the crash NTPd needs to be restarted, and again must go through several polling cycles to lock the time. 16 second intervals are the shortest time intervals allowed, so it might take 2-3 minutes before NTPd locks the time and changes the stratum of the sever to one that a Windows machine will accept.
