diff options
| author | Matt Rude <[email protected]> | 2011-05-21 22:31:34 -0500 |
|---|---|---|
| committer | Matt Rude <[email protected]> | 2011-05-21 22:31:34 -0500 |
| commit | 2b4e098c3dc537b48475fbcde9483bd88bd1ffd0 (patch) | |
| tree | 5f6c77f24ae7b09528e3e1741f6735fc3983769e /archives | |
| parent | 9dadd9eb53928e5b16b89f6bbba96973997142e5 (diff) | |
| download | time.mattrude.com-2b4e098c3dc537b48475fbcde9483bd88bd1ffd0.tar.gz time.mattrude.com-2b4e098c3dc537b48475fbcde9483bd88bd1ffd0.tar.bz2 time.mattrude.com-2b4e098c3dc537b48475fbcde9483bd88bd1ffd0.zip | |
delete bad names
Diffstat (limited to 'archives')
| -rw-r--r-- | archives/FreeBSD_NTP_GPS_Experiment_#2.html | 170 | ||||
| -rw-r--r-- | archives/FreeBSD_NTP_GPS_Experiment_#4.html | 247 |
2 files changed, 0 insertions, 417 deletions
diff --git a/archives/FreeBSD_NTP_GPS_Experiment_#2.html b/archives/FreeBSD_NTP_GPS_Experiment_#2.html deleted file mode 100644 index 257d1ae..0000000 --- a/archives/FreeBSD_NTP_GPS_Experiment_#2.html +++ /dev/null @@ -1,170 +0,0 @@ -<HTML><HEAD> -<TITLE>FreeBSD NTP eTrex GPS experiment</TITLE></HEAD> -<BODY BGCOLOR=FFFFFF> -<CENTER> -<H1>FreeBSD NTP GPS Experiment #2</H1> -Using a commercial GPS unit as a NTP time source<BR> -</CENTER> -<HR> -<B>This system is no longer running. Check -<A HREF="../ntp-gps.html">here</A> for other GPS/NTP systems.</B><BR><BR> - -This page monitors an experimental -<A HREF="http://www.ntp.org">NTP time server</A> using a -<A HREF="http://www.garmin.com"> -Garmin</A> eTrex GPS receiver as a clock. -<BR> -<HR> -<H3>Setup</H3> -The server is a Shuttle system, with a 2 GHz Celeron CPU and 256M of RAM, -running FreeBSD 4.10. This server sits behind a NAT router, attached to -a broadband cable modem in my basement. The eTrex is connected to -com port 2 of the server via a home-brew serial cable, which also -supplies regulated 3VDC power to the GPS. I learned how to make the -cable here: <A HREF="http://www.jens-seiler.de/etrex/datacable.html"> -http://www.jens-seiler.de/etrex/datacable.html</A>, and here: -<A HREF="http://www.nomad.ee/micros/etrex.shtml"> -http://www.nomad.ee/micros/etrex.shtml</A>. The power supply is a -12VDC 'wall-wart' transformer connected to an automotive variable- -voltage accessory adapter, set to 3VDC.<BR><BR> - -I'm running the stock ntpd daemon via setting xntpd_enable="YES" in -/etc/rc.conf. In the /etc/ntp.conf file, I've selected both the -generic NMEA and local clock device drivers:<BR><BR> - -<PRE> -# Local clock, in case GPS fails -server 127.127.1.0 -fudge 127.127.1.0 stratum 10 - -# NMEA GPS driver -server 127.127.20.1 prefer -</PRE> -<BR> - -I also made a symbolic link '/dev/gps1', which points to -/dev/ttyd1, the name of the comm 2 port in FreeBSD. The driver expects this -link to tell it where the GPS is attached to the system.<BR><BR> - -The eTrex has NMEA mode set on its 'system:interface' setting to -output NMEA sentences, which the driver then parses to get the -current GPS time. UTC time is then calculated from this (GPS time -doesn't use leap seconds, UTC does, however the NMEA $GPRMC sentence -that the driver defaults to has the UTC in it, calculated by the -GPS unit itself), and the clock is set.<BR><BR> - -I've also enabled statistics file generation to track how the receiver -is doing. A collection of shell scripts cull the data from the stats -files and hand them off to Ploticus, which generates the graphs for -the current UTC day's data every 15 minutes.<BR><BR> - -<H3>Results</H3> -In the timekeeping world, GPS clocks are known for their jitter. -Their short-term stability is not all that hot, but long-term -stability is very good, since the satellites are kept locked to -national time standards to within about 5 nanoseconds. This being -said, the Garmin eTrex is designed as a position GPS, not a -timing GPS. The difference is that timing GPS units have a 1 pulse per -second (PPS) output which is steered to within 50 nanoseconds -(ideally) of actual GPS time. A computer connected to this would -have this PPS signal fed into a signal line (the DCD pin of the -serial port is the usual place) and use it to discipline the -local clock to very close to the exact time. Since the PPS -signal carries no data as to which second it's indicating, the -serial NMEA string is also used to tell the server what the actual -time is. <BR><BR> - -Non-timing GPS units like the eTrex spit out NMEA sentences about once -every second. The variation is due to the fact that the GPS unit was -designed with low cost, rather than super-accurate timing in mind, and -as such the construction and output of the NMEA sentence is considered -a lower priority by the GPS' CPU. This shows up as rather large jitter -in these GPS units, as you can see in the -<A HREF="http://jcnsystems.dyndns.org/~nordlie/time/">graphs</A>. -It appears that in this case, the time signal can vary +-150ms and -even worse in some cases.<BR><BR> - -<H3>Rationale</H3> -Why build a GPS time server in the first place? After all, there are -already -<A HREF="http://www.boulder.nist.gov/timefreq/">publicly available -time servers</A> that administrators can use to synchronize their -system clocks. The reasons are many, but the primary one in this -case is that the broadband network this system is connected to is -so congested that trying to sync to public time servers was almost -impossible. The ntpd daemon was getting so far off that it was -causing clock resets by more than half a second, and sometimes multiple -seconds, rather than slowly slewing the clock as is normally done. -Other systems on my home LAN that sync to this server were also having -problems because of all this bouncing around of the current time -reading. Some sort of stabilizing influence was needed other than -depending on external network time servers, and I had almost all the -hardware for this experiment at hand. This setup is not ideal, in -that it uses a non-timing GPS receiver, and the receiver is located in a -basement where it has trouble keeping locked on satellite signals -at times. <BR><BR> - -Other possible time sources are various radio clocks, shortwave radio -receivers feeding WWV/WWVH signals into a sound card, WWVB radio -clocks, LORAN-C radio clocks, precision frequency sources fed into -the PPS driver, etc. The -<A HREF="http://www.eecis.udel.edu/~mills/ntp/html/refclock.html"> -Reference Clock Driver</A> -page has many more options, and makes for some fascinating reading. -<BR><BR> - -<H3>Update: January 24, 2005</H3> -The system has been running for two days now. The GPS unit loses -satellite lock on a fairly regular basis (indicated by the flat -spots on the 'time offset' graphs), and the ntpd daemon falls back -to the computers local oscillator as a timebase. Locating the GPS -outdoors with a better view of the sky would doubtless overcome -this problem, but I'm in no hurry to do that at this time. -<BR><BR> - -<H3>Update: January 28, 2005</H3> -It appears that the GPS receiver hasn't received an update for over -24 hours now. The ntp daemon has been running on the local -oscillator, which is about 0.125 sec out of sync with public -ntp servers. I will need to check the receiver and see what's -going on. Since the clockstats file only updates every time the -GPS NMEA sentence is used to adjust the clock, the stats page -still contains data on it, while the peerstats file shows the -local clock with no offset, variance, or jitter. Since peerstats -continues to update, the two files get out of sync and generate -plots that could mislead those not familiar with how ntpd works. -<BR><BR> - -It seems clear now (and further research on the web confirms this) -that GPS receivers not designed for timing applications are not -appropriate by themselves to construct stratum 1 ntp servers. While -the timing of the NMEA sentences will get ntpd within about 1 -second of UTC, timing receivers with 1 PPS output lines are -advertised to providing accuracy to about 50ns. The next phase -of this experiment will be acquiring a PPS GPS receiver and -placing it where it can get a good view of the sky. -<BR><BR> - -The eTrex or other non-timing GPS receivers could be used in NMEA -mode to provide second information when an accurate 1 PPS source -is also used (i.e. a WWV/H/B radio clock, or cesium frequency -source), however it would seem false economy to invest in one -of these sources to discipline a cheap GPS receiver. The best -'bang for the buck' looks like getting a timing GPS receiver -in the first place, since it can provide both the NMEA second -information and a PPS signal. -<BR><BR> - -<B>Links:</B><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/service/gpscal.htm"> -Using a GPS receiver as a NIST traceable frequency standard</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/service/gpstrace.htm"> -NIST GPS data archive</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/">NIST Time and Frequency -Lab</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/ion/">NIST Ion Storage -Group</A><BR> - - -</BODY> -</HTML> diff --git a/archives/FreeBSD_NTP_GPS_Experiment_#4.html b/archives/FreeBSD_NTP_GPS_Experiment_#4.html deleted file mode 100644 index 473c27f..0000000 --- a/archives/FreeBSD_NTP_GPS_Experiment_#4.html +++ /dev/null @@ -1,247 +0,0 @@ -<HTML><HEAD> -<TITLE>FreeBSD NTP Garmin GPS-16 HVS experiment</TITLE></HEAD> -<BODY BGCOLOR=FFFFFF> -<CENTER> -<H1>FreeBSD NTP GPS Experiment #4</H1> -Using a Garmin GPS-16 HVS unit as a NTP time source<BR> -</CENTER> -<HR> -This page monitors an experimental -<A HREF="http://www.ntp.org">NTP time server</A> using a -<A HREF="http://www.garmin.com"> -Garmin</A> GPS-16 HVS receiver as a clock. -<BR> -<UL> -<LI><A HREF="http://jcnsystems.dyndns.org/~nordlie/time">Statistics generated every 15 minutes</A></LI> -</UL> -<HR> -<H3>Setup</H3> -The server is a -<A HREF="http://us.shuttle.com/home.aspx">Shuttle</A> -computer system, with a 2 GHz Celeron CPU and 256M of RAM, -running -<A HREF="http://www.freebsd.org">FreeBSD</A> 6.2. -This server sits behind a NAT router, attached to -a broadband cable modem in my basement. The GPS-16 HVS is connected to -com port 1 of the server via a home-brew serial connector, which also -supplies regulated 12VDC power to the GPS. The connector is a modified -serial terminal adapter, with a DB-9F connector on one side and an RJ-45F -connector on the other, with a DC power input jack added to power the GPS. -Power is supplied by a Radio Shack 12 VDC 500 mA 'wall-wart' power -supply. -<BR><BR> - -I obtained the GPS-16 HVS unit from <A HREF="http://www.navtechgps.com/"> -www.navtechgps.com</A>, under the "Combination GPS/Antenna" section. The -GPS-16 HVS provides the necessary 1 Pulse Per Second (PPS) line needed for -highly accurate timing, as well as accepting a wide range of DC voltages for -power input. While -this units works well, recently other NTP timekeepers have had good luck -with the much-cheaper Garmin GPS-18 LVC (be sure to use the LVC version, -which includes a 1 PPS line). I wired the connector according to the -chart in the <A HREF="http://www.navtechgps.com/pdf/16_17HVS_manual.pdf"> -GPS-16 manual</A>, page 7. I also connected the grey 1 PPS line to pin -1 on the DB9 connector (Data Carrier Detect), so that the NTP PPS driver can read it. Even -though the PPS line is only TTL (0-5 VDC), most modern RS-232 ports -can still sense it without any additional electrical conditioning. -<BR><BR> - -After the hardware was built, I tested it and configured the GPS-16 HVS -unit using the SNSRCFG program available at the Garmin website: -<A HREF="http://www.garmin.com/oem">www.garmin.com/oem</A>. Click -on the GPS unit, then choose "Downloads & Updates" on the menu at -left. Running the program on a windows desktop, I verified that the -unit was receiving satellite transmissions in the location I had -placed it (a window). I left most everything in the configuration -in the default mode, except: I turned off all NMEA sentences except -GPRMC (which is what the NTP driver looks for), and enabled the -PPS line. -<BR><BR> - -The software configuration was fairly simple. To run the NTP daemon -at system startup, I added 'xntpd_enable="YES"' to the /etc/rc.conf -file on the FreeBSD system. The NTP daemon drivers need to know -where to find the data and signals for using the GPS. The NMEA -and PPS drivers look for devices with names /dev/gpsx and /dev/ppsx -respectively, where x is the unit number. In this case I created -symbolic links in the /dev directory as such: -<BR> - -<PRE> -gps0 -> cuad0 -pps0 -> cuad0 -</PRE> - -These refer to the first serial communications port (COM 1), where -the GPS unit was connected. Since I didn't want to lose the links -any time 'make' was run in the /dev directory, such as a system -update, I added:<BR> - -<PRE> -# link GPS receiver for NTP use -link cuad0 gps0 -link cuad0 pps0 -</PRE> - -to /etc/devfs.conf. -<BR><BR> - -Now the NTP configuration itself. In this case I used the generic -GPS NMEA driver for the serial stream, and the PPS driver to -discipline the clock (increase the accuracy of the GPS NMEA sentence). -To tell NTP which clock is to be disciplined, the 'prefer' tag is -added to the NMEA driver line. I also added an entry to poll an NTP -server on my ISPs network, and finally enabled the local system clock -to act as a backup in case everything else went down. Here's the -/etc/ntp.conf file in its entirety: - -<PRE> -# Local clock, in case network link goes down -server 127.127.1.0 -fudge 127.127.1.0 stratum 10 - -# NMEA GPS driver -server 127.127.20.0 prefer - -# Pulse Per Second (PPS) driver fine-tunes -# the data provided by the NMEA GPS -server 127.127.22.0 - -# Network NTP server for comparison, but tell NTP never to use -# it for a timesource -server tock.midco.net noselect - -# Where to keep track of the local clock drift -driftfile /etc/ntp.drift - -# Tell ntpd to keep statistics -statsdir /var/log/ntp/ -filegen clockstats file clockstats type day enable -filegen peerstats file peerstats type day enable -filegen loopstats file loopstats type day enable -statistics clockstats peerstats loopstats - -# Send log output to a seperate file for NTP -logfile /var/log/ntp/messages -</PRE> -<BR> - -<H3>Results</H3> -So far the results of the system have been very good. Here is a -typical time reading: - -<PRE> -> ntpq -p - remote refid st t when poll reach delay offset jitter -============================================================================== - LOCAL(0) LOCAL(0) 10 l 52 64 377 0.000 0.000 0.002 -+GPS_NMEA(0) .GPS. 0 l 15 64 377 0.000 -0.018 0.004 -oPPS(0) .PPS. 0 l 6 64 377 0.000 -0.018 0.004 -xtock.midco.net .GPS. 1 u 19 64 377 16.811 1.340 0.072 -</PRE> - -The offset wanders around a bit but the jitter, indicating the clock -stability, is always very low. This setup performs much better than -the <A HREF="../ntp-gps2">eTrex</A> GPS, due to the availability of -the 1 PPS signal. The GPS-16 HVS has locked up once during the -experiment (running about 1 month as of April, 2007), requiring -cycling the power to reset the receiver. Also the GPS does lose -lock occasionally, and the time and PPS jump when lock is re-established. -<BR><BR> - -<H3>Rationale</H3> -Why build a GPS time server in the first place? After all, there are -already -<A HREF="http://www.boulder.nist.gov/timefreq/">publicly available -time servers</A> that administrators can use to synchronize their -system clocks. The reasons are many, but the primary one in this -case is that the broadband network this system is connected to is -so congested that trying to sync to public time servers was almost -impossible. <I>Note: as of April 2007, this has gotten much better, -due to a network upgrade performed by midconet.</I> -The ntpd daemon was getting so far off that it was -causing clock resets by more than half a second, and sometimes multiple -seconds, rather than slowly slewing the clock as is normally done. -Other systems on my home LAN that sync to this server were also having -problems because of all this bouncing around of the current time -reading. Some sort of stabilizing influence was needed other than -depending on external network time servers. -<BR><BR> - -One easy but less accurate way around this would be to run an NTP -server with the localclock driver as the source. Since this -runs off the systems quartz frequency standard, the time will -drift with temperature and sometimes voltage, but will still be -much more stable than NTP trying to synch to multiple servers -on a clogged network connection. Such a system should itself -be synched either manually or perhaps through a crontab by -running ntpdate against a public NTP server. This sacrifices -accuracy for stability, and is probably sufficient for many -applications. Those <A HREF="http://www.leapsecond.com/time-nuts.htm"> -time-nuts</A> among us looking for ever greater accuracy can -never leave well enough alone, however. :) -<BR><BR> - -Other possible time sources are various radio clocks, shortwave radio -receivers feeding WWV/WWVH signals into a sound card, WWVB radio -clocks, LORAN-C radio clocks, CDMA (cellular phone) clocks, -precision frequency sources fed into -the PPS driver, etc. The -<A HREF="http://www.eecis.udel.edu/~mills/ntp/html/refclock.html"> -Reference Clock Driver</A> -page has many more options, and makes for some fascinating reading. -<BR><BR> - -<B>Update: April 16, 2007</B><BR> -The system has been running fairly well. When the GPS receiver loses -signal lock, ntpd switches to the next highest stratum server, which -is the external server used for comparison. Since this server runs -at an offset from the GPS, this causes some instability in the test -server. To help reduce this, I added the 'noselect' option to the -external server line, which instructs ntpd to never use that -server as a timesource. Ntpd should now switch to the 'local' clock -when GPS is unavailable, which should be fine for short periods. Since -the local clock is frequency-adjusted by ntpd based on other clocks -such as the GPS, it should act as a hold-over clock while the GPS -receiver reaquires signal lock. -<BR><BR> -Note: this configuration is aimed at this GPS/NTP experiment. One would -not normally configure an NTP server synchronizing a network this way. -Having ntpd fall back to other external servers is the normal mode -of operation, sacraficing a small measure of stability for overall -reliability and accuracy. -<BR><BR> - -<B>Update: December 26, 2007</B><BR> -A further study the frequency of GPS loss-of-lock events: The system -queries the GPS receiver about every 64 seconds, or 1340 times per -day. If the receiver is unlocked the GPRMC sentence includes a 'V' -character, if the receiver has a positive lock an 'A' appears in the -sentence. A script was constructed to report the number of unlocked -sentences per day contained in the daily 'clockstats' log files. The -results for the period from March 14, 2007 through December 26, 2007 -appears <A HREF="images/gps_lock_drops.jpg">here</A>. The graph seems -to indicate a yearly trend in the average number of daily lost-lock -events. This may be due to satellite constellation configuration, -attenuation of radio signals by atmospheric moisture, changes in -receiver sensitivity or noise floor due to temperature, or -some combination of these effects. Again, the receiver is located -on the sill of a south-facing window, indoors, with a good view of the -southern sky through the glass.<BR><BR> - -<B>Links:</B><BR> -<A HREF="http://www.wraith.sf.ca.us/ntp/">NTP server using PC gnu/linux and FreeBSD</A><BR> -<A HREF="http://www.david-taylor.myby.co.uk/ntp/FreeBSD-GPS-PPS.htm"> -Adding a FreeBSD NTP server based on an GPS 18 LVC</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/service/gpscal.htm"> -Using a GPS receiver as a NIST traceable frequency standard</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/service/gpstrace.htm"> -NIST GPS data archive</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/">NIST Time and Frequency -Lab</A><BR> -<A HREF="http://www.boulder.nist.gov/timefreq/ion/">NIST Ion Storage -Group</A><BR> - - -</BODY> -</HTML> |