Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
Mike S wrote: If you do a bit of research, I think you'll find that the 32768 Hz input to the RTC clock isn't even exposed on most PCs. A battery supported RTC It wasn't part of the PC architecture, but it was part of the PC AT architecture, and possibly of the PC XT. All modern Intel Architecture PCs are descendants of the AT. I've got the AT circuit diagram and can tell you the actual chip used, if you want. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
Mike S wrote: At 02:00 AM 1/13/2011, Terje Mathisen wrote... Not quite true: Many OSs use the 32768 Hz clock, suitably subdivided to something like 1024 Hz or 64 Hz (pretty common Windows SMP kernel) as the main timer interrupt. If you do a bit of research, I think you'll find that the 32768 Hz input to the RTC clock isn't even exposed on most PCs. A battery supported RTC was simply not a part of the original PC architecture. I'd like to see some support for your claim, because I couldn't find any. I haven't done this research since around 1986-87 or so, when the IBM AT had turned up with a CMOS clock. That original chip did have the capability to be programmed to generate external interrupts at any power of two Hz, from 1 Hz to 32KHz. I know, because I used it to improve local clock consistency by a couple of orders of magnitude: I wrote a program/driver (remember TSRs?) which took over most of the BIOS/Dos timing functions, and replaced them with code that was based on the CMOS clock interrupt. I had no NTP style timing packets, just a week-long calibration run to measure the average drift. With this hack the drift rate dropped from a number of seconds/day to some tens of ms. Anyway, it is quite possible that this facility has gone away on modern machines, it was WinNTs change many years ago from a default 100 Hz clock to 64 Hz which made me think they had changed to use the CMOS interrupt. 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] How to keep Linux server in Chicago and Mumbai in sync to within 5 microseconds
Chuck Swiger wrote: On a good day, my MUA sends Content-type: text/plain; format=flowed and should contain line breaks following the 80-character-per-line Usenet conventions, which modern MUAs might well reassemble based upon the user's window size. If it is being re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well, that lies beyond my control. Obviously a bad day as there is no format flowed on yours, whereas there is on mine (posted directly to usenet). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Folks, You may recall that I had a problem with a Garmin GPS18x LVC after firmware upgrades, where the offset between the leading edge of the PPS signal and the end of the NMEA serial data exceeded one second. With some help from Hal Murray who knows more of NTP than I do, we have worked round the problem as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x The basic steps were: - make the GPX18x LVC noselect so that NTP would not use it - enable the peerstats to measure where NTP thought the 18x end of message occurred - analyse the peerstats file to determine the apparent offset (which was -1.000 seconds, as it happened) - add that offset (as +1.000 seconds) to the fudge time2 value for the 18x in the ntp.conf - restart NTP I hope that helps someone. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] IEEE 1588 Plugfest in Germany
Hi, I hope people do not mind if I shamelessly take advantage of the fact that a large number of time sync related people are reading this newsgroup. I just wanted to announce that there will be a IEEE 1588/PTP (Precision Time Protocol) plugfest held in Lemgo, Germany at the end of March. Anybody who is interested in testing their PTP implementations/devices is invited to participate and run interoperability/performance/conformance tests in Lemgo against the products/software of other vendors. See http://www.hs-owl.de/init/en/aktuelles/news/news-einzelansicht/news/ieee-1588-plugfest-im-ciit/1.html for further information. Regards, Heiko ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Use ntpd as a daemon so that it continuously disciplines clock, no listen port
I want to use ntpd as a daemon on client to synchronize to my NTP server of company lan. Can I avoid ntpd service doesn't listen to port 123 on this client ? I'd like using only this service for synchronizing to ntp server, but no listen port ! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On Fri, Jan 14, 2011 at 08:40:25AM -, David J Taylor wrote: Folks, You may recall that I had a problem with a Garmin GPS18x LVC after firmware upgrades, where the offset between the leading edge of the PPS signal and the end of the NMEA serial data exceeded one second. With some help from Hal Murray who knows more of NTP than I do, we have worked round the problem as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x - add that offset (as +1.000 seconds) to the fudge time2 value for the 18x in the ntp.conf Thanks for the information. I was curious about the new position averaging mode, but I'll wait until this is resolved. 1.0s offset is horrible, that will certainly break gpsd or any application that pairs pulses with following NMEA timestamps. Have you tried increasing baud rate to 38400 and disabling all unneeded NMEA sentences? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
At 02:40 AM 1/14/2011, Terje Mathisen wrote... That original chip did have the capability to be programmed to generate external interrupts at any power of two Hz, from 1 Hz to 32KHz. Yes, I'm aware of that. I probably used the wrong word when I said it wasn't exposed, by which I meant that I don't believe those interrupts are setup and used for any purpose, by either BIOS or common OSs, so any inaccuracy in the 32768 Hz is not normally seen (except in power-off timekeeping accuracy). The interrupts are available for applications to use. I believe that all system timing ultimately traces back (almost universally) to a 14.31818 MHz source, which drives the 8254 HPET ACPI PM Timer. With all of the motherboards I've played with, changing a 14.31818 crystal is what affected the drift rate reported by NTP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
On 2011-01-12, Chris Albertson albertson.ch...@gmail.com wrote: I had a motherborad fail a few weeks ago, (big black burned hole where a voltage regulator caught fire) so before dumping the thing in the trash I looked it over for good salvage.I found two TCXOs that were used for the CU clock and for the graphic system but the real time clock chip had a cheep 32Khz watch crystal on it. These sell for maybe 10 cents each. Seems to me that if you want to build a first class NTP server it would not be hard to unsolder the watch crystal and replace it with a length of coax cable that heads off to a precision oscillator.I had little to loose as the board was already dead and found the watch crystal comes off very easy. Some day I'll build a 32K oscillator that is locked to the 10Mhz laboratory frequency reference Since you are going to perform some circuit board repairs, there is a TAPR kit you might have interest: http://www.tapr.org/~n8ur/Clock-Block_Manual.pdf The clock crystal is removed and replaced with this board and the PC will be phase locked with the GPS broadcasts. The designer, N8UR, has a lot of time related information on his website as well. He has replaced the motherboard clock on a low powered Intel Atom with this kit. SMT board soldering is not for everyone, but since you are already planning on replacing your motherboard clock chip, you might want to review this site for various ideas: http://www.febo.com Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Folks, You may recall that I had a problem with a Garmin GPS18x LVC after firmware upgrades, where the offset between the leading edge of the PPS signal and the end of the NMEA serial data exceeded one second. With some help from Hal Murray who knows more of NTP than I do, we have worked round the problem as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x The basic steps were: - make the GPX18x LVC noselect so that NTP would not use it - enable the peerstats to measure where NTP thought the 18x end of message occurred - analyse the peerstats file to determine the apparent offset (which was -1.000 seconds, as it happened) - add that offset (as +1.000 seconds) to the fudge time2 value for the 18x in the ntp.conf - restart NTP I hope that helps someone. This is a problem in the coding of the program (gpsd?) that you are using to get the data. The computer clock is a good device for measuring the time between the PPS. The timestamp on the PPS and the timestamp on the beginning and end of the nmea transmission are more than sufficient infomation to link the nmea time to the PPS. While I agee that the GPS should not be taking more an a second to get the time to you, the program should also be robust enough to take that into account. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Thanks for the information. I was curious about the new position averaging mode, but I'll wait until this is resolved. 1.0s offset is horrible, that will certainly break gpsd or any application that pairs pulses with following NMEA timestamps. Have you tried increasing baud rate to 38400 and disabling all unneeded NMEA sentences? -- Miroslav Lichvar Miroslav, From reports elsewhere, it seems that the position averaging mode adds about 8ms to the delay. You can enable and disable the mode with the Garmin configuration software. NTP seems to work correctly with the - agreed horrible - 1.0s offset. That is with 19200 baud and just the single GPRMC sentence. (I think that's the one). So changing to 38400 baud wouldn't get me a lot (about 17ms earlier). Cheers, David Well 17ms would get you under the 1.0 sec cutoff. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij14l6.qns.un...@wormhole.physics.ubc.ca... [] Well 17ms would get you under the 1.0 sec cutoff. It seems that with ntpd there is no 1.0 sec cut-off - fortunately. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
On 1/13/2011 8:08 PM, Chris Albertson wrote: On Thu, Jan 13, 2011 at 3:59 PM, Mike Smi...@flatsurface.com wrote: de-facto' timer hardware for IA-PCs. If trying to improve the system time stability of a PC, the first thing to look for is a 14.31818 MHz crystal I just now did a parts search at Digikey for the best posable 14.31818 MHz crystal to put on a PC motherboard. The one I found was a 10ppm part made by a company called TXC. It was also an exact match to the part I salvaged from the dead board. So it seems the only way to get better is to build some kind of disciplined oscillator likely based on GPS. It would not be hard to build one that is 1000 times better than 10ppm Have you considered temperature control? Try putting the crystal in a home made oven? All you have to do is to ensure that the crystal is maintained at a constant temperature. The tighter the temperature control, the more stable the frequency will be! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
On Jan 13, 7:38 pm, mi...@flatsurface.com (Mike S) wrote: I was able to force the kernel to use the 8259 by adding clocksource=acpi_pm to the boot options. The available clock sources can be found with cat /sys/devices/system/clocksource/clocksource0/available_clocksource. FWIW, the 8259 is the PIT, not the ACPI timer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Use ntpd as a daemon so that it continuously disciplines clock, no
ric.castell...@alice.it said: I want to use ntpd as a daemon on client to synchronize to my NTP server of company lan. Can I avoid ntpd service doesn't listen to port 123 on this client ? I'd like using only this service for synchronizing to ntp server, but no listen port ! ntpd has to bind to an interface on your LAN so that it can poll your LAN time server. Recent versions of NTP provide a way for you to control which interfaces ntpd will use. If you don't want your ntpd serving time to others (e.g. on your LAN) then you will need configure the access restrictions to meet your requirements (see http://support.ntp.org/Support/AccessRestrictions or search for 'restrict' at http://doc.ntp.org/your.ntp.version). -- Steve Kostecke kostecke.ntp.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij14hc.qns.un...@wormhole.physics.ubc.ca... [] This is a problem in the coding of the program (gpsd?) that you are using to get the data. The computer clock is a good device for measuring the time between the PPS. The timestamp on the PPS and the timestamp on the beginning and end of the nmea transmission are more than sufficient infomation to link the nmea time to the PPS. While I agee that the GPS should not be taking more an a second to get the time to you, the program should also be robust enough to take that into account. This is on a system with no gpsd. This is from the device itself, with measurements confirmed with a 'scope, and confirmed by others. ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On Fri, Jan 14, 2011 at 1:30 PM, unruh un...@wormhole.physics.ubc.ca wrote: On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. The only way to know is to compare to another reference assumed to be correct. Pool NTP servers would be accurate enough for that.The GPSes (Motorola Oncore) I use have a related problem in that they allow the pulse to be adjust so that it happens before the UTC second or any time during the second. So I actually have a choice. But how to set it and know it is right? What you'd do is adjust the timing until it was a best match to the other reference clocks you have or lacking that to a set of pool NTP servers I think what this proves is that setting up a Stratum One NTP server requires that you have access to multiple clocks in your lab. eBay makes this very inexpensive now. Many people have three or more clocks and test equipmnt so that they can be compared. Lacking this, it is just a gues if your server has corect time Could this be automated? Maybe, to some degree. The reference clock driver would need to have a survey mode setting where it would run for many hours and compare it's own time to others. NTP does this already, almost, what it lacks is a way to capture the measured offset and fold it back to a config file. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Use ntpd as a daemon so that it continuously disciplines clock, no listen port
RICCARDO wrote: I want to use ntpd as a daemon on client to synchronize to my NTP server of company lan. That's how it is normally used (except for choice of server). Can I avoid ntpd service doesn't listen to port 123 on this client ? ntpd needs to receive the replies from the server. It cannot do so unless it listens on port 123. The code is not structured in terms of using a socket for one server. The same socket serves for both responses and requests, in both directions. I'd like using only this service for synchronizing to ntp server, but no listen port ! If you have problems with a security consultant with an open port checker, you will just have to educate them. Otherwise the default configuration is reasonably secure but you can use restrict statements and (outside of ntpd) firewall rules to further restrict it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
On Jan 14, 3:14 pm, Evandro Menezes evan...@mailinator.com wrote: On Jan 13, 7:38 pm, mi...@flatsurface.com (Mike S) wrote: I was able to force the kernel to use the 8259 by adding clocksource=acpi_pm to the boot options. The available clock sources can be found with cat /sys/devices/system/clocksource/clocksource0/available_clocksource. FWIW, the 8259 is the PIT, not the ACPI timer. Ahem, the 8254 is the PIT, not the ACPI timer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
At 05:51 PM 1/14/2011, Evandro Menezes wrote... On Jan 14, 3:14 pm, Evandro Menezes evan...@mailinator.com wrote: On Jan 13, 7:38 pm, mi...@flatsurface.com (Mike S) wrote: I was able to force the kernel to use the 8259 by adding clocksource=acpi_pm to the boot options. The available clock sources can be found with cat /sys/devices/system/clocksource/clocksource0/available_clocksource. FWIW, the 8259 is the PIT, not the ACPI timer. Ahem, the 8254 is the PIT, not the ACPI timer. Yep, and if I'm not mistaken, the ACPI timer interrupt is routed through the APIC, which is basically a fancy 8259 PIC. Of course, there is no 8254 or 8259 or APIC on any modern motherboard, just subsets of devices (e.g. south bridge chip) which provide equivalent functionality. One might also say that the PIT is not an 8254, and the PIC is not an 8259, etc. and complain about that, too. In any case, pedanticism aside, the whole point was to avoid using the HPET (which - trying to satisfy the pedants again - is not a thing, but a function), because it gets set up inconsistently. acpi_pm worked for me. The choices I had available were tsc, hpet, and acpi_pm (pit was not a choice). I didn't even bother trying tsc, since I understand there's a strong likelihood of issues due to processor frequency scaling. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Use ntpd as a daemon so that it continuously disciplines clock, no listen port
On Fri, Jan 14, 2011 at 2:30 PM, David Woolley david@ex.djwhome.demon.invalid wrote: RICCARDO wrote: I want to use ntpd as a daemon on client to synchronize to my NTP server of company lan. That's how it is normally used (except for choice of server). Can I avoid ntpd service doesn't listen to port 123 on this client ? You don't say why you needs this. I'm assuming there is a firewall and you do not have the ability to re-configure it. Do you have VPN access through the firewall. The other thing is to make an SSH tunnel and forward port 123 data via SSH. I think with effort you can get NTP to use a different port What about setting up the server for broadcast? Then your client can be a broadcast client As a last resort you can buy a GPS receiver for $80, use that for a reference and ignore the server. = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
On Fri, Jan 14, 2011 at 1:05 PM, Richard B. Gilbert rgilber...@comcast.net wrote: Have you considered temperature control? Try putting the crystal in a home made oven? All you have to do is to ensure that the crystal is maintained at a constant temperature. That TAPR clock board is pretty much the answer. I did not know about it until it was pointed out here. There is slightly more to it then just constant temperature, that is actually very hard to do well. The TAPR board let's you use an existing lab standard you may already have. So you save a bit that way. Also the crystals they put in ovens are cut so that have a flat spot or bump in the temperature vs. frequency curve and then they set the oven to that spot on the curve. A crystal pulled off the computer may not have the right kind of curve for being ovenized. Yes simply stabilizing the temp might be good enough but using a lab standard is literally more than 1000 times better. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset jitter
On Jan 14, 2011, at 3:34 PM, Mike S wrote: In any case, pedanticism aside, the whole point was to avoid using the HPET (which - trying to satisfy the pedants again - is not a thing, but a function), because it gets set up inconsistently. That's a valid criticism of HPET, although some of the problems may be the fault of the BIOS and ACPI configuration, and not your OS. It's possible that a newer BIOS or tweaking of ACPI / power-state options might help. acpi_pm worked for me. The choices I had available were tsc, hpet, and acpi_pm (pit was not a choice). I didn't even bother trying tsc, since I understand there's a strong likelihood of issues due to processor frequency scaling. Also very true, although sufficiently modern processors have a P-state invariant CPU which will run at a constant rate and also ought to read the same regardless of which CPU core might be used. Anyway, the ACPI timer is generally a good timer choice, and if you're happy with it, there may well be no benefits from a change to something else. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Use ntpd as a daemon so that it continuously disciplines clock, no listen port
On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: RICCARDO wrote: Can I avoid ntpd service doesn't listen to port 123 on this client ? You don't say why you needs this. It's usually the old open ports are bad ports meme. Or it's the desire to not accept any unsolicited connections. I'm assuming there is a firewall and you do not have the ability to re-configure it. Interesting thought. Do you have VPN access through the firewall. The other thing is to make an SSH tunnel and forward port 123 data via SSH. Forwarding NTP packets over a VPN or through SSH is a good way to increase latency and jitter. I think with effort you can get NTP to use a different port Changing the NTP source port is simple if you're able to compile the source. This gives you security through obscurity at the expense of breaking ntpq (and ntpdc). What about setting up the server for broadcast? Then your client can be a broadcast client The client still has to bind the NTP port on the interface facing the broadcast server. As a last resort you can buy a GPS receiver for $80, use that for a reference and ignore the server. Another interesting thought. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Jan 14, 2011 at 1:30 PM, unruh un...@wormhole.physics.ubc.ca wrote: On 2011-01-14, Chris Albertson albertson.ch...@gmail.com wrote: When the software (any software) only receives a PPS signal and a serial message conveying the absolute time, but it does not know how much the serial message is offset from the true time, how should it determine the true time? From a configuration file that describes the relationship between the PPS and text message. How in the world does whoever set up that config file know that difference? The program can use the same algorithm you do to determine that. The only way to know is to compare to another reference assumed to be correct. Pool NTP servers would be accurate enough for that.The GPSes (Motorola Oncore) I use have a related problem in that they allow the pulse to be adjust so that it happens before the UTC second or any time during the second. So I actually have a choice. But how to set it and know it is right? ??? That would make the pps totally useless. If it does not occur on the UTC second, it is pointless. What you'd do is adjust the timing until it was a best match to the other reference clocks you have or lacking that to a set of pool NTP servers Since you are using the pool as your time source, just use them. This device adds nothing in that case. I am assuming, as with the GPS18. that the unit emits a PPS pulse exactly on the seconds transition of UTC time. Then the nmea sentences come after that telling you which second it was that that pulse gave the exact time to. The shmslp driver does something similar. It uses some other source to get the seconds right and then hands over to the PPS to get the nanoseconds right. But it uses only the PPS pulse, not the serial nmea data. It thus requires you to have another source of time. However with something like the GPS18 it delivers both the nanoseconds via that PPS AND the seconds via the nmea sentence. Of course that only works if you know which second that PPS pulse refers to. The specs of the GPS18 say that it is the previous pulse that that nmea timestamp refers to . But if it takes 2 sec say to deliver the nmea sentence, then the previous pps pulse is the wrong one. So the sentence MUST start less than 1 sec after the pulse. If it does not, it is broken and is not working according to spec. I have never had trouble with teh GPS18, but they are refering to the GPS 18x, the newer version. I think what this proves is that setting up a Stratum One NTP server requires that you have access to multiple clocks in your lab. eBay makes this very inexpensive now. Many people have three or more clocks and test equipmnt so that they can be compared. Lacking this, it is just a gues if your server has corect time Could this be automated? Maybe, to some degree. The reference clock driver would need to have a survey mode setting where it would run for many hours and compare it's own time to others. NTP does this already, almost, what it lacks is a way to capture the measured offset and fold it back to a config file. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
In article AANLkTi=E0_9LzCDg9esXx7yZp_NJGmSU+cuS=FY9=8...@mail.gmail.com, Chris Albertson albertson.ch...@gmail.com writes: Could this be automated? Maybe, to some degree. The reference clock driver would need to have a survey mode setting where it would run for many hours and compare it's own time to others. NTP does this already, almost, what it lacks is a way to capture the measured offset and fold it back to a config file. If you run the to-be-calibrated server in noselect mode, it won't pollute your local clock. If you turn on peerstats, you can get lots of data about how far off that clock is. That assumes your local clock is correct. If you believe that the PPS is correct, you only have to get the NMEA text close-enough. You can easily get there using typical network connections. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij219b.cr7.un...@wormhole.physics.ubc.ca... [] The shmslp driver does something similar. It uses some other source to get the seconds right and then hands over to the PPS to get the nanoseconds right. But it uses only the PPS pulse, not the serial nmea data. It thus requires you to have another source of time. However with something like the GPS18 it delivers both the nanoseconds via that PPS AND the seconds via the nmea sentence. Of course that only works if you know which second that PPS pulse refers to. The specs of the GPS18 say that it is the previous pulse that that nmea timestamp refers to . But if it takes 2 sec say to deliver the nmea sentence, then the previous pps pulse is the wrong one. So the sentence MUST start less than 1 sec after the pulse. If it does not, it is broken and is not working according to spec. I have never had trouble with teh GPS18, but they are refering to the GPS 18x, the newer version. Yes, it's the GPS 18x LVC - the newer version - and even then the problem only happens with newer versions of its firmware. This has been reported to Garmin. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij1g6n.mnc.un...@wormhole.physics.ubc.ca... [] ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. No program is actually needed - just an oscilloscope looking at the PPS and serial outputs. In this particular case, there is no separate program as such, just ntpd with the type 20 refclock looking at the serial signal, and a type 22 refclock looking at the PPS signal through a modified device drive. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
On 2011-01-15, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: unruh un...@wormhole.physics.ubc.ca wrote in message news:slrnij1g6n.mnc.un...@wormhole.physics.ubc.ca... [] ??? There is a program which takes the PPS signal and takes the nmea sentence and tells ntpd how much out the computer clock is from the true time. If you are not using gpsd, you are using some other program. Insert the name of that program whereever in my message I used the word gpsd. No program is actually needed - just an oscilloscope looking at the PPS and serial outputs. In this particular case, there is no separate program as such, just ntpd with the type 20 refclock looking at the serial signal, and a type 22 refclock looking at the PPS signal through a modified device drive. Is the start of the nmea sentect coming more than one second after the PPS signal? Or is it just ending at the one second mark? Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
