Re: [ntp:questions] garmin 18x and linux
On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: As I said, Without a PPS signal you will not get reasonable results. If the GPS lacks the PPS get another GPS. They are cheap. Really nice units with timing specs literally 100X better than the 18X can be bought on eBay for $20 to $30. The problem with NMEA only setups is that (I think) the firmware takes non-determinic time to convert its internal data to ASCII. This means the sentence is never output at the exact second tick. This error is enough to cause the GPS to fail NTPs clock selection algorithm. No. ntp can use the GPS nmea sentences to time the clock to a few 10s of ms. -- you may need to fudge the time offset to make up for the delay of the nmea sentence. There are two classes of GPS. The first is the more common one. These are navigation receivers. The second class are timing receivers these are special units that can take advantage of the fact that they KNOW their antenna is not moving.Knowing your exact position allows better timing solutions. The best timing GPS have nanosecond level error. You NMEA only unit likely has millisecond level error which is about 6 orders of magnitude worse. To use an expression. NTP has likely voted it off the island. It would only vote it off the island if it had a better source. Since this is the only source the vote is rigged. It is always on the island. I said there were two classes of GPS, but really as long as a GPS has a PPS output it can be used for timing. These is considerable crossover.The one thing all dedicated timing receivers will have is the ability to tell it the antenna location and that it is not moving. A gps with just nmea can be used for timing. Not as accurate, but then 10ms is only .1 seconds of arc on the telescope and I doubt he needs better accuracy than that. OK, no Internet at the observatory. But try using pool servers while you are setting up and debugging. You will need additional ref clocks to verify your GPS. the one second off problem is common as are delays in the PPS being out of phase with the true UTC second tick. I did this exact something a few years back. We built an astronomical camera specialized for photometry. I put NTP into the firmware so when the camera wrote out the FITS image files the time would be accurate. Accurate to what accuracy? On Thu, Sep 1, 2011 at 7:24 PM, Greg Hennessy greg.henne...@cox.net wrote: On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: Also, don't expect any reasonable result until you connect the pulse per second to NTP. There is no PPS for the GPS18x PC. You only listed one line from the config file. Post more of it. And finally it helps a lot if you can add some pool servers to the config file. The only other line is the driftfile line. The computer is meant for control of a telescope and observatory, and isn't on the internet. Adding pool servers won't help for that reason. Given that ntp in debug mode shows gpsread showing NTP at least sees the GPRMC messages, can anyone sugguest why NTP never syncs? Is there additional debug flags that would be useful? ___ 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] Odd behaviour in a multicast setting (bug in ntpd???)
Il 01/09/2011 16:08, Dave Hart ha scritto: That may tell you nothing, but it tells me the issue you see with multicast servers showing up with 1024s poll interval is not a problem with the ntp-stable release 4.2.6p3, meaning it's also unlikely to be an issue with ntp-dev (4.2.7). You can think it that way, you know the code better than I do, no doubt. But I don't know the code, and I am not as sure as you. The bug is difficult to reproduce with 4.2.4, so we may just have been lucky it didn't appear in 4.2.6. I'll keep doing my experiments for a while more. Considering how rude you've been, I'm not sure I'll bother posting my findings back, should the stable version break the same way. Good luck to you, too. -- M PS: should you ever bother to know how not to be that rude, check Steve Kostecke's answer. You may learn something. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntptime (ntp_gettime) behaviour
Resend Hello, I'm struggling with the behavior of ntptime. Let me first explain what i want to reach. We have an embedded system where we have to log several inputs with timestamp. The timestamp needs to be within 0,5sec accuracy. When using ntp version 4.2.2.p3 I use the output of ntptime to see if we can 'trust' the time on the system. Now i want to upgrade to the newest ntpd (4.2.6p3) because of some issues with dns not available at startup. But with this new version, ntptime give ok status, even when no ntp server have been ever reachable. Is this a bug in the new version, or am i misusing the ntptime output. If so, is there a better way of obtaining the time status of my system? Regards, Rini ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of GPS device
On 2 September 2011 07:56, unruh un...@wormhole.physics.ubc.ca wrote: Nope. It is completely unclear to me what your question is. Your 10.0.2.254 is an outside switch. I had several questions in my first message. Your assumption is wrong. You are telling me that a switch I installed in my rack and defined its many IP addresses is outside my company? Uau! 10.0.2.254 is a local as any machine in the 10.0.0.0/8 network. $ ntpq -p 10.0.99.99 remote refid st t when poll reach delay offset jitter == *10.0.2.10 .GPS.1 u 21 256 3770.1730.196 0.008 +10.0.2.9.GPS.1 u 93 256 3770.1750.191 0.014 +10.0.2.254 81.94.123.16 2 u 149 256 3770.583 -6.884 0.152 This tells me that your two GPS receivers are consistant with each other, but I have no idea why the offset is larger than the delay, and why the offsets are so large. On a lan, the offsets should be a factor of 20 or so less than what you are getting here. That the external router is 7 ms out just tells me that it is really poorly synced with the outside world. I found out the problem and just for the record I'll explain... The offset is larger than the delay because NTPd is using 10.0.2.254 (more on this switch later) as a time source and it shouldn't because it has two local stratum 1 clocks that are closer (0.170 ms vs 0.583 ms) are show less jitter. Anyway... to prove my point I removed 10.0.2.254 (the **internal** switch) from the configuration and here's the result of ntpq -p as of now: $ ntpq -p 10.0.2.2 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 889 1024 3770.179 -0.066 0.083 *10.0.2.9.GPS.1 u 391 1024 3770.166 -0.084 0.051 Oddly enough, FreeBSD embedded machine with roughly the same NTP configuration shows better results $ ntpq -p 10.0.99.99 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 864 1024 3770.1930.025 0.301 *10.0.2.9.GPS.1 u 1012 1024 3770.1920.030 0.004 Regarding 10.0.2.254 it is an internal switch it is getting time over a cable connection from several sources $ ntpq -p 10.0.2.254 remote refid st t when poll reach delay offset jitter == -ntp0.as34288.ne .PPS.1 u 391 1024 377 71.960 -1.029 0.270 *canon.inria.fr .GPSi. 1 u 707 1024 377 55.2200.199 0.700 +ntp1.inrim.it .CTD.1 u 359 1024 377 65.8600.091 1.830 +ntp-p1.obspm.fr .TS-3. 1 u 373 1024 377 55.110 -0.215 0.610 -metasweb01.admi .HBGi. 1 u 992 1024 377 73.290 -5.182 0.850 I can't control the network at my upstream provider and while my link is not saturated (far from that) my upstream provider links be could and there's nothing I can do about it except deploying local time sources as I did. I am checking my local time sources with some remote NTP stratum 1 servers at a fixed interval and plotting the results. I see that once in a while the offset to external time servers increases and I agree this has to be with network congestion but this happens at my ISP so there's not much I can do. This is a FreeBSD embedded PBX machine running Asterisk. The machine is mostly idle. What kind of offsets should I get with local machines? in the 10s of usec range max. Certainly less than the delay. tens of usec is good... Anyone here which can explain why NTP isn't getting that? How could we? Maybe you are running a virtual BSD machine, and thus the clocks are wonkey. Maybe you have lousy hardware. Who knows. No lousy hardware here but I think posting detailed hardware specifications won't help. No virtualization here also. Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets higher than 100 us. Is it possible to decrease these numbers? Sure. all my systems have offsets in the 10us range-- on the same lan as my time server. Mind you I do use chrony, not ntpd but even ntpd should be in a few 10s of usec. Can ntpd really get there? I'll try to query some good public servers to see what others are getting... Sure it can. It can get better than 30us. But why you are not getting it is impossible for us to say. I got it... As you saw above. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of GPS device
On Fri, Sep 02, 2011 at 09:50:05AM +0100, Miguel Gonçalves wrote: I found out the problem and just for the record I'll explain... The offset is larger than the delay because NTPd is using 10.0.2.254 (more on this switch later) as a time source and it shouldn't because it has two local stratum 1 clocks that are closer (0.170 ms vs 0.583 ms) are show less jitter. Anyway... to prove my point I removed 10.0.2.254 (the **internal** switch) from the configuration and here's the result of ntpq -p as of now: It would be interesting to see the root distances for the three servers. I think it's reasonable to expect the weights of the stratum 1 servers to be much higher than the weight of the third server, so the combined offset isn't affected much by the third server. But what I think it's happening here is the high default dispersion rate (15 ppm) increases the root distance so much that the weights are not that much different. Setting tinker dispersion to a more realistic value like 1 ppm (or even to 0.1 ppm in your case, see my comment below) should help. You can also use tos minclock 2 to limit the number of combined sources. $ ntpq -p 10.0.2.2 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 889 1024 3770.179 -0.066 0.083 *10.0.2.9.GPS.1 u 391 1024 3770.166 -0.084 0.051 Those are very good numbers for such high polling interval. Is the crystal oscillator thermally stabilized? In any case I'd suggest to use a shorter maximum poll interval. The default maxpoll is way too high for jitters normally seen on LANs if you want best accuracy. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: As I said, Without a PPS signal you will not get reasonable results. I would appreciate advice on solving the problem I have, not buying the equipment you wished I have. I don't need microsecond timing. I don't need millisecond timing. I have a need to have my clock set to about a second, which a NMEA only gps should be able to solve. The problem with NMEA only setups is that (I think) the firmware takes non-determinic time to convert its internal data to ASCII. This means the sentence is never output at the exact second tick. This error is enough to cause the GPS to fail NTPs clock selection algorithm. With only one source, how do I verify that your suspicion is correct? ntpq -p shows reach never changing from zero. OK, no Internet at the observatory. But try using pool servers while you are setting up and debugging. You will need additional ref clocks to verify your GPS. My problem is not that my GPS reported time is bad. My problem is that ntp is not showing it is processing any of the data. Running ntpd with the -n and -d flags shows that input from the GPS goes into ntp, but reach never changes from zero. On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: Also, don't expect any reasonable result until you connect the pulse per second to NTP. There is no PPS for the GPS18x PC. You only listed one line from the config file. Post more of it. And finally it helps a lot if you can add some pool servers to the config file. The only other line is the driftfile line. The computer is meant for control of a telescope and observatory, and isn't on the internet. Adding pool servers won't help for that reason. Given that ntp in debug mode shows gpsread showing NTP at least sees the GPRMC messages, can anyone sugguest why NTP never syncs? Is there additional debug flags that would be useful? ___ 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] garmin 18x and linux
Greg Hennessy greg.henne...@cox.net wrote: On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: As I said, Without a PPS signal you will not get reasonable results. I would appreciate advice on solving the problem I have, not buying the equipment you wished I have. I don't need microsecond timing. I don't need millisecond timing. I have a need to have my clock set to about a second, which a NMEA only gps should be able to solve. You will find (you have found) that by posting on this group, your message falls into the hands of a small group of people that will either base all their solutions on much more stringent requirements than you actually have (e.g. they don't consider using GPS serial messages because it is not possible to have millisecond precision with that), or they go on an on about how the requirements you post cannot be achieved at all and should be relaxed or be realized with atom clocks etc. This is usually partly the fault of the original poster (who omits requirements from the question or copies something from an external spec that mentions microseconds), but it is the fault of the people on this group, who are time nuts and blindly assume that everyone else is one too. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Greg Hennessy wrote: On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: As I said, Without a PPS signal you will not get reasonable results. I would appreciate advice on solving the problem I have, not buying the equipment you wished I have. I don't need microsecond timing. I don't need millisecond timing. I have a need to have my clock set to about a second, which a NMEA only gps should be able to solve. The problem with NMEA only setups is that (I think) the firmware takes non-determinic time to convert its internal data to ASCII. This means the sentence is never output at the exact second tick. This error is enough to cause the GPS to fail NTPs clock selection algorithm. With only one source, how do I verify that your suspicion is correct? ntpq -p shows reach never changing from zero. You need to check the gps on a pc with ntp working correctly and having a low offset. I have four GPS, BR304, Garmin 18x-LVC, Sure and Motorola Oncore. I've not yet coupled up the Oncore. The NMEA output of the BR304 has too much variation of +/- 100ms and I gave up on use as ntp timesource. The Garmin and Sure are probably around +/- 50ms and could be used by ntpd. The 3.70 firmware for the Garmin would be a big improvement but but it has PPS which gets me within a few us same as with the Sure. If you can't couple it to an internet connected pc, the next best is to use the computers local clock as reference with the gps nmea marked as 'no select' and running loopstats, peerstats and summary utilities from your ntpd distribution. David OK, no Internet at the observatory. But try using pool servers while you are setting up and debugging. You will need additional ref clocks to verify your GPS. My problem is not that my GPS reported time is bad. My problem is that ntp is not showing it is processing any of the data. Running ntpd with the -n and -d flags shows that input from the GPS goes into ntp, but reach never changes from zero. On 2011-09-02, Chris Albertson albertson.ch...@gmail.com wrote: Also, don't expect any reasonable result until you connect the pulse per second to NTP. There is no PPS for the GPS18x PC. You only listed one line from the config file. Post more of it. And finally it helps a lot if you can add some pool servers to the config file. The only other line is the driftfile line. The computer is meant for control of a telescope and observatory, and isn't on the internet. Adding pool servers won't help for that reason. Given that ntp in debug mode shows gpsread showing NTP at least sees the GPRMC messages, can anyone sugguest why NTP never syncs? Is there additional debug flags that would be useful? ___ 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] garmin 18x and linux
On 2011-09-02, Courtney Bane ntp-5...@cbane.org wrote: NTP isn't syncing because the GPS is reporting that it doesn't have a valid fix. $GPRMC,195342,V,3855.3261,N,07704.0687,W,,,010911,010.8,W*68 Thank you. I will try to move it to a place with more visibility. And if I can find the person who thought having a 'V' indicate not valid data, I will hit him with a nerf bat. Anyone want to guess where my telescope is located? ;) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of GPS device
2011/9/2 Miguel Gonçalves m...@miguelgoncalves.com: $ ntpq -p 10.0.2.2; ntpdc -c kerninfo 10.0.2.2 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS. 1 u 734 1024 377 0.182 -0.149 0.034 *10.0.2.9 .GPS. 1 u 235 1024 377 0.163 -0.055 0.029 pll offset: -8.5e-05 s pll frequency: 44.545 ppm maximum error: 0.151092 s estimated error: 3.8e-05 s status: 0001 pll time constant: 6 precision: 1e-06 s frequency tolerance: 512 ppm For the FreeBSD PBX server asterisk# ntpq -pn ; ntpdc -c kerninfo remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS. 1 u 843 1024 377 0.202 0.033 0.005 *10.0.2.9 .GPS. 1 u 991 1024 377 0.186 0.029 0.017 pll offset: 2.4324e-05 s pll frequency: 151.490 ppm maximum error: 1.03863 s estimated error: 2.1e-05 s status: 2001 pll nano pll time constant: 10 precision: 1e-09 s frequency tolerance: 496 ppm BTW, what is the difference between 2001 pll nano and 0001 in the status? The 0001 should have been followed by pll -- that it wasn't suggests the system which built the ntpdc you're using didn't have STA_PLL defined. I'm guessing that's a linux system, as there was a problem with STA_ and MOD_ defines in Linux headers not too long ago. 2001 and 0001 are both hexadecimal, though it's not obvious from context. The 0x1 bit is typically STA_PLL, meaning the kernel loop discipline is operating in phase-locked loop mode (PLL) as opposed to frequency-locked loop (FLL). The 0x2000 bit here is STA_NANO, meaning the kernel loop discipline is fed offsets to nanosecond precision, as opposed to microsecond precision used by earlier kernel loops. ntpdc -c kerninfo is one of the unfortunate examples of where using ntpdc built on the queried system can give better results than ntpdc built on a different system. The text decoded on the status: line from the hexadecimal value depends on ntpdc having been built against the same system as ntpd, because bitfields are decoded only when the relevant preprocessor macro is defined (such as STA_PLL or STA_NANO): #ifdef STA_NANO if (status STA_NANO) (void)fprintf(fp, nano); #endif When ntpdc is built on a system which doesn't have a nanosecond-precision kernel loop, STA_NANO is not defined, and that bit will not be decoded correctly when querying a ntpd built with STA_NANO defined. Recent 4.2.7 snapshots have a new ntpq -c kerninfo which is not so limited -- the decoding of bit values to keywords is handled by the remote ntpd, not ntpq. That works only if both your ntpd and ntpq are recent 4.2.7, however. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of GPS device
On 2011-09-02, Miguel Gon?alves m...@miguelgoncalves.com wrote: On 2 September 2011 07:56, unruh un...@wormhole.physics.ubc.ca wrote: Nope. It is completely unclear to me what your question is. Your 10.0.2.254 is an outside switch. I had several questions in my first message. Your assumption is wrong. You are telling me that a switch I installed in my rack and defined its many IP addresses is outside my company? Uau! I am not telling you anything. I am trying to find out what you are doing. 10.0.2.254 is a local as any machine in the 10.0.0.0/8 network. $ ntpq -p 10.0.99.99 remote refid st t when poll reach delay offset jitter == *10.0.2.10 .GPS.1 u 21 256 3770.1730.196 0.008 +10.0.2.9.GPS.1 u 93 256 3770.1750.191 0.014 +10.0.2.254 81.94.123.16 2 u 149 256 3770.583 -6.884 0.152 This tells me that your two GPS receivers are consistant with each other, but I have no idea why the offset is larger than the delay, and why the offsets are so large. On a lan, the offsets should be a factor of 20 or so less than what you are getting here. That the external router is 7 ms out just tells me that it is really poorly synced with the outside world. I found out the problem and just for the record I'll explain... The offset is larger than the delay because NTPd is using 10.0.2.254 (more on this switch later) as a time source and it shouldn't because it has two local stratum 1 clocks that are closer (0.170 ms vs 0.583 ms) are show less jitter. Anyway... to prove my point I removed 10.0.2.254 (the **internal** switch) from the configuration and here's the result of ntpq -p as of now: $ ntpq -p 10.0.2.2 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 889 1024 3770.179 -0.066 0.083 *10.0.2.9.GPS.1 u 391 1024 3770.166 -0.084 0.051 Still far too large an offset. Oddly enough, FreeBSD embedded machine with roughly the same NTP configuration shows better results $ ntpq -p 10.0.99.99 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 864 1024 3770.1930.025 0.301 *10.0.2.9.GPS.1 u 1012 1024 3770.1920.030 0.004 That is better, but still large. Regarding 10.0.2.254 it is an internal switch it is getting time over a cable connection from several sources Thank you. Why not have it also get its time from your intenal GPS sources? $ ntpq -p 10.0.2.254 remote refid st t when poll reach delay offset jitter == -ntp0.as34288.ne .PPS.1 u 391 1024 377 71.960 -1.029 0.270 *canon.inria.fr .GPSi. 1 u 707 1024 377 55.2200.199 0.700 +ntp1.inrim.it .CTD.1 u 359 1024 377 65.8600.091 1.830 +ntp-p1.obspm.fr .TS-3. 1 u 373 1024 377 55.110 -0.215 0.610 -metasweb01.admi .HBGi. 1 u 992 1024 377 73.290 -5.182 0.850 I can't control the network at my upstream provider and while my link is not saturated (far from that) my upstream provider links be could and there's nothing I can do about it except deploying local time sources as I did. I am checking my local time sources with some remote NTP stratum 1 servers at a fixed interval and plotting the results. I see that once in a while the offset to external time servers increases and I agree this has to be with network congestion but this happens at my ISP so there's not much I can do. This is a FreeBSD embedded PBX machine running Asterisk. The machine is mostly idle. What kind of offsets should I get with local machines? in the 10s of usec range max. Certainly less than the delay. tens of usec is good... Anyone here which can explain why NTP isn't getting that? How could we? Maybe you are running a virtual BSD machine, and thus the clocks are wonkey. Maybe you have lousy hardware. Who knows. No lousy hardware here but I think posting detailed hardware specifications won't help. No virtualization here also. Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets higher than 100 us. Is it possible to decrease these numbers? Sure. all my systems have offsets in the 10us range-- on the same lan as my time server. Mind you I do use chrony, not ntpd but even ntpd should be in a few 10s of usec. Can ntpd really get there? I'll try to query some good public servers to see what others are getting... Sure
Re: [ntp:questions] Accuracy of GPS device
On 2011-09-02, Miguel Gon?alves m...@miguelgoncalves.com wrote: Very good point really. This is probably why the FreeBSD machine performs better than the Linux one. The FreeBSD is embedded and doesn't produce a lot of heat while the Linux one is a Dell regular server. Perhaps removing the lid on the Linux server will improve things. Most systems have temperature sensors on the motherboard or on the cpu. Keep track of the temperature to see if it is temp problems. 10.0.2.2 has been running for quite a while and it doesn't seem to get lower offsets. Could it be because it's running Linux? I've heard Linux is not as good as FreeBSD for time keeping. It probably means there is jitter in the time from the servers. Offset doesn't measure the error in the internal time, it measures the estimated instantaneous error in the measurements of that time. A large error in the measurement will produce a proportionate, but smaller error in the actual time. OK. So I should look at ntptime? Or ntp -c kerninfo? I tried You can keep track of the offset over time. That will give you a measure. It is archived in the peerstats file-- the measured offset against each peer at every measurement. $ ntpq -p 10.0.2.2; ntpdc -c kerninfo 10.0.2.2 remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 734 1024 3770.182 -0.149 0.034 *10.0.2.9.GPS.1 u 235 1024 3770.163 -0.055 0.029 pll offset: -8.5e-05 s pll frequency:44.545 ppm maximum error:0.151092 s estimated error: 3.8e-05 s status: 0001 pll time constant:6 precision:1e-06 s frequency tolerance: 512 ppm So, despite 149 and 55 us I should consider the 38 us estimated error? For the FreeBSD PBX server asterisk# ntpq -pn ; ntpdc -c kerninfo remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u 843 1024 3770.2020.033 0.005 *10.0.2.9.GPS.1 u 991 1024 3770.1860.029 0.017 pll offset: 2.4324e-05 s pll frequency:151.490 ppm maximum error:1.03863 s estimated error: 2.1e-05 s status: 2001 pll nano pll time constant:10 precision:1e-09 s frequency tolerance: 496 ppm BTW, what is the difference between 2001 pll nano and 0001 in the status? Thanks a lot David! You were very helpful! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
Rob wrote: You will find (you have found) that by posting on this group, your message falls into the hands of a small group of people that will either base all their solutions on much more stringent requirements than you actually have (e.g. they don't consider using GPS serial messages because it is not possible to have millisecond precision with that), or they go on an on about how the requirements you post cannot be achieved at all and should be relaxed or be realized with atom clocks etc. NTP isn't designed to work at accuracies worse than a few 10s of milliseconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Fri, Sep 2, 2011 at 12:06 AM, unruh un...@wormhole.physics.ubc.cawrote: No. ntp can use the GPS nmea sentences to time the clock to a few 10s of ms. -- you may need to fudge the time offset to make up for the delay of the nmea sentence. Yes, maybe NTP can but not with this Garmin 18 unit. Some GPSes are better than others. And like I said very good units are available for not much money. These Garmin units have problems with their NMEA timing. I tried to use an even earlier unit and had the same result. Not worth knocking your head on a wall when good timing units are available for cheap. The problem is not just with the timing of the serial data coming out of the GPS. There are FIFO buffers in the Serial port in the computer and in the OS.PPs is handled by a very low latency interrupt driven interface that tie stamps the PPS. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-02, David Woolley david@ex.djwhome.demon.invalid wrote: Rob wrote: You will find (you have found) that by posting on this group, your message falls into the hands of a small group of people that will either base all their solutions on much more stringent requirements than you actually have (e.g. they don't consider using GPS serial messages because it is not possible to have millisecond precision with that), or they go on an on about how the requirements you post cannot be achieved at all and should be relaxed or be realized with atom clocks etc. NTP isn't designed to work at accuracies worse than a few 10s of milliseconds. ?? Where does this come from? While it is true that there is the 128ms rule ( which I believe can be adjusted) but where is this coming from? And besides, Garmin GPS nmea can control to better than 10ms. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On 2011-09-03, Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Sep 2, 2011 at 12:06 AM, unruh un...@wormhole.physics.ubc.cawrote: No. ntp can use the GPS nmea sentences to time the clock to a few 10s of ms. -- you may need to fudge the time offset to make up for the delay of the nmea sentence. Yes, maybe NTP can but not with this Garmin 18 unit. Some GPSes are better than others. And like I said very good units are available for not much money. These Garmin units have problems with their NMEA timing. I tried to use an even earlier unit and had the same result. Not worth knocking your head on a wall when good timing units are available for cheap. The problem is not just with the timing of the serial data coming out of the GPS. There are FIFO buffers in the Serial port in the computer and in the OS.PPs is handled by a very low latency interrupt driven interface that tie stamps the PPS. I do not argue that pps is not better than nmea. It is. But that is irrelevant. The question is whether or not nmea can be used to control the system to a few ms. If you are saying that this particular nmea unit has such huge fluctuations, then it would be good to have some backing for that. The FIFO buffers are certainly able to better than 100ms. And the OS does not take that much time. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
