Re: [ntp:questions] how do I lock in average frequency correction
Ron Frazier (NTP) wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. On IBM PC hardware it doesn't originate from the 32768 Hz RTC clock crystal. On most it originates from the main system oscillator, but there is no requirement for this, and I half remember that some early PCs used a separate oscillator. All bets are off for other architectures. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
Ron Frazier (NTP) wrote: On 2/13/2012 3:25 PM, Chris Albertson wrote: On Mon, Feb 13, 2012 at 10:59 AM, Chuck Swigercswi...@mac.com wrote: You might be able to improve the stability of the crystal by ensuring good airflow and cooling via HVAC as needed. And I suppose you could adjust the rate by changing the HVAC set-point, but I don't think the benefit is worth it. For temperature stability, I just finished building a fan controller. There is a temperature sensor on the end of a 18 cable. Glue the sensor onto anything you like. Then when the sensor matches a set point the fan comes on.I think this should work as long as you keep the set point above the room temperature. I've not tried it yet. It is simple enough to make. The TMP36 sensor outputs a voltage of 10mV per degree. That goes to one side of an LM311 comparator. The lm311 switches a transistor that drives the fan. It looks like holding the sensor temp to +- 1/2 degree is easy.Holding to only 0.5 C is not hard and might help. Actually this controller is going on a Rubidium oscillator, not an XO. but if it works well I'll build a few more. The idea is about the same is an ovenized XO but slightly more crude. Just aim the fan at the part you want to control and insulate the sensor from airflow. I'll know if this work in a few weeks Chris Albertson Redondo Beach, California Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. My most recent PC is from about 7 years ago. All the systems that I've checked seem to have a 14.31818 MHz crystal. Some of the older systems even have a jumper to use an external source. David Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
Richard B. Gilbert wrote: On 2/13/2012 2:36 AM, Dave Hart wrote: That's OCXO, oven controlled crystal oscillator. Why X for crystal? Crystal is frequently abbreviated as XTAL. I think this usage may have originated in amateur radio. It did. All radio were amateur radio in those days. I.e. my university ham radio club (LA1K, the recipient of the very first ham sat diploma!) were forced to sell their founder stock in The Radio Society when that company was nationalized in orderto serve as the basis for Norwegian Public Radio. Terje/la8nw -- - 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] ntpd wedged again
A C wrote: On 2/13/2012 15:44, David Lord wrote: Recent ntpd is supposed to handle that level of frequency offset but most of my pcs have had the frequency offset adjusted to be 10 ppm which is done when I build a kernel with options PPS_SYNC and options TIMER_FREQ=119. This kernel does have PPS_SYNC enabled but I'm not using it right now since I'm still debugging ntpd/libc. I'll start using it next week after I know ntpd will survive a week straight. How do you determine the timer frequency number? Trial and error? At one time I could find it in the documentation but not when I last did a search. AFAIK it was supposed to be self calibrating so the ability for adjustment might be dropped. Unfortunately the self calibration can be 50ppm out. PC me6000 is using kernel compiled for a different pc: me6000 $ dmesg | grep timecounter timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 me6000 $ cat /var/db/ntp/ntpd.drift -35.834 me6000 $ ntpq -p remote refid st poll reach delay offset jitter *GPS_NMEA(2) .GPSb. 016 377 0.000 -34.509 18.290 oPPS(2) .PPSb. 016 377 0.000 -0.001 0.004 p4x2400b $ dmesg | grep timecounter timecounter: Timecounter i8254 frequency 1193110 Hz quality 100 p4x2400b $ cat /var/db/ntp/ntpd.drift -9.358 p4x2400b $ ntpq -p remote refid st poll reach delay offset jitter *me6000 .PPSb. 164 376 1.5730.559 0.517 +ntp0 .MSFa. 1 1024 375 1.8111.905 2.614 David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] lots of GPS modules and info at SparkFun
Figure I might chime in with the gps unit I got and if your in Aust i think its probably about the best deals i've seen that has a pps line (theres also another one they have if you can do smd soldering thats cheaper again). http://www.twig.com.au/store/product_info.php?products_id=108osCsid=148a3e8759d5ae6b8ab6f3f0489e0fd4 http://www.twig.com.au/store/product_info.php?products_id=108osCsid=148a3e8759d5ae6b8ab6f3f0489e0fd4 I was looking to put together the dirt-cheapest ntpd machine with pps i could, and that was the cheapest i could find (though i havent had the time to put mine together as yet because the pps line does need some soldering). I also happened to have a wyse terminal (x86 based) http://www.wyse.com/products/hardware/thinclients/S10/index.asp that i picked up for around 30$ (currently running ubuntu 10.10 server without too much drama). On 13/02/12 13:00, Dave Hart wrote: On Sat, Feb 11, 2012 at 10:20, Terje Mathisen wrote: unruh wrote: GEt the manual from Mediatex MTK NMEA Packet User Manual, which gives a far far more extensive set of nmea programming instructions for the chipset that Sure uses. Does that one have more info than my current program? C:\c2\nmea-mtkRelease\nmea-mtk.exe -? nmea-mtk (c) 2011 Terje Mathisen Syntax: nmea-mtk [options] The SURE electronics unit people have been buying as an affordable refclock for those with soldering skills and time is the reference design for the SkyNet SKG16AH chip known as SKG16B [1]. Unruh and Terje are talking about a MTK (I or II?) chipset. Does anyone know the relationship between the two? I'm wondering if there's a way to refer to both unambiguously, or if they're subtly different beasts. After a little more digging I came across a nice comparison table of chipsets [2] which suggests to me the SKG16AH is derived from or clones the interface of a MTk design. If you have additional insight or can correct me, I'd appreciate it. [1] http://www.skylab.com.cn/datasheet/SkyNav_SKG16AH_DS.pdf [2] http://wiki.openstreetmap.org/wiki/GPS_Chipset Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
On 2012-02-14, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: On 2/13/2012 3:25 PM, Chris Albertson wrote: On Mon, Feb 13, 2012 at 10:59 AM, Chuck Swigercswi...@mac.com wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. Not clear what thei question has to do with frequency stablizing a xtal, but the system clock is linked to the cpu clock. Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
On 2/14/2012 9:36 AM, unruh wrote: On 2012-02-14, Ron Frazier (NTP)timekeepingntpl...@c3energy.com wrote: On 2/13/2012 3:25 PM, Chris Albertson wrote: On Mon, Feb 13, 2012 at 10:59 AM, Chuck Swigercswi...@mac.com wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. Not clear what thei question has to do with frequency stablizing a xtal, but the system clock is linked to the cpu clock. I was simply wondering which crystal is the perpetrator. I always thought the CPU clock was highly accurate. 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] how do I lock in average frequency correction
On Feb 13, 2012, at 10:20 PM, Ron Frazier (NTP) wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. On classic IBM AT hardware, an Intel 8253 PIT (Programmable Interval Timer) using a 1.19MHz crystal is used to generate a periodic clock interrupt via the Intel 8259 PIC (Programmable Interrupt Controller) on IRQ 0, which is commonly referred to as system timer in IRQ docs. Typically, the OS would arrange for 60, 64, or 100 of these interrupts per second. The BIOS RTC clock is connected to IRQ 8; it's not commonly used as the primary system timer interrupt because it was expected to run at exactly 18.2 Hz for the RTC to keep time properly for (eg) DOS-based software, and it is on the secondary or slave 8259 connected via cascade to the primary 8259's IRQ 1. More modern hardware has replaced the pair of 8259 PICs with an APIC, originally the Intel 82093AA; and the 8253 PIT has been replaced by HPET, although modern x86 hardware will also have alternatives like the ACPI clock and TSC. In terms of software, earlier operating systems ran the kernel scheduler's quantum at the system timer interrupt rate; later systems tended to decouple them, and might also add yet more timers for profiling or gathering process usage stats. A typical example might be the system timer calling hardclock() at 60 or 100 Hz, the scheduler running at 1000Hz which calls softclock(), and adds a fixed estimate of time to the kernel's idea of now for each scheduler tick based upon the ratio between the interrupt waits, and/or possibly looking at the TSC. [1] The profiling and stats timers tended to run at odd rates like 1013 HZ and 91Hz, which are deliberately chosen to not correspond with the scheduler tick and thus provide more fair coverage (and to try to detect processes which game the process accounting system by doing work for just less than a scheduler tick, and then blocking so that they aren't active when the scheduler runs). Systems prefer to use the HPET for these, but it is possible to hook onto the RTC interrupt handler on IRQ8 at (eg) 91Hz, and only pass 1 interrupt of 5 onto the RTC's ISR-- giving that the expected 18.2Hz frequency. I seem to recall that video card BIOSes of a certain era (VESA BIOS linear framebuffer stuff) also hooked into IRQ8 References: http://en.wikipedia.org/wiki/8253 http://www.compuphase.com/int70.txt http://www.intel.com/design/chipsets/datashts/290566.htm http://en.wikipedia.org/wiki/High_Precision_Event_Timer Regards, -- -Chuck [1]: This code has been historically buggy to very buggy in various platforms, and can exhibit many unfortunate behaviors such as having the clock appear to be stuck for one or more scheduler ticks, or even have time going backwards, etc. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
On 2012-02-14, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: On 2/14/2012 9:36 AM, unruh wrote: On 2012-02-14, Ron Frazier (NTP)timekeepingntpl...@c3energy.com wrote: On 2/13/2012 3:25 PM, Chris Albertson wrote: On Mon, Feb 13, 2012 at 10:59 AM, Chuck Swigercswi...@mac.com wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. Not clear what thei question has to do with frequency stablizing a xtal, but the system clock is linked to the cpu clock. I was simply wondering which crystal is the perpetrator. I always thought the CPU clock was highly accurate. Accurate it is not. It does not need to be. All it has to do is tick, and the cpu really does not care ( within bounds) what rate it is ticking at. It also does not care if that rate changes in time. Ie, it does not really need to be a good clock. In fact on some modern machines, its rate purposely fluctuates. It is certainly sensitive to temperature fluctuations. The cpu clock drives the interrupts on the timer interrupt chip. The cpu clock also drives the counter in the cpu which is used to interpolate the fine time between the major clock ticks from the timer interrupt. In many ways it is astonishing that the PC architecure allows timing down to the usec level with any accuracy at all. Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] lots of GPS modules and info at SparkFun
Hi Paul, I noticed the module you mentioned uses the Sirf III chipset. I've been doing a good bit of experimentation with a GlobalSat BU-353 (no PPS) which is also based on the same chipset. David Taylor was nice enough to post my experience on his website from a series of dialogs we had. You might find the information useful, including how I programmed the unit. The GlobalSat specific data may not apply to the unit you mentioned, but the Sirf stuff should apply to either. If you want to look it up, the link is below. I don't think that page mentions it, but I now have my unit outputting only the GPZDA NMEA sentence, which seems to give the most accurate timing information and the least jitter. I don't think this sentence has any position information. Obviously, with PPS, the accuracy of the NMEA is less important. But, with my current setup, I'm getting pretty consistent +/- 6 ms accuracy. http://www.satsignal.eu/ntp/conversation-with-ron.html Sincerely, Ron On 2/12/2012 9:31 PM, Paul J R wrote: Figure I might chime in with the gps unit I got and if your in Aust i think its probably about the best deals i've seen that has a pps line (theres also another one they have if you can do smd soldering thats cheaper again). http://www.twig.com.au/store/product_info.php?products_id=108osCsid=148a3e8759d5ae6b8ab6f3f0489e0fd4 http://www.twig.com.au/store/product_info.php?products_id=108osCsid=148a3e8759d5ae6b8ab6f3f0489e0fd4 I was looking to put together the dirt-cheapest ntpd machine with pps i could, and that was the cheapest i could find (though i havent had the time to put mine together as yet because the pps line does need some soldering). I also happened to have a wyse terminal (x86 based) http://www.wyse.com/products/hardware/thinclients/S10/index.asp that i picked up for around 30$ (currently running ubuntu 10.10 server without too much drama). On 13/02/12 13:00, Dave Hart wrote: On Sat, Feb 11, 2012 at 10:20, Terje Mathisen wrote: unruh wrote: GEt the manual from Mediatex MTK NMEA Packet User Manual, which gives a far far more extensive set of nmea programming instructions for the chipset that Sure uses. Does that one have more info than my current program? C:\c2\nmea-mtkRelease\nmea-mtk.exe -? nmea-mtk (c) 2011 Terje Mathisen Syntax: nmea-mtk [options] The SURE electronics unit people have been buying as an affordable refclock for those with soldering skills and time is the reference design for the SkyNet SKG16AH chip known as SKG16B [1]. Unruh and Terje are talking about a MTK (I or II?) chipset. Does anyone know the relationship between the two? I'm wondering if there's a way to refer to both unambiguously, or if they're subtly different beasts. After a little more digging I came across a nice comparison table of chipsets [2] which suggests to me the SKG16AH is derived from or clones the interface of a MTk design. If you have additional insight or can correct me, I'd appreciate it. [1] http://www.skylab.com.cn/datasheet/SkyNav_SKG16AH_DS.pdf [2] http://wiki.openstreetmap.org/wiki/GPS_Chipset Cheers, Dave Hart -- (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
[ntp:questions] why do internet servers not poll at longer intervals
Hi all, I have my USB GPS working pretty good at this point on both Windows and Linux. I have some more Linux specific questions that I'll post later. At the moment, I'm working on Windows. As has been suggested by others, I know I can get hugely better accuracy using a different GPS and PPS, and I plan to experiment with that when I get time and money. (I've been ignoring lots of other household things while pursuing this project.) For the moment, I just want to get optimum performance out of the equipment that I have. For my immediate needs, +/- 6-10 ms accuracy is perfectly adequate for what I'm doing. Here's a recent ntpq -p printout: C:\Windows\system32ntpq -p remote refid st t when poll reach delay offset jitter == *GPS_NMEA(5) .GPS1. 0 l18 3770.000 -1.181 0.977 +nist1-ny.ustimi .ACTS. 1 u 25 64 377 53.9903.458 6.160 #216.119.63.113 .ACTS. 1 u 42 64 377 59.998 22.534 5.595 +india.colorado. .ACTS. 1 u 36 64 377 63.9861.739 6.604 +ping-audit-207- .ACTS. 1 u 50 64 377 83.9980.715 3.206 Note that my GPS is closely synchronized with 3 of the 4 NIST Stratum 1 servers. I have intentionally set the fudge factor on the GPS so this is the case. Now, here are the relevant server lines in ntp.conf: server 127.127.20.5prefer minpoll 3 maxpoll 3 mode 72 fudge 127.127.20.5 time2 0.2950 refid GPS1 server nist1-ny.ustiming.org prefer minpoll 6 maxpoll 13 server nist1.columbiacountyga.gov minpoll 6 maxpoll 13 server utcnist.colorado.edu minpoll 6 maxpoll 13 server nist1.aol-ca.truetime.com minpoll 6 maxpoll 13 Now, note that the NIST servers are being polled every 64 seconds. This thing has been running this way since yesterday evening. However, in the configuration file, those servers are allowed to poll up to every 2 hours. My question is, why are the internet servers being polled so often continuously even though I have a stable GPS source available which is the currently selected active clock? If I comment out the GPS line, the internet servers will eventually go back to polling at longer intervals. Note that I don't want to get banned from using any of these public servers for hitting them too often. 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
[ntp:questions] how stable is GPS after startup
Hi all, I have my USB GPS running pretty well. However, I have noticed a few occasions when it goes wonky. Those are: a) Sometimes it appears to produce more consistent loopstats charts running the process on Above Normal priority (in Windows) rather than RealTime priority. I have to do further testing and documentation on this. b) Sometimes, it appears to destabilize after about 3 days of operation, and offsets jump by a factor of 10 to over 100 ms. I have to do more testing on this too, but I have noticed that unplugging and replugging the GPS appears to fix the problem. This has prompted me on some occasions to unplug and replug the GPS before restarting NTPD after making any configuration changes. c) I have sometimes noticed a large offset on the order of 50 ms TO THE NIST SERVERS after restarting NTPD even though the PC was closely synchronized to under 5 ms just a minute or two before. Note, the GPS is the preferred clock, AND, I have the GPS time fudged so it is in very close agreement with NIST. So, normally, both the NIST servers and the GPS are reporting less than 5 ms of offset. So, my main question for this thread is about item c). I know it has been said that NTPD takes a while to stabilize, but the phenomenon I mention doesn't always occur. Sometimes, the very first report I get after restarting NTPD says I'm within 5 ms or so of GPS time and the NIST servers. I was originally thinking NTPD was at fault, or possibly NTPQ or possibly the Meinberg server monitor. I'm now wondering if the GPS receiver is the problem. I want to know if this theory is likely. I have noted on an old hand held GPS I have, that, when it gets a fix, it will first say, for example, that it's accuracy is 150 ft, then later, maybe 70 ft, then, after a while, maybe 23 feet, and occasionally, 15 feet or so. So, I'm wondering it my unit here is doing the same thing. Maybe, when I first plug it in, it doesn't have an accurate position fix, and possibly, is not outputting the time as accurately. Maybe that's why I see immediate offsets to all the NIST servers of 50 ms or more. Then, later, after the GPS has been running 20 minutes or so, maybe it's position and time fix is much more accurate, so then I see my normal offsets to NIST of under 5 ms. Does that make sense? 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] ntpd wedged again
On 2/14/2012 01:49, David Lord wrote: A C wrote: On 2/13/2012 15:44, David Lord wrote: Recent ntpd is supposed to handle that level of frequency offset but most of my pcs have had the frequency offset adjusted to be 10 ppm which is done when I build a kernel with options PPS_SYNC and options TIMER_FREQ=119. This kernel does have PPS_SYNC enabled but I'm not using it right now since I'm still debugging ntpd/libc. I'll start using it next week after I know ntpd will survive a week straight. How do you determine the timer frequency number? Trial and error? At one time I could find it in the documentation but not when I last did a search. AFAIK it was supposed to be self calibrating so the ability for adjustment might be dropped. Unfortunately the self calibration can be 50ppm out. PC me6000 is using kernel compiled for a different pc: me6000 $ dmesg | grep timecounter timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 I have timecounter in my dmesg also but it doesn't show up anywhere in the kernel configuration for compiling: # dmesg | grep time timecounter: Timecounters tick every 10.000 msec timer0 at mainbus0 ioaddr 0xf300 ipl 10: delay constant 18, frequency = 100 Hz timecounter: Timecounter timer-counter frequency 100 Hz quality 100 timecounter: Timecounter clockinterrupt frequency 100 Hz quality 0 I'll have to ask the NetBSD people where the value is hiding. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] why do internet servers not poll at longer intervals
Ron Frazier (NTP) wrote: server nist1-ny.ustiming.org prefer minpoll 6 maxpoll 13 server nist1.columbiacountyga.gov minpoll 6 maxpoll 13 server utcnist.colorado.edu minpoll 6 maxpoll 13 server nist1.aol-ca.truetime.com minpoll 6 maxpoll 13 Stratum 1 servers in NY, GA, CO, CA? I'd change that to something like: restrict source nomodify pool us.pool.ntp.org iburst minpoll 10 -- 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] how stable is GPS after startup
On Tue, Feb 14, 2012 at 11:53 AM, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: Hi all, I have my USB GPS running pretty well. However, I have noticed a few occasions when it goes wonky. Those are: a) Sometimes it appears to produce more consistent loopstats charts running the process on Above Normal priority (in Windows) rather than RealTime priority. I have to do further testing and documentation on this. b) Sometimes, it appears to destabilize after about 3 days of operation, and offsets jump by a factor of 10 to over 100 ms. I have to do more testing on this too, but I have noticed that unplugging and replugging the GPS appears to fix the problem. This has prompted me on some occasions to unplug and replug the GPS before restarting NTPD after making any configuration changes. c) I have sometimes noticed a large offset on the order of 50 ms TO THE NIST SERVERS after restarting NTPD even though the PC was closely synchronized to under 5 ms just a minute or two before. Note, the GPS is the preferred clock, AND, I have the GPS time fudged so it is in very close agreement with NIST. So, normally, both the NIST servers and the GPS are reporting less than 5 ms of offset. So, my main question for this thread is about item c). I know it has been said that NTPD takes a while to stabilize, but the phenomenon I mention doesn't always occur. Sometimes, the very first report I get after restarting NTPD says I'm within 5 ms or so of GPS time and the NIST servers. I was originally thinking NTPD was at fault, or possibly NTPQ or possibly the Meinberg server monitor. I'm now wondering if the GPS receiver is the problem. I want to know if this theory is likely. I have noted on an old hand held GPS I have, that, when it gets a fix, it will first say, for example, that it's accuracy is 150 ft, then later, maybe 70 ft, then, after a while, maybe 23 feet, and occasionally, 15 feet or so. So, I'm wondering it my unit here is doing the same thing. Maybe, when I first plug it in, it doesn't have an accurate position fix, and possibly, is not outputting the time as accurately. Maybe that's why I see immediate offsets to all the NIST servers of 50 ms or more. Then, later, after the GPS has been running 20 minutes or so, maybe it's position and time fix is much more accurate, so then I see my normal offsets to NIST of under 5 ms. Does that make sense? Much of the appearent problem may be that NTP is measring offset with respect to the system time and the system time is not stable. With a GPS I'd guess this is the case. Yes the GPS will gain a better idea of it's location over time The graph of stabilty over time most offen used is an ADEV plot. Or Allen Deviation plot. This is really not hard. the vertical axis is deviation just like you learned in a statistics class. The horz. axis is the number of seconds yo collected sample data to compute the deviation. adev plot for a good GPS should be a straight line going down forever, until it hits some limit like the master clock at the GPS ground control station at maybe one part on 10^14. But when you first turn on the GPS it might take some minutes before it outputs anything. In fact a Motorola Oncore with no battery backup and an indoor antenna can take an hour or more but about 1 minute is typical for most GPSes. However a broken GPS can do anything. A few ways they can be broken is if the antenna does not have a good view of the sky and a sat. flies out of view or gets blocked by a tree. or if you can see the sky but there is multipath reflections.Typically a hand held GPS has very poor timing. I have one that NTP always rejects. It works well for sailboat racing (the velocity made good computation is a godsend) but the unit is useless for timing. If you GPS is doing odd things, check that it can see at least four sats. and nothing bad happened to the signal strength becuase the GPS signal i jammed. (another good reason to have the GPS antenna on a mast outdoors.) Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] why do internet servers not poll at longer intervals
On Tue, Feb 14, 2012 at 11:25 AM, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: As has been suggested by others, I know I can get hugely better accuracy using a different GPS and PPS, and I plan to experiment with that when I get time and money. (I've been ignoring lots of other household things while pursuing this project.) For the moment, I just want to get optimum performance out of the equipment that I have. For my immediate needs, +/- 6-10 ms accuracy is perfectly adequate for what I'm doing. Actually I like building stuff with junk (junk = ham radio term for box of salvaged parts) It is so easy to build anying if you can just order whatever parts you like. You learn more f you have to use what you have. Why the short polling? NTP's real end product is a clock adjustment rate. NTP looks to see if this rate moves around.lots of movement tel NTP that the oscillator inside your computer is not stable and can't be trusted for long periods of time. In might be a cheap oscillator, or your PC might be right under an air conditioning vent. It don't matter.The polling interval is set baed on (1) the stabilty of the local PC internal clock and (2) jitter on the Internet servers. NTP finds the place two lines cross and puts the polling interval there. Your nest step is to stabilize the internal temp. of the PC, turn off power management and get a thermostatically controlled fan. A good location for a home NTP server would be some internal closet that does not have an external wall r a heat/AC vent inside. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] how I did Ubuntu + NTPD + GPS, but how do I keep it?
Hi all,
This is the story of the hoops I had to jump through to get my USB GPS
to work with Ubuntu 11.04 and NPTD without using GPSD. When I first set
up the system, I couldn't get the GPS to work any way I tried. It turns
out that the AppArmor system was preventing it from working. Another
person on the list suggested checking the log files. I eventually
figured it out, and I'm posting the procedure here. However, when I
reboot, I lose some of these configuration steps, which I need help with
figuring out how to make permanent. Hopefully, by sharing this
information, it will help others in a similar situation. I used lots of
internet sources for this data, and don't remember all the websites I
went to.
AppArmor must be tweaked every time you want to add an NTPD external
reference clock, otherwise, AppArmor won't allow NTPD to access the
GPS. This assumes you already have NTP set up and running with internet
servers.
Edit the AppArmor tunable file for ntpd with:
gksu gedit /etc/apparmor.d/tunables/ntpd
Add lines to allow ntpd to access the port you want - in this case
/dev/gps5. I'm using 127.127.20.5 as my GPS address in ntp.conf. In
Windows, NTPD expects to find the GPS on COM5. The last digit of the
address controls the COM number. On Linux, NTPD expects to see the GPS
on /dev/gps5. The last digit of the address controls the number at the
end of this string. This following modification to the AppArmor file
will allow NTPD to access /dev/gps5, or 1, or whatever you have uncommented.
Here is the contents of my AppArmor file.
-
# Added by Ron - 2012-02-11
# Path to this file is: /etc/apparmor.d/tunables/ntpd
# Added /dev/gps1 and /dev/gps5
# /dev/null was the original line. /dev/ttyS1 was there but commented out.
# Apparently only one device can be active. Commented others out.
#Add your ntpd devices here eg. if you have a DCF clock
# @{NTPD_DEVICE}=/dev/ttyS1
#@{NTPD_DEVICE}=/dev/null
#@{NTPD_DEVICE}=/dev/gps1
@{NTPD_DEVICE}=/dev/gps5
---
Now, reinitialize AppArmor with:
(You may have to cd to this directory. I don't remember for sure.)
sudo invoke-rc.d apparmor reload
Stop ntpd with:
sudo /etc/init.d/ntp stop
Plug in the USB GPS. Wait a few seconds for it to initialize if it's
been on recently, or up to 12 minutes (I think) for a full cold start
and satellite data download. My GPS flashes a LED light about once /
second when it has a position fix.
Set the parameters for the USB port with:
(Customize your baud rate and USB port number.)
stty -F /dev/ttyUSB0 57600 igncr clocal -echo -ixon
Now, the output of the GPS should be appearing on /dev/ttyUSB0. This
must be sent to /dev/gps5 to satisfy NTPD.
Set up a symlink linking this port with /dev/gps5 with:
sudo ln -T /dev/ttyUSB0 /dev/gps5
Check that the gps is outputting data on /dev/gps5 with:
cat /dev/gps5
This should output something like (output will vary with different
gps's). There should be no blank lines. I have my GPS set to output
only the GPZDA sentences.
--
ron@asus-k52f-1:/etc$ cat /dev/gps5
$GPZDA,184622.000,11,02,2012,,*5E
$GPZDA,184623.000,11,02,2012,,*5F
$GPZDA,184624.000,11,02,2012,,*58
$GPZDA,184625.000,11,02,2012,,*59
$GPZDA,184626.000,11,02,2012,,*5A
$GPZDA,184627.000,11,02,2012,,*5B
ctrl-c to stop
--
Edit /etc/ntp.conf with:
gksu gedit /etc/ntp.conf
Set up the gps lines:
-
# Uncomment this if GPS is available, Tweak com no. Unprefer NIST.
# GPS on COM5 - xxx.xxx.xxx.5 - Mode 16 = 9600 baud Mode 64 = 57600
# Add 1 to mode to use GPRMC sentence - same as default
# Add 2 to mode to use GPGGA sentence - may have better timing
# Add 8 to mode to use GPZDA or GPZDG sentence - recommended by Trimble
# Mode 66 = 57600 baud and use GPGGA sentence
# Mode 72 = 57600 baud and use GPZDA or GPZDG sentence
# Fudge - Tweak the GPS input for less offset from nist
# GlobalSat BU-353 USB GPS - 57600 baud /dev/ttyUSB0 link to /dev/gps1
or /dev/gps5
# Linux settings
# Fudge factor using time2 for Linux = 0.300
server 127.127.20.5prefer minpoll 3 maxpoll 3 mode 72
fudge 127.127.20.5 time2 0.3000 refid GPS1
-
Initialize the clock with:
sudo ntpdate nist1-ny.ustiming.org
Restart the ntpd service with:
sudo /etc/init.d/ntp start
Check the status of ntp with:
ntpq -p
At this point, NTPD should be reading the GPS. You may have to wait
several minutes for it to stabilize. Initial reports may be bogus.
-
ron@asus-k52f-1:/etc$ ntpq -p
remote refid st t when poll reach delay offset
jitter
==
*GPS_NMEA(5) .GPS1. 0 l68 3770.0000.002
0.002
nist1-ny.ustimi .ACTS. 1 u 66 641 56.459
-1.558
Re: [ntp:questions] how I did Ubuntu + NTPD + GPS, but how do I keep it?
Also, I'd like to know how to have multiple USB serial devices plugged in, since, as I understand it, there's no guarantee that the same USB device will always be assigned to /dev/ttyUSB0. Simple hack is to edit less /etc/init.d/ntpd Be sure and save the edited verion as an OS upgrades might over right it. How to automatically find the GPS after it is plugged in. Read the port. You should see a NMEA sentence on it. Takes a bit of shell or perl script. But a real ntp server would have a serial RS232 port and you almost never re-boot except to replace failed hardware. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how stable is GPS after startup
On 2012-02-14, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: Hi all, I have my USB GPS running pretty well. However, I have noticed a few occasions when it goes wonky. Those are: a) Sometimes it appears to produce more consistent loopstats charts running the process on Above Normal priority (in Windows) rather than RealTime priority. I have to do further testing and documentation on this. b) Sometimes, it appears to destabilize after about 3 days of operation, and offsets jump by a factor of 10 to over 100 ms. I have to do more testing on this too, but I have noticed that unplugging and replugging the GPS appears to fix the problem. This has prompted me on some occasions to unplug and replug the GPS before restarting NTPD after making any configuration changes. That should not make a difference. c) I have sometimes noticed a large offset on the order of 50 ms TO THE NIST SERVERS after restarting NTPD even though the PC was closely synchronized to under 5 ms just a minute or two before. Note, the GPS is the preferred clock, AND, I have the GPS time fudged so it is in very close agreement with NIST. So, normally, both the NIST servers and the GPS are reporting less than 5 ms of offset. Since you are using the end of the sentences as the timing mark, that sentence and could be occuring at differnt times. Eg if there is an extra character (byte) at 9600dB that is about 1ms difference. So if there were a whole extra sentence being insterted every once in a while ( eg your gps receiver every hour say reports extra sentences) it could explain that. That is why gps is better using PPS. Note that there could be manyreasons for your system jumping in time if you restart. So, my main question for this thread is about item c). I know it has been said that NTPD takes a while to stabilize, but the phenomenon I mention doesn't always occur. Sometimes, the very first report I get after restarting NTPD says I'm within 5 ms or so of GPS time and the NIST servers. I was originally thinking NTPD was at fault, or possibly NTPQ or possibly the Meinberg server monitor. I'm now wondering if the GPS receiver is the problem. I want to know if this theory is likely. I have noted on an old hand held GPS I have, that, when it gets a fix, it will first say, for example, that it's accuracy is 150 ft, then later, maybe 70 ft, then, after a while, maybe 23 feet, and occasionally, 15 feet or so. So, I'm wondering it my unit here is doing the same thing. Maybe, when I first plug it in, it doesn't have an accurate position fix, and possibly, is not outputting the time as accurately. Maybe that's why I see immediate offsets to all the NIST servers of 50 ms or more. Then, later, after the GPS has been running 20 minutes or so, maybe it's position and time fix is much more accurate, so then I see my normal offsets to NIST of under 5 ms. Does that make sense? It would have to out in its fix by 300km ( 200 miles) to make the time be out by 1ms. Not likely. Sincerely, Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd wedged again
On 2/14/2012 1:43 AM, David J Taylor wrote: A C agcarver+...@acarver.net wrote in message news:4f398579.9060...@acarver.net... [] I'm not sure it's a good idea either but I would really like to understand why a refclock clamps the polling interval at such a low value when nearly every bit of documentation says we should be kind to NTP servers and make sure the polling period is allowed to reach 1024. If you look back in the archives of this newsgroup you will find that I asked David Mills a similar question, and he gave an answer. I'm not sure that I completely understood the answer, though. I now have lines like the following in my ntp.conf file for my stratum-1 PCs: server 0.uk.pool.ntp.org minpoll 10 server 1.uk.pool.ntp.org minpoll 10 server 0.nl.pool.ntp.org minpoll 10 As I have three PCs peered fed from different GPS receivers I'm hoping that the Internet servers are never needed. G Cheers, David The problem with THREE GPS receivers, or just about any other clock, is that it it can too easily degenerate to the two server case. It is well known that a man with two clocks can never be certain what time it is. Four, five, and seven are the magic numbers for a robust configuration. Most sites will settle for four. The very paranoid or the very rich might go for seven. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd wedged again
On 2012-02-15, Richard B. Gilbert rgilber...@comcast.net wrote: On 2/14/2012 1:43 AM, David J Taylor wrote: A C agcarver+...@acarver.net wrote in message news:4f398579.9060...@acarver.net... [] I'm not sure it's a good idea either but I would really like to understand why a refclock clamps the polling interval at such a low value when nearly every bit of documentation says we should be kind to NTP servers and make sure the polling period is allowed to reach 1024. If you look back in the archives of this newsgroup you will find that I asked David Mills a similar question, and he gave an answer. I'm not sure that I completely understood the answer, though. I now have lines like the following in my ntp.conf file for my stratum-1 PCs: server 0.uk.pool.ntp.org minpoll 10 server 1.uk.pool.ntp.org minpoll 10 server 0.nl.pool.ntp.org minpoll 10 As I have three PCs peered fed from different GPS receivers I'm hoping that the Internet servers are never needed. G Cheers, David The problem with THREE GPS receivers, or just about any other clock, is that it it can too easily degenerate to the two server case. It is well known that a man with two clocks can never be certain what time it is. And the problem with 976 receivers is all it takes is 974 failures and you are down to the two receiver case. Four, five, and seven are the magic numbers for a robust configuration. Most sites will settle for four. The very paranoid or the very rich might go for seven. Four is horrible, in that two to two is a tie. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd wedged again
On Wed, Feb 15, 2012 at 04:22, unruh un...@invalid.ca wrote: On 2012-02-15, Richard B. Gilbert rgilber...@comcast.net wrote: Four, five, and seven are the magic numbers for a robust configuration. Most sites will settle for four. The very paranoid or the very rich might go for seven. Four is horrible, in that two to two is a tie. The cluster algorithm doesn't compare one cluster against another, so that shouldn't be a problem. See http://www.eecis.udel.edu/~mills/ntp/html/cluster.html and http://www.eecis.udel.edu/~mills/ntp/html/warp.html Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
In article 4f39fd1a.6020...@c3energy.com, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. Customarily, there's a really cheap crystal oscillator on the motherboard, and all of the other frequencies on the system -- except for the battery-backed RTC clock -- are generated by a clock-generator circuit which uses that frequency as a reference. Historically, the PC used frequencies which were convenient multiples of the NTSC colorburst frequency, because NTSC crystals were really cheap. Today's PCs tend to use a 14.31818 MHz (4*NTSC) crystal instead, and the chipset has a clock generator to generate 1/3 NTSC to drive the emulated Intel 8254 programmable interval timer which is what drives traditional timer interrupts. Modern machines have at least four other timing sources: the CPU's cycle counter (TSC), the ACPI timer, one more more high-precision event timers (HPETs), and the battery-backed real-time clock (RTC). On my machine, the ACPI timer runs at 3.579545 MHz and the HPET runs at 14.318180 MHz. All of these have issues, starting with the fact that they run at inconvenient rates. The CPU cycle counter varies widely in quality, depending on the design of the motherboard, CPU, BIOS, and operating system. (Some CPUs run the cycle counter at a constant frequency regardless of the actual CPU clock dictated by power management; some CPUs don't count cycles spent in system-management mode; multiprocessors are generally a hard case.) The ACPI timer depends on the quality of the BIOS's ACPI implementation, but is guaranteed to be power-state invariant, and there's only one of them per system so the multiprocessor issues are tractable. The HPET is not universally supported yet, and my FreeBSD system at least considers the ACPI timer to be higher quality. The 8254 is extremely slow despite being implemented in the motherboard chipset; the emulation replicates the speed of ISA-bus I/O -- but it can generate interrupts. The RTC can generate interrupts, but only at power-of-two frequencies, it's also a slow ISA-emulating device, and the counter that generates the interrupts can't be read so no interpolation is possible. Modern operating systems are moving towards tickless operation to improve power efficiency. This requires an on-board timing device that has sufficient range and stability to accurately determine the amount of time that has elapsed between two non-periodic interrupts, so that the clock can be advanced by the correct amount. -GAWollman -- Garrett A. Wollman| What intellectual phenomenon can be older, or more oft woll...@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
On 2/14/2012 2:54 AM, Chris Albertson wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. Look in the directory /sys/devices/system/clocksource/clocksource0 On Linux there are two files. One lists all the possible clock source the kernel found on your hardware. There might be more then a few depending on what kind of computer you have. Remember Linux runs on everything from cell phones to mainframes The other file tells you with clock source is actually being used. There is a way to force the selection at boot time. All that said, on a modern PC lilely you are using the hpet to cause periodic interrupts, each interrupt advances the system time by one tick. hpet is the high precision timer. Google will tell you all about hpet. Ticks are between 100Hz and 1000Hz. I think 1000Hz is common. It is adjustable at boot time also I'd bet it is completely different on Windows systems an even other UNIXes Chris Albertson Redondo Beach, California HI Chris, Thanks for the info. What a mess of different methods to create a clock tick. I think I'll focus on trying to use the system rather than trying to understand it. 8-) 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] how do I lock in average frequency correction
On Wed, Feb 15, 2012 at 06:04, Garrett Wollman woll...@bimajority.org wrote: In article 4f39fd1a.6020...@c3energy.com, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: Perhaps a silly question, but, does the tick that drives the OS software clock originate from the RTC or from the CPU master clock at 2 GHz or whatever? Just trying to understand how this stuff works. Customarily, there's a really cheap crystal oscillator on the motherboard, and all of the other frequencies on the system -- except for the battery-backed RTC clock -- are generated by a clock-generator circuit which uses that frequency as a reference. Historically, the PC used frequencies which were convenient multiples of the NTSC colorburst frequency, because NTSC crystals were really cheap. I believe it had more to do with the Color Graphics Adapter circuitry needing to operate at NTSC-compatible frequency.l Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
Richard B. Gilbert wrote: Generally, those crystals have failed quality control by the clock/watch makers. We are not talking about the RTC crystal! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
