Re: [ntp:questions] Peer Review of ntpq -c rv
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f582243.10...@c3energy.com... [] At first I was confused and thought he was ms off. However, if he's within 34 us, that's pretty good. Sounds like his board is working OK, but could possibly be a bit better. If he were communicating exclusively on the serial port and the PPS were not working, would he be getting performance this good? As has been written here many time before - serial NMEA alone is likely to about as good as Internet sources (if that) and perhaps three orders or magnitude worse than a serial port PPS/DCD connection. Milliseconds, not microseconds. [] However, the manual for the Trimble Resolution T recommends GPZDA for timekeeping. Strange they do that as that sentence has no information about whether the GPS data is valid or whether the GPS is locked. Until I hear a good reason otherwise, that seems to me to be the /worst possible/ single NMEA sentence to use! Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] got the Sure GPS on order, how do I program it
unruh un...@invalid.ca wrote in message news:VxP5r.41044$np3.19...@newsfe05.iad... [] I presume (.exe) that this is a windows program. Not too useful for those that use Linux or BSD unfortunately, or have you ported it? The source is provided. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] got the Sure GPS on order, how do I program it
unruh un...@invalid.ca wrote in message news:IQN5r.8981$x%7.7...@newsfe01.iad... [] Trying to figure out the exact format of commands to send to accomplish something is not play. It is an exercise in futility. commands have very very specific syntax, and discovering that syntax and what any particular command does by trial and error is hopeless. You wouldn't have enjoyed code-breaking, would you? G Anyway, for the Sure chip manuals (for other boards) are available fortunately. However, I would not let sure off the hook for their woefully inadequate manual. It's not a Sure chip, but a Skylab SKG16B. I don't see Dell providing Intel programming manuals. We disagree, and I see no point in responding further. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] got the Sure GPS on order, how do I program it
Chris Albertson albertson.ch...@gmail.com wrote in message news:CABbxVHuTF=J_oCmDFfVM- [] It _is_ fair to blame Sure Electronic. They selected the chip. If they selected one with poor documentation it's them who did that. They could have picked some other chip with better docs. If you want an evaluation board for a different chip, surely you would buy a different board? That is one reason I like the Motorola brand and the Trimble brand or even Rockwell GPSes. They have first rate docs written in the USA by real technical writers speak English as their native language. (Actually I'd buy the Sure stuff if it saved me a ton of money or worked better.) For NTP, Chris, what aspect of performance is inadequate? But on the other hand, the Sure GPS works well enough if you can build a custom serial/PPS cable and then just turn it on. You don't need to know how it works if you are using it only for NTP. Chris Albertson Redondo Beach, California No special cable needed, just one or two extra links on the board. I see it as a very low-cost solution which is adequate for the job in hand. The sub-microsecond level performance of higher-cost solutions isn't required for NTP. Anyone wanting a no soldering solution could get the ready adapted GPS 18x LVC, at a somewhat higher price. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f57cc17.3020...@c3energy.com... [] I have an adapter based on the Prolific chipset which is supposed to pass the handshaking signals. It's the Trendnet TU-S9. I'm going to try that, but I'll certainly keep the one you mentioned in mind. If you're lucky, that should work on Windows to get offsets within the 400 microsecond level, and jitter I saw as ~45 microseconds using Windows XP. That is the $ 20,000 question. From our prior discussion, it looks like you're saying the Garmin has a jitter in the start time of the NMEA sentence of about 170 ms. I appear to be observing a similar phenomenon here, but I'm not totally convinced it's real. For the Garmin GPS 18x with 3.70 firmware, it's real. I could see something similar on the 'scope here. Whether other GPSs have similar values I don't know. I think the monitor program may be lying to me about the offsets of the internet servers. If it is real, the variation is very slow, and it takes a day or two to swing from about + 80 ms from NIST to - 80 ms from NIST. I have nothing to explain that 900 ms jump I mentioned. Is this wobble effect something that has been observed with other GPS units? Be aware that servers such as NIST's may well be overloaded. Choose ones with a short network path and, ideally, one with little load. My gut feeling is that until you have PPS, you may get better performance from a selection of Internet servers than a serial-only GPS, [] Are you using that version or later? On Windows, I'm running 4.2.7p259. On Ubuntu Linux, when I boot into it, I'm running the version from the Ubuntu repositories which is about 2 years old. I did a manual upgrade to try to troubleshoot some abrupt jumps in the reported offsets, but that didn't solve the problem. I retrograded back to the one that's in the repositories as doing a manual install breaks several things. It's better to use the package manager. For use with the Sure, I suggest the latest NTP on Linux as well. I had to ask here how to update FreeBSD and, apart from the time taken to recompile everything under the sun, it went well. [] May I suggest using the $GPGGA sentence instead even if it is a little longer? The $GPZDG sentence appears to be the only other one with a valid indicator. I think the satellite lock was good at the time but cannot prove it. It looks to me like the Meinberg monitor is reporting the server offsets wrong. I very much doubt that. I'm presuming it uses the ntpq command internally to get that data but I don't know. Doesn't it read the loopstats files for its graphs, though? I'm currently experimenting with all internet servers noselected to see what happens. I have a variation from my GPS time going from 11 of 12 internet servers within 9.99 ms (single digit before the decimal point) to 4 of 12 internet servers within 9.99 ms. I have not observed any more 950 ms offsets to the internet servers. I just checked while typing this and 8 of 12 internet servers are within 9.99 ms. The 950 ms sounds like the GPS getting the wrong second - slipping sync compared to the clock. [] It doesn't look like GPGGA has any validation in it. The Fix Quality field. 0 = Invalid, 1 = GPS fix, 2 = DGPS fix. I would hope that NTP rejects any data with 0 in this field, but I don't read the sources at all well. I am reluctant to switch to another sentence for a few reasons, assuming NMEA only is ultimately usable at all for a few reasons: Noted, and I see your reasons, but using only $GPZDA concerns me as it lacks any validity check. [] This is the part of my ntp.conf file in windows related to stats. Do I need to add anything else? I think all the stats are already on in Linux. enable stats statsdir C:\NTP Service\NTP\etc\ statistics loopstats Thanks for the help. Sincerely, Ron You may want to add peerstats: statistics loopstats peerstats so that you can look at the 5th column of the results, and read the offset for each clock. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] got the Sure GPS on order, how do I program it
unruh wrote: On 2012-03-07, Terje Mathisenterje.mathisen at tmsw.no wrote: unruh wrote: While it is true that the device does work out of the box, one might want to change things, and for that a manual is crucial. Helpful, certainly, but not crucial. You can just the program kindly provided by one of the helpful, regular posters here, Terje Mathisen. Play! Have fun! Enjoy discovering the device! Trying to figure out the exact format of commands to send to accomplish something is not play. It is an exercise in futility. commands have very very specific syntax, and discovering that syntax and what any particular command does by trial and error is hopeless. Which is exactly why my program will list all valid commands if you run it with a /? parameter: I presume (.exe) that this is a windows program. Not too useful for those that use Linux or BSD unfortunately, or have you ported it? The source code is included, I have tried to keep the windows-specific stuff extremely limited, but I haven't actually done the #ifdef WINDOWS #else #endif stuff needed to support unix/linux directly. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
On Thu, Mar 8, 2012 at 08:17, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Dave, perhaps you could clarify one thing on Windows about the user-mode PPS timestamping. When you say serial I/O layer, my understanding is that this /would/ include virtual COM port devices such as RS-232/USB adapters. Correct. Perhaps the Linux port could also benefit from a user-mode DCD timestamp, or is there not the justification for the effort? It's an ugly hack, and one that fortunately will be migrating out of the ntpd Windows port serial I/O code and into its own PPSAPI provider DLL, thanks to a suggestion by Juergen Perlinger which I should have considered myself. There's no provision to enable or disable it currently, for example. By putting it in an optional DLL, only those who want end-of-line timestamps replaced with PPS timestamps taken in user mode would get them. It's particularly confusing for drivers that have different fudge factors for PPS and serial, as NMEA does, and putting it in a PPSAPI provider DLL will correct that confusion. Apparently no one has had the right mix of idea and motivation to modify the POSIX ntpd serial I/O code to watch for DCD transitions to accomplish similar. It's not hard to find proper PPS support in free OSes. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
Dave Hart h...@ntp.org wrote in message news:cambsiydtftww+jov8xpsszpfzx9+wwgckvj5c5au5ntjcn0...@mail.gmail.com... On Thu, Mar 8, 2012 at 08:17, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Dave, perhaps you could clarify one thing on Windows about the user-mode PPS timestamping. When you say serial I/O layer, my understanding is that this /would/ include virtual COM port devices such as RS-232/USB adapters. Correct. Thanks. Perhaps the Linux port could also benefit from a user-mode DCD timestamp, or is there not the justification for the effort? It's an ugly hack, and one that fortunately will be migrating out of the ntpd Windows port serial I/O code and into its own PPSAPI provider DLL, thanks to a suggestion by Juergen Perlinger which I should have considered myself. There's no provision to enable or disable it currently, for example. By putting it in an optional DLL, only those who want end-of-line timestamps replaced with PPS timestamps taken in user mode would get them. It's particularly confusing for drivers that have different fudge factors for PPS and serial, as NMEA does, and putting it in a PPSAPI provider DLL will correct that confusion. Apparently no one has had the right mix of idea and motivation to modify the POSIX ntpd serial I/O code to watch for DCD transitions to accomplish similar. It's not hard to find proper PPS support in free OSes. Cheers, Dave Hart That's good news, Dave, as anything which reduces confusion is welcome. I have a variety of boxes here I can test with should you need, and it will allow me to measure my own GPS devices as well. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
Alby VA wrote: David Does this mean there is something I need to tweek to get my offsets lower? Could the delays from the remote NTP servers be my issue? I don't know if that's the case. I setup my two servers to use the nearest ntp servers that didn't share the same sources. There are tools to assist in the ntp distribution or you can select from the list of public servers at ntp.org. The stratum is usually of no importance. I had several stratum3 servers in my initial selection but the same servers are now stratum2 or stratum1. By nearest, I mean those with shortest delay. I'd remove the sources with highest delay, maybe just by marking as noselect. My own server with gps/pps source gives a couple of blips each morning due to load from cron jobs. The other pcs show variations from load and from temperature. http://www.lordynet.org.uk/mrtg/stats/ntp/ David David: Can I get your mrtg.cfg and perl script for those graph/stats? I think mine are just mislabeled... They can be downloaded from ftp://ftp0.lordynet.org.uk/pub/os/NetBSD/mrtg_ntp.tbz David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
Ron Frazier (NTP) wrote: On 3/7/2012 11:59 AM, David Lord wrote: Alby VA wrote: On Mar 7, 10:59 am, David Lord sn...@lordynet.org wrote: Alby VA wrote: I'm looking to get a little feedback on if the following output of my Sure GPS / FreeBSD setup looks like its running smoothly and keeping time correctly. assID=0 status=0115 leap_none, sync_atomic, 1 event, event_clock_reset, version=ntpd 4.2@1.2349-o Mon Feb 20 22:00:33 UTC 2012 (1), processor=amd64, system=FreeBSD/9.0-RELEASE, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.269, refid=PPS, reftime=d301d22f.dc1393c2 Wed, Mar 7 2012 7:25:19.859, clock=d301d230.cc08bad9 Wed, Mar 7 2012 7:25:20.797, peer=41909, tc=4, mintc=3, offset=-0.034, frequency=-25.214, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001 Here are my website graphs/stats I've been keeping since day 1. NTP Clock Offset:http://godzilla.empire.org:/ NTP Offset from UTC:http://godzilla.empire.org:/godzilla_ntp-b.html Could you also post output from ntpq -p I don't have a pc with recent FreeBSD but the desktop I updated to NetBSD-6 only 2 hours ago gives: remoterefidst t poll reach delay offset jitter +ntp1.lordynet.org81.187.61.74 2 u 512 377 0.450 -4.961 3.024 *ntp0.lordynet.org.uk .MSFa.1 u 512 377 0.642 -0.828 4.785 +local pc .PPSb.1 u 512 377 1.572 -1.935 3.187 -local pc2 81.187.61.74 2 u 512 377 1.553 -6.075 3.892 Does the Sure have a PPS output you can use? Local pc is using a Sure with PPS # ntpq -c rv -p me6000 associd=0 status=0119 leap_none, sync_pps, 1 event, leap_armed, version=ntpd 4.2.6p5, processor=i386, system=NetBSD/5.1_STABLE, . offset=-0.001 sys_jitter=0.004 David Here is my ntpq -p output: [a...@godzilla.empire.org(tcsh):6] ntpq -p remote refid st t when poll reach delay offset jitter == -ntp.alaska.edu .GPS.1 u 133 128 377 120.428 -2.464 0.371 +utcnist2.colora .ACTS. 1 u 53 128 377 66.362 -4.215 0.429 -time-a.nist.gov .ACTS. 1 u 670 128 240 16.473 2.627 17.066 +tick.usask.ca .GPS.1 u 110 128 377 104.848 -3.473 1.482 -cronos.cenam.mx .GPS.1 u 49 128 377 100.163 10.784 27.096 oPPS(0) .PPS.0 l6 16 3770.000 -0.018 0.002 *GPS_NMEA(0) .GPSb. 0 l9 16 3770.000 -36.164 18.050 [a...@godzilla.empire.org(tcsh):7] Sorry I misread your message and had in my mind that you were getting msec offsets rather than usec. I canceled my reply after posting. The offsets still look to be high for what can be achieved from pps but are not reflected in the jitter. David Correct me if I'm wrong, but, doesn't that last line mean 36 ms of offset with 18 ms of jitter? Yes that is the offset from the NMEA. The NMEA in this case is only used to obtain the second value of the clock. PPS on the line above is used to condition the system clock which at that poll had offset of -0.018 ms and jitter of 0.002 ms. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
On 3/8/2012 6:54 AM, David Lord wrote: Ron Frazier (NTP) wrote: On 3/7/2012 11:59 AM, David Lord wrote: Alby VA wrote: On Mar 7, 10:59 am, David Lord sn...@lordynet.org wrote: Alby VA wrote: I'm looking to get a little feedback on if the following output of my Sure GPS / FreeBSD setup looks like its running smoothly and keeping time correctly. assID=0 status=0115 leap_none, sync_atomic, 1 event, event_clock_reset, version=ntpd 4.2@1.2349-o Mon Feb 20 22:00:33 UTC 2012 (1), processor=amd64, system=FreeBSD/9.0-RELEASE, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.269, refid=PPS, reftime=d301d22f.dc1393c2 Wed, Mar 7 2012 7:25:19.859, clock=d301d230.cc08bad9 Wed, Mar 7 2012 7:25:20.797, peer=41909, tc=4, mintc=3, offset=-0.034, frequency=-25.214, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001 Here are my website graphs/stats I've been keeping since day 1. NTP Clock Offset:http://godzilla.empire.org:/ NTP Offset from UTC:http://godzilla.empire.org:/godzilla_ntp-b.html Could you also post output from ntpq -p I don't have a pc with recent FreeBSD but the desktop I updated to NetBSD-6 only 2 hours ago gives: remoterefidst t poll reach delay offset jitter +ntp1.lordynet.org81.187.61.74 2 u 512 377 0.450 -4.961 3.024 *ntp0.lordynet.org.uk .MSFa.1 u 512 377 0.642 -0.828 4.785 +local pc .PPSb.1 u 512 377 1.572 -1.935 3.187 -local pc2 81.187.61.74 2 u 512 377 1.553 -6.075 3.892 Does the Sure have a PPS output you can use? Local pc is using a Sure with PPS # ntpq -c rv -p me6000 associd=0 status=0119 leap_none, sync_pps, 1 event, leap_armed, version=ntpd 4.2.6p5, processor=i386, system=NetBSD/5.1_STABLE, . offset=-0.001 sys_jitter=0.004 David Here is my ntpq -p output: [a...@godzilla.empire.org(tcsh):6] ntpq -p remote refid st t when poll reach delay offset jitter == -ntp.alaska.edu .GPS.1 u 133 128 377 120.428 -2.464 0.371 +utcnist2.colora .ACTS. 1 u 53 128 377 66.362 -4.215 0.429 -time-a.nist.gov .ACTS. 1 u 670 128 240 16.473 2.627 17.066 +tick.usask.ca .GPS.1 u 110 128 377 104.848 -3.473 1.482 -cronos.cenam.mx .GPS.1 u 49 128 377 100.163 10.784 27.096 oPPS(0) .PPS.0 l6 16 3770.000 -0.018 0.002 *GPS_NMEA(0) .GPSb. 0 l9 16 3770.000 -36.164 18.050 [a...@godzilla.empire.org(tcsh):7] Sorry I misread your message and had in my mind that you were getting msec offsets rather than usec. I canceled my reply after posting. The offsets still look to be high for what can be achieved from pps but are not reflected in the jitter. David Correct me if I'm wrong, but, doesn't that last line mean 36 ms of offset with 18 ms of jitter? Yes that is the offset from the NMEA. The NMEA in this case is only used to obtain the second value of the clock. PPS on the line above is used to condition the system clock which at that poll had offset of -0.018 ms and jitter of 0.002 ms. David OK. Now I get it. Thanks. Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
Ron Frazier (NTP) wrote: On 3/7/2012 7:10 PM, David Lord wrote: Ron Frazier (NTP) wrote: I'm a little confused. Are you currently getting offsets in the 10's of milliseconds range or in the 10's of microseconds range. Also, how are you measuring offset from UTC, as opposed to offset from the GPS board? Sincerely, Ron On 3/7/2012 7:26 AM, Alby VA wrote: I'm looking to get a little feedback on if the following output of my Sure GPS / FreeBSD setup looks like its running smoothly and keeping time correctly. assID=0 status=0115 leap_none, sync_atomic, 1 event, event_clock_reset, version=ntpd 4.2.6p5@1.2349-o Mon Feb 20 22:00:33 UTC 2012 (1), processor=amd64, system=FreeBSD/9.0-RELEASE, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.269, refid=PPS, reftime=d301d22f.dc1393c2 Wed, Mar 7 2012 7:25:19.859, clock=d301d230.cc08bad9 Wed, Mar 7 2012 7:25:20.797, peer=41909, tc=4, mintc=3, offset=-0.034, frequency=-25.214, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001 From above the offset is -0.034 msec, ie 34 usec David At first I was confused and thought he was ms off. However, if he's within 34 us, that's pretty good. Sounds like his board is working OK, but could possibly be a bit better. If he were communicating exclusively on the serial port and the PPS were not working, would he be getting performance this good? My system with Sure GPS and PPS : identmeanrmsmax 127.127.22.20.000 0.004 0.030 The 30 usec offsets are during the morning at time the system logs are created and rotated. I'll try to insulate the xtal when I next have to move the pc but I don't know that the blips in offset are caused by increase in temperature. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] what does meinberg graph of peerstats file mean
I just recently turned on peerstats collection. Then, I went to the Meinburg server monitor statistics screen and graphed the peerstats file. However, I don't know what the graph means. What does a graph of offset and frequency mean when the source is a peerstats file, particularly if there are multiple internet servers involved. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failed to test leapsecond's handling
On Thu, Mar 08, 2012 at 01:10:02PM +0100, Marco Marongiu wrote: But when I graph the time log (see the log target in the makefile), I don't see the leap second kicking in. Based on Mills' The NTP Timescale and Leap Seconds[1], when the leap second kicks in, I'd expect two consecutive date command to _appear_ happen at different offset than in normal conditions. Unfortunately, that didn't happen, and if I draw a line of the accumulated offsets between consecutive runs of the command, the line is almost perfectly straight. Do you see the leap bit enabled in ntptime or adjtimex output? Is the local timezone UTC? Just to make sure the date commands sets time to before 0:00 UTC and not some other hour. It would be interesting to also try disable kernel in the ntp.conf. In a clknetsim simulation with ntp-4.2.6p5 I can see the clock is correctly stepped by 1.0 second. Here is the ntpd log (in UTC+2 timezone): http://pastebin.com/ZRi6qv8E -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failed to test leapsecond's handling
On Thu, Mar 08, 2012 at 02:28:07PM +0100, Miroslav Lichvar wrote: In a clknetsim simulation with ntp-4.2.6p5 I can see the clock is correctly stepped by 1.0 second. Here is the ntpd log (in UTC+2 timezone): http://pastebin.com/ZRi6qv8E In another simulation set to start 15 seconds before midnight it didn't work and it seems ntpd needs to be started sooner, perhaps some number of polling intervals? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
My system with Sure GPS and PPS : identmeanrmsmax 127.127.22.20.000 0.004 0.030 The 30 usec offsets are during the morning at time the system logs are created and rotated. I'll try to insulate the xtal when I next have to move the pc but I don't know that the blips in offset are caused by increase in temperature. David My offset excursions are almost certainly temperature-related: http://www.satsignal.eu/mrtg/performance_pixie.php happening at the time when the central heating comes on! The are no regular tasks run on that PC. On my Windows PCs, I use SpeedFan to monitor various temperatures (disk, CPU). I also have some very cheap external temperature probes which work over USB for external temperature and humidity: http://www.satsignal.eu/mrtg/performance_disk_temp.php http://www.satsignal.eu/mrtg/performance_air_temp.php Sensors: http://www.pcsensor.com/index.php Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
Ron Frazier (NTP) wrote: Based on the aforementioned web page, it looks like the possible validity fields are as follows: GPRMC sentence - POS_STAT GPGLL sentence - POS_STAT GPGGA sentence - FIX_MODE GPZDA sentence - none, as you observed GPZDG sentence - V or maybe signal strength I don't know if my GPS will do GPZDG. Otherwise I might try it. It may be proprietary to some GPS's. We still don't know if NTPD recognizes any of these fields, or if the behavior is different in Windows and Linux. If it does, I might switch back to another sentence. However, I already know it will increase my NMEA jitter. If I can get PPS working, that won't matter as much. That's not an option with the BU-353 though. [] This is the part of my ntp.conf file in windows related to stats. Do I need to add anything else? I think all the stats are already on in Linux. enable stats statsdir C:\NTP Service\NTP\etc\ statistics loopstats Thanks for the help. Sincerely, Ron You may want to add peerstats: statistics loopstats peerstats so that you can look at the 5th column of the results, and read the offset for each clock. Cheers, David Peerstats is now on. Not totally sure what to do with it, but it's there. There are scripts in the distribution to produce summary files from the stats files: eg. peer_summary: peerstats.20120126 ident cnt mean rms max delay dist disp == 192.168.59.673150.7380.5371.1940.5936.5253.033 127.127.20.21350 -64.665 14.597 60.0750.0002.3691.781 127.127.22.21350 -0.0000.0040.0360.0000.9280.928 192.168.59.222870.5950.3451.0330.5885.3022.462 81.187.61.69 1611.4990.7291.5410.770 11.6595.202 192.168.59.242 2730.7860.7531.8871.1887.1132.734 81.187.61.74 1471.1960.6051.4371.025 12.3345.765 192.168.59.210 2690.9230.8662.0791.1906.3752.953 eg. loop_summary: loopstats.20110922 loop 1350, 6+/-41.5, rms 5.9, freq -35.51+/-0.639, var 0.227 loopstats.20110923 loop 1350, 6+/-27.4, rms 3.2, freq -35.79+/-0.157, var 0.090 loopstats.20110924 loop 1350, 8+/-24.8, rms 3.7, freq -35.76+/-0.171, var 0.067 loopstats.20110925 loop 1350, 9+/-28.2, rms 5.6, freq -35.31+/-0.555, var 0.191 David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] got the Sure GPS on order, how do I program it
On 2012-03-08, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Chris Albertson albertson.ch...@gmail.com wrote in message news:CABbxVHuTF=J_oCmDFfVM- [] It _is_ fair to blame Sure Electronic. They selected the chip. If they selected one with poor documentation it's them who did that. They could have picked some other chip with better docs. If you want an evaluation board for a different chip, surely you would buy a different board? That is one reason I like the Motorola brand and the Trimble brand or even Rockwell GPSes. They have first rate docs written in the USA by real technical writers speak English as their native language. (Actually I'd buy the Sure stuff if it saved me a ton of money or worked better.) For NTP, Chris, what aspect of performance is inadequate? But on the other hand, the Sure GPS works well enough if you can build a custom serial/PPS cable and then just turn it on. You don't need to know how it works if you are using it only for NTP. Chris Albertson Redondo Beach, California No special cable needed, just one or two extra links on the board. I see it as a very low-cost solution which is adequate for the job in hand. The sub-microsecond level performance of higher-cost solutions isn't required for NTP. Anyone wanting a no soldering solution could get the ready adapted GPS 18x LVC, at a somewhat higher price. It also requires soldering-- of the output lines which are bare, to something, and something to provide power to the system. Ie, much more work(soldering) is required for the 18x than for the Sure board. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
On 2012-03-08, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: On 3/7/2012 7:10 PM, David Lord wrote: Ron Frazier (NTP) wrote: I'm a little confused. Are you currently getting offsets in the 10's of milliseconds range or in the 10's of microseconds range. Also, how are you measuring offset from UTC, as opposed to offset from the GPS board? Sincerely, Ron On 3/7/2012 7:26 AM, Alby VA wrote: I'm looking to get a little feedback on if the following output of my Sure GPS / FreeBSD setup looks like its running smoothly and keeping time correctly. assID=0 status=0115 leap_none, sync_atomic, 1 event, event_clock_reset, version=ntpd 4.2.6p5@1.2349-o Mon Feb 20 22:00:33 UTC 2012 (1), processor=amd64, system=FreeBSD/9.0-RELEASE, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.269, refid=PPS, reftime=d301d22f.dc1393c2 Wed, Mar 7 2012 7:25:19.859, clock=d301d230.cc08bad9 Wed, Mar 7 2012 7:25:20.797, peer=41909, tc=4, mintc=3, offset=-0.034, frequency=-25.214, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001 From above the offset is -0.034 msec, ie 34 usec David At first I was confused and thought he was ms off. However, if he's within 34 us, that's pretty good. Sounds like his board is working OK, but could possibly be a bit better. If he were communicating exclusively on the serial port and the PPS were not working, would he be PPS on a linux machine will give offsets of around 5us (standard deviation around 3) with occasional larger excursions. With a local network connection to a stratum 1 server, you will get around 20us fluctuations in the offset. getting performance this good? Even though it's not as critical with PPS, I thought I'd pass a long a couple of tips to making the serial NMEA connection perform as good a possible. My advice to stabilize the NMEA data as much as possible, do the following: A) maximize the baud rate, as long as it doesn't destabilize the system. B) minimize the number of NMEA sentences, to preferably one. C) make that NMEA sentence one that doesn't vary much, if at all, in length, like GPZDA or maybe GPZDG. I don't know much about GPZDG. However, the manual for the Trimble Resolution T recommends GPZDA for timekeeping. D) Set ntp.conf to read only the desired sentence. Here's something else that could be affecting his results, or possibly, I could be all wet. It occurred to me that BSD (which I know nothing about, but am assuming it's a linux like system) might be automatically loading the virtual com port driver for the USB connection, like Ubuntu did when I plugged in the USB GPS that I have, which is a Globalsat BU-353. So, my thought was, if it were trying to communicate both by USB and serial, that it might be causing a problem. Or, it could be totally unrelated. But, I just thought I'd throw it out there. Sincerely, Ron Here are my website graphs/stats I've been keeping since day 1. NTP Clock Offset: http://godzilla.empire.org:/ NTP Offset from UTC: http://godzilla.empire.org:/godzilla_ntp-b.html ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58b4fc.4060...@c3energy.com... [] On the Status tab, that's where it displays all the offsets, similar to the ntpq -p command. I don't know how it gets this data. On the Statistics screen, if you select the directory where your statistics files are, you can graph either loopstats or peerstats files. I think clockstats is the third type. I don't know if there is anything to graph in that or not. No, I've not played with those fields in that program. I wrote my own loopstats analyser. The Fix Quality field. 0 = Invalid, 1 = GPS fix, 2 = DGPS fix. I would hope that NTP rejects any data with 0 in this field, but I don't read the sources at all well. OK. I see your point. They call that FIX_MODE on this page which you mentioned before. http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html I didn't see that field before. There are lots of things I can't even find, let alone see them! G [] Based on the aforementioned web page, it looks like the possible validity fields are as follows: GPRMC sentence - POS_STAT GPGLL sentence - POS_STAT GPGGA sentence - FIX_MODE GPZDA sentence - none, as you observed GPZDG sentence - V or maybe signal strength I don't know if my GPS will do GPZDG. Otherwise I might try it. It may be proprietary to some GPS's. We still don't know if NTPD recognizes any of these fields, or if the behavior is different in Windows and Linux. If it does, I might switch back to another sentence. However, I already know it will increase my NMEA jitter. If I can get PPS working, that won't matter as much. That's not an option with the BU-353 though. Take a look at the source, refclock_nmea.c, around line 868 in the copy I have. It does checks on $GPZDG, $GPMRC, $GPGGA and $GPGLL, but what it does with the checks I can't easily follow. [] Peerstats is now on. Not totally sure what to do with it, but it's there. Sincerely, Ron David Lord answered this, I wrote a small Windows program for my own purposes. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Popcorn on prefer takes out system clock
On 2012-03-08, A C agcarver+...@acarver.net wrote: On 3/7/2012 15:38, unruh wrote: On 2012-03-07, A Cagcarver+...@acarver.net wrote: On 3/6/2012 20:34, Dave Hart wrote: On Wed, Mar 7, 2012 at 01:32,Null@blacklist.anitech-systems.invalid wrote: Dave Hart wrote: A Cagcarver+...@acarver.net wrote: 130.207.165.28 944d 8d popcorn 2147483647.997598 s I assume you mean in the local ntpd log on your sparc box referring to the IP address that used to be marked prefer. I realize not everyone is a programmer, but the number above jumped out at me as suspiciously round in hex and binary. Sure enough, round it to whole seconds and you have 2^31 or 0x8000. Incredible coincidence? -0.002402 ? Nope. NTP's 32:32 l_fp is used for both unsigned timestamps and signed differences between timestamps (intervals or offsets). In both cases the fractional part is unsigned and positive. For offsets, the integer part is signed, so -0.002402 would be -1 seconds plus 0.997598, or in hex 0x.0xf... In this case we have an unambiguously positive value 0x7fff.0xf... or just over +68 years. Interestingly the same remote server just popcorned again but this time the number was still huge though less than a full overflow: 130.207.165.28 901d 8d popcorn 202238.338413 s Is it delivering a KOD packet? What is that server running? Do you have peers enabled and can you look at the output of the peers file when that weird measurement comes in? It would be nice if one could see all four times in the ntp packet for that situation, to see if it is your machine or the remote machine that is putting in absurd times into the packet (or if ntpd is misinterpreting something and causing the problem itself.) Unfortunately I do not think that there is any debug flag that can tell ntpd to report all four of those times on a bad packet. (I suppose you could hack the source to have it do that) The peer records for that particular server. Five polls prior to the major event (the popcorn 2147483647.997598 s), the event itself, and five polls after: Well, I am confused. (It would really really be nice if ntp inserted an explanation for the peerstats output into the file, instead of having to root about in the source code). The peerstats file seems to be fprintf(peerstats.fp, %lu %s %s %x %.9f %.9f %.9f %.9f\n, day, ulfptoa(now, 3), stoa(addr), status, offset, delay, dispersion, skew); which would indicate that the there is nothing surprizing that is happening to the measured offsets during that time, but the dispersion goes crazy, for no reason that I can see. 55992 28127.756 130.207.165.28 9014 -0.170051294 0.078942366 7.937562104 0.000122070 55992 28129.677 130.207.165.28 9014 -0.179983358 0.077845506 3.937600648 0.009932064 55992 28133.799 130.207.165.28 9014 -0.199691829 0.077621280 0.937640806 0.021355778 55992 28408.122 130.207.165.28 9024 -0.006291682 0.078885845 7.937562104 0.000122070 55992 28409.830 130.207.165.28 9024 -0.016024622 0.078550234 3.937600653 0.009732940 55992 28411.834 130.207.165.28 9024 -0.026350192 0.077996043 9225.801161582 0.015952448 55992 28413.833 130.207.165.28 9024 -0.036352381 0.078129313 0.937637060 0.021732520 55992 28415.829 130.207.165.28 963a -0.041918036 0.077468683 0.437644685 0.023521481 55992 28417.863 130.207.165.28 963a -0.041216188 0.077486681 0.187648967 0.020491380 55992 28476.861 130.207.165.28 943a -0.011773862 0.078609389 0.063072171 0.020977043 55992 28542.857 130.207.165.28 943a 0.000470710 0.079669255 0.000839328 0.029465863 This is for the later event of 202238.338413 s popcorn 55993 28733.851 130.207.165.28 944d 0.001442344 0.077783855 0.003718608 0.000174640 55993 29065.885 130.207.165.28 904d 0.001781094 0.077855594 0.004514781 0.000271580 55993 29263.848 130.207.165.28 944d 0.001515211 0.077869762 0.004768669 0.000225611 55993 29397.858 130.207.165.28 944d 0.001499231 0.077956490 0.005274452 0.000200836 55993 29525.860 130.207.165.28 944d 0.001522830 0.077973892 0.003356092 0.000185364 55993 29781.861 130.207.165.28 944d 202238.340010876 0.077839850 1.518925725 202238.338406371 55993 30374.867 130.207.165.28 941d 0.001488131 0.078009916 0.005926894 0.000356562 55993 30439.861 130.207.165.28 941d 0.001620819 0.078177454 0.002953087 0.000259219 55993 30568.902 130.207.165.28 941d 0.001570695 0.077985387 0.001762402 0.000288896 55993 30766.859 130.207.165.28 941d 0.001727346 0.077951527 0.001585799 0.000266961 55993 30897.850 130.207.165.28 941d 0.001619869 0.077850728 0.001662438 0.000143900 I happened to notice the time of day is close for each event, the events are almost 24 hours apart. I'll see what happens later tonight (the clock only shows 22120 seconds right now) ___
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
Hi David, I would look at the file, but I'm running Windows at the moment, and I can't figure out how to extract a .tar.gz file from here. Can you email me the C file? I have about 15 things going on with the PC right now and I don't want to reboot into Linux. I could possibly do that later if I need to. Sincerely, Ron On 3/8/2012 10:50 AM, David J Taylor wrote: Take a look at the source, refclock_nmea.c, around line 868 in the copy I have. It does checks on $GPZDG, $GPMRC, $GPGGA and $GPGLL, but what it does with the checks I can't easily follow. -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58dfb2.3060...@c3energy.com... Hi David, I would look at the file, but I'm running Windows at the moment, and I can't figure out how to extract a .tar.gz file from here. Can you email me the C file? I have about 15 things going on with the PC right now and I don't want to reboot into Linux. I could possibly do that later if I need to. Sincerely, Ron Will do. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what does meinberg graph of peerstats file mean
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58adc8.2000...@c3energy.com... I just recently turned on peerstats collection. Then, I went to the Meinburg server monitor statistics screen and graphed the peerstats file. However, I don't know what the graph means. What does a graph of offset and frequency mean when the source is a peerstats file, particularly if there are multiple internet servers involved. Sincerely, Ron Looking at the drop-down list in the Meinberg NTP Time Server Monitor, I see only Loopstats mentioned (in addition to *.*). This suggests to me that only loopstats files can be analysed. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what does meinberg graph of peerstats file mean
On 3/8/2012 12:06 PM, David J Taylor wrote: Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58adc8.2000...@c3energy.com... I just recently turned on peerstats collection. Then, I went to the Meinburg server monitor statistics screen and graphed the peerstats file. However, I don't know what the graph means. What does a graph of offset and frequency mean when the source is a peerstats file, particularly if there are multiple internet servers involved. Sincerely, Ron Looking at the drop-down list in the Meinberg NTP Time Server Monitor, I see only Loopstats mentioned (in addition to *.*). This suggests to me that only loopstats files can be analysed. Cheers, David Double click on a peerstats file that's in the same directory. It will produce a graph. I'm just not totally sure what it means. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
On 3/8/2012 11:58 AM, David J Taylor wrote: Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58dfb2.3060...@c3energy.com... Hi David, I would look at the file, but I'm running Windows at the moment, and I can't figure out how to extract a .tar.gz file from here. Can you email me the C file? I have about 15 things going on with the PC right now and I don't want to reboot into Linux. I could possibly do that later if I need to. Sincerely, Ron Will do. Cheers, David Thanks David. I got the C file and looked at it. I can see what you mean. They are doing validity checks on GPRMC, GPGLL, GPGGA, and GPZDG, but not GPZDA. I'm not very knowledgeable on C, but can usually read the basic meaning of code. This is a bit harder to figure out than I thought. I may have to spend more time later on it. I don't know what they're doing with the validity check, but I presume a failure would force the system to seek another clock, if one is available. I'm going back to GPGGA for testing. I'm pretty sure this will increase the jitter in the NMEA stream. So, that presents me with an interesting dilemma. Have low jitter data with no validity check when GPS is working, or higher jitter data with a validity check in case GPS fails. Interesting paradox. I cannot figure out how to make this GPS output GPZDG. Psychologically speaking, with this particular equipment, being under + / - 10 ms sounds really cool. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what does meinberg graph of peerstats file mean
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58eec2.2070...@c3energy.com... [] Double click on a peerstats file that's in the same directory. It will produce a graph. I'm just not totally sure what it means. Sincerely, Ron It means nothing. The program deals with loopstats data, as I suggested. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what does meinberg graph of peerstats file mean
On 3/8/2012 1:42 PM, David J Taylor wrote: Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58eec2.2070...@c3energy.com... [] Double click on a peerstats file that's in the same directory. It will produce a graph. I'm just not totally sure what it means. Sincerely, Ron It means nothing. The program deals with loopstats data, as I suggested. Cheers, David I wouldn't say it means nothing. It appears to be going through every line in the log file and graphing the offset from each server from my system clock as time goes by. That could have some value. It lets me know how far out I am from the internet servers over time. Many lines in the peerstats file represent my GPS, so deviations away from that baseline are what the internet servers are doing relative to me. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Peer Review of ntpq -c rv
Ron Frazier (NTP) wrote: It occurred to me that BSD (which I know nothing about, but am assuming it's a linux like system) Its the other way around, Linux is Unix-like; Unix in general predates Linux but something like 22 years; BSD predates Linux, by something like 14 years. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what does meinberg graph of peerstats file mean
On 3/8/2012 2:39 PM, Ron Frazier (NTP) wrote: On 3/8/2012 1:42 PM, David J Taylor wrote: Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f58eec2.2070...@c3energy.com... [] Double click on a peerstats file that's in the same directory. It will produce a graph. I'm just not totally sure what it means. Sincerely, Ron It means nothing. The program deals with loopstats data, as I suggested. Cheers, David I wouldn't say it means nothing. It appears to be going through every line in the log file and graphing the offset from each server from my system clock as time goes by. That could have some value. It lets me know how far out I am from the internet servers over time. Many lines in the peerstats file represent my GPS, so deviations away from that baseline are what the internet servers are doing relative to me. Sincerely, Ron I have confirmed experimentally by modifying the contents of the peerstats file, that if you feed a peerstats file to the Meinburg time server monitor statistics graphing screen, you get the following. This page defines the statistics files. http://www.eecis.udel.edu/~mills/ntp/html/monopt.html The RED graph, which is normally clock offset, is still clock offset. In the peerstats file, it comes from column 5. The BLUE graph, which is normally frequency, becomes round trip delay. In the peerstats file, it comes from column 6. I still haven't figured totally what to do with it, but you could use some batch commands like this to manipulate the file. This command will remove all references to my local clock and put what's left in peerstats.remote. Feed this file to Meinburg to graph the offsets of every remote server, all together, over time. type peerstats.20120308 | find /v 127.127.20.5 peerstats.remote This command will extract all references to a specific server and put those lines in peerstats.specific. Feed this file to Meinburg to graph the offsets of this remote server over time. type peerstats.20120308 | find 207.200.81.113 peerstats.specific This command will extract all references to the local gps clock and put those in peerstats.gps. Feed this file to Meinburg to graph the offsets of the local clock. Graphing loopstats will do the same thing if that was always the selected clock. type peerstats.20120308 | find 127.127.20.5 peerstats.gps Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what does meinberg graph of peerstats file mean
I wouldn't say it means nothing. It appears to be going through every line in the log file and graphing the offset from each server from my system clock as time goes by. That could have some value. It lets me know how far out I am from the internet servers over time. Many lines in the peerstats file represent my GPS, so deviations away from that baseline are what the internet servers are doing relative to me. Sincerely, Ron If it help you, Ron, that's great. All I'm saying is that it appears to me that the program was only designed to analyse loopstats. For peerstats, you would want a peer selection mechanism. You may find it helpful to load the peerstats into Excel and play with it there. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ESR looking for good GPS clocks
On Mon, 05 Mar 2012 20:18:31 +, unruh wrote: The problem is that parallel ports are far rarer than serial ports these days, and even rarer than usb ports. And you would then have to get the output of that counter into the computer. A bit more than $100 for the whole thing I suspect. Here's an outline of how this can be easily done for far less than $100 of hardware: any parallel output for which a suitable driver exists can be used. Most general-purpose computers have more than one of these (e.g. LED drivers, IR drivers, as well as serial and/or parallel ports). At some time, the computer takes a timestamp, sets an output port line to a specific state and takes another timestamp. The two timestamps bracket the setting of the output (the output state can be reset at some later non-critical time). A simple microcontroller such as a Microchip dsPIC series device does the rest, viz. measure the time interval between the aforementioned computer output pin and the GPS PPS timing reference edge, read and echo NMEA messages from the GPS serial data, and convert the measured time interval into an NMEA sentence which is inserted into the serial output along with echoed GPS NMEA sentences. The computer reads the NMEA data (USB is fine as timing of the serial data is not critical); the measured time interval is encoded in the NMEA data and the computer has before and after timestamps bracketing the output port state transition, from which the local clock timing offset to GPS PPS timing reference is easily computed. Echoed GPS NMEA sentences provide the date and time. Microcontroller and support components, I/O signal conditioning, serial line transceivers, etc. total cost is likely to be well under $100 even in small quantities. Microcontroller requirements are modest; a reasonable timer, serial I/O, and enough memory for a fairly simple program. Of course, there are many boards suitable for use as a router (e.g. Soekris products) that not only have parallel I/O but also can use the on- board CPU for timing, eliminating the need for a microcontroller. And interfacing GPS timing receivers to a Soekris board has already been done (Google can point you to some examples). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] SIRF time output wobble, GPS or NTP fault?
On 3/8/2012 9:51 AM, David Lord wrote: Ron Frazier (NTP) wrote: Based on the aforementioned web page, it looks like the possible validity fields are as follows: GPRMC sentence - POS_STAT GPGLL sentence - POS_STAT GPGGA sentence - FIX_MODE GPZDA sentence - none, as you observed GPZDG sentence - V or maybe signal strength I don't know if my GPS will do GPZDG. Otherwise I might try it. It may be proprietary to some GPS's. We still don't know if NTPD recognizes any of these fields, or if the behavior is different in Windows and Linux. If it does, I might switch back to another sentence. However, I already know it will increase my NMEA jitter. If I can get PPS working, that won't matter as much. That's not an option with the BU-353 though. [] This is the part of my ntp.conf file in windows related to stats. Do I need to add anything else? I think all the stats are already on in Linux. enable stats statsdir C:\NTP Service\NTP\etc\ statistics loopstats Thanks for the help. Sincerely, Ron You may want to add peerstats: statistics loopstats peerstats so that you can look at the 5th column of the results, and read the offset for each clock. Cheers, David Peerstats is now on. Not totally sure what to do with it, but it's there. There are scripts in the distribution to produce summary files from the stats files: eg. peer_summary: peerstats.20120126 ident cnt mean rms max delay dist disp == 192.168.59.673150.7380.5371.1940.5936.525 3.033 127.127.20.21350 -64.665 14.597 60.0750.0002.369 1.781 127.127.22.21350 -0.0000.0040.0360.0000.928 0.928 192.168.59.222870.5950.3451.0330.5885.302 2.462 81.187.61.69 1611.4990.7291.5410.770 11.659 5.202 192.168.59.242 2730.7860.7531.8871.1887.113 2.734 81.187.61.74 1471.1960.6051.4371.025 12.334 5.765 192.168.59.210 2690.9230.8662.0791.1906.375 2.953 eg. loop_summary: loopstats.20110922 loop 1350, 6+/-41.5, rms 5.9, freq -35.51+/-0.639, var 0.227 loopstats.20110923 loop 1350, 6+/-27.4, rms 3.2, freq -35.79+/-0.157, var 0.090 loopstats.20110924 loop 1350, 8+/-24.8, rms 3.7, freq -35.76+/-0.171, var 0.067 loopstats.20110925 loop 1350, 9+/-28.2, rms 5.6, freq -35.31+/-0.555, var 0.191 David That's pretty cool. I'll have to check them out. Does that work under Windows and Linux, and, where would I find them? Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ESR looking for good GPS clocks
Bruce Lilly wrote: On Mon, 05 Mar 2012 20:18:31 +, unruh wrote: The problem is that parallel ports are far rarer than serial ports these days, and even rarer than usb ports. And you would then have to get the output of that counter into the computer. A bit more than $100 for the whole thing I suspect. Here's an outline of how this can be easily done for far less than $100 of hardware: any parallel output for which a suitable driver exists can The more I look at this, the more I settle down on using Ethernet as the communication channel! Something like the Soekris board reduced to the size of a pack of cards, with a (timing) gps chip on a daughter card, and an Ethernet port for communication. Preferably using a cheap TCXO or more expensive OCXO for local holdover and stability. The TCXO could be synthesized by moving one of the regular temperature monitoring channels to the crystal. (We have seen experiments doing this with the normal cpu hard disk temp monitors, they seemed to give an order of magnitude reduction in temperature-induced excursions.) I.e. the recently posted link to an ntp black box server embedded in an outdoor-proof antenna enclosure, but a couple of orders of magnitude cheaper. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
