Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Daniel O'Connor wrote: > > >> On 17 Jun 2022, at 12:52, Jim Pennino wrote: >> Daniel O'Connor wrote: >>> >>> >>>> On 17 Jun 2022, at 00:07, David Taylor >>>> wrote: >>>> >>>> On 16/06/2022 10:00, Thiebaud HUMBERT wrote: >>>>> To do the inversion, I just changed the "Pulse Mode" parameter to >>>>> "Falling edge" from "Rising edge". >>>>> The offset induced by the "pulse length" has disappeared. >>>>> But there is still an offset of around 10.3ms, which I think is induced >>>>> by USB as explained in this article about other chipsets >>>>> (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html) >>>> >>>> Yes, Thiebaud, USB is not good enough for PPS signals! >>> >>> This is absolutely false. >>> >>> If you are using it for NTP then GPS+PPS over USB is quite adequate (from >>> personal experience). >> >> As USB is a two wire interface, there is no such thing as PPS over USB. > > The fact USB only has 2 data lines is irrelevant to wether you can send PPS > over USB. > >> You of course can get the ASCII data over USB, but to get a PPS signal >> you in general have to hack a USB GPS and add a signal wire for PPS then >> hack some interface on the computer to accept PPS. > > This is absolutely not true in any meaningful sense. OK, then to which of the USB connector pins do you connect the PPS signal to get "PPS over USB"? -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Daniel O'Connor wrote: > > >> On 17 Jun 2022, at 00:07, David Taylor >> wrote: >> >> On 16/06/2022 10:00, Thiebaud HUMBERT wrote: >>> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling >>> edge" from "Rising edge". >>> The offset induced by the "pulse length" has disappeared. >>> But there is still an offset of around 10.3ms, which I think is induced by >>> USB as explained in this article about other chipsets >>> (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html) >> >> Yes, Thiebaud, USB is not good enough for PPS signals! > > This is absolutely false. > > If you are using it for NTP then GPS+PPS over USB is quite adequate (from > personal experience). As USB is a two wire interface, there is no such thing as PPS over USB. You of course can get the ASCII data over USB, but to get a PPS signal you in general have to hack a USB GPS and add a signal wire for PPS then hack some interface on the computer to accept PPS. If all you need is accuracy in the 2 millisecond range, most recent USB GNSS dongles will achieve that without PPS. -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] Re: GPS+PPS vs NTP server, why a huge offset ?
chris wrote: > On 06/16/22 16:20, Jim Pennino wrote: >> Thibaut HUMBERT wrote: >>> Le jeudi 16 juin 2022 à 16:37:33 UTC+2, David Taylor a écrit : >>>> On 16/06/2022 10:00, Thiebaud HUMBERT wrote: >>>>> To do the inversion, I just changed the "Pulse Mode" parameter to >>>>> "Falling edge" from "Rising edge". >>>>> The offset induced by the "pulse length" has disappeared. >>>>> But there is still an offset of around 10.3ms, which I think is induced >>>>> by USB as explained in this article about other chipsets >>>>> (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html) >>>> Yes, Thiebaud, USB is not good enough for PPS signals! >>>> >>>> See if your motherboard has a true serial port - perhaps just as a header >>>> but >>>> not a back connector. If not, just set the offset of the PPS to ~10.3 >>>> milliseconds (10.3 - IIRC the offsets are in milliseconds but please >>>> check). >>>> Plus or minus 10.3, try it and see! Not perfect, but better than nothing. >>>> >>>> You might find better results using that GPS/PPS with a Raspberry Pi as a >>>> stratum-1 server and offering that as a server on your LAN. >>>> >>>> Cheers, >>>> David >>>> -- >>>> Cheers, >>>> David >>>> Web: http://www.satsignal.eu >>> >>> >>> I have a serial port, but I don't know how to convert the PPS output (0 / >>> 3.3V) to RS232 (-5V / +5V). >> >> You go to amazon.com and search for "level converter 3.3 to 5". >> >> > > You need a ttl to rs232 converter. That is what a level converter 3.3 to 5 is. The RS-232 standard mark is +3 to +15 V and space is -15 to -3 V, which means a 0/3v level converter to -5/+5V meets the RS-232 standard. -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
[questions] Re: GPS+PPS vs NTP server, why a huge offset ?
Thibaut HUMBERT wrote: > Le jeudi 16 juin 2022 à 16:37:33 UTC+2, David Taylor a écrit : >> On 16/06/2022 10:00, Thiebaud HUMBERT wrote: >> > To do the inversion, I just changed the "Pulse Mode" parameter to "Falling >> > edge" from "Rising edge". >> > The offset induced by the "pulse length" has disappeared. >> > But there is still an offset of around 10.3ms, which I think is induced by >> > USB as explained in this article about other chipsets >> > (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html) >> Yes, Thiebaud, USB is not good enough for PPS signals! >> >> See if your motherboard has a true serial port - perhaps just as a header >> but >> not a back connector. If not, just set the offset of the PPS to ~10.3 >> milliseconds (10.3 - IIRC the offsets are in milliseconds but please check). >> Plus or minus 10.3, try it and see! Not perfect, but better than nothing. >> >> You might find better results using that GPS/PPS with a Raspberry Pi as a >> stratum-1 server and offering that as a server on your LAN. >> >> Cheers, >> David >> -- >> Cheers, >> David >> Web: http://www.satsignal.eu > > > I have a serial port, but I don't know how to convert the PPS output (0 / > 3.3V) to RS232 (-5V / +5V). You go to amazon.com and search for "level converter 3.3 to 5". -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
Re: [ntp:questions] ntp pool servers disappear - more data
William Unruh wrote: > On 2021-06-25, Jim Pennino wrote: >> chris wrote: >>> On 06/25/21 17:28, Jim Pennino wrote: >> > ... >> >> Actually what I plan to do is to put a $14 USB GPS on the machine that >> already has a PPS GPS attached and do away with ALL external machines. >> >> If there are two GPS receivers attached to the machine I have a backup >> if one receiver fails. > > Two is in general bad, because your machine has no idea which the better > one is and is likely to pick the GPS ratehr than the PPS. It will pick the one with PPS as the jitter is much better. Tested and verified. >> As GPS receivers are highly unlikely to fail in some wonky mode, e.g. time >> being off by some large amount, but to fail completely, there is no need >> for any other reference source while I replace the failed receiver. > > Since both are attached to the same machine, the probability of common > mode errors become high. The cleaner unpluggin the line which feeds both > receivers, etc. Common mode errors from what? The GPS receivers connect to separte ports on different interal busses. >> Now if there is a Carrington-class coronal mass ejection or WWIII >> breaks out, I will lose all time references but I will have lots of >> other things to worry about that are much more important than the >> computer clock and it is likely that all internet access will also be >> down. > > That of course is a very very general common mode error, and is > extremely hard to counteract. More likely are those in your office, on > your floor, or in your building. The last time there was a Carrington-class coronal mass ejection that hit the Earth was 1859. >> >> Then on two other machines I attach two $14 USB GPS receivers and no >> external references. > > Remember pps is a factor of about 1 more accurate than than NMEA > GPS. Yeah, so? How many times do I have to say I DO HAVE A GPS WITH REAL PPS? >> These three machines then provide time for all other machines on my >> network. The three machines will provide the redundancy needed for when >> one of those machines gets rebooted for updates/upgrades. > > Again, make sure they are all on separate electrical circuits, > prefereably also in separate buildings. Why? This is a hobby, not the New York Stock exchange. >> Done. >> >> The only foreseeable change to that I might ever make is if and when USB >> 3.0 GPS receivers with PPS become cheap and available, I might swap out >> the USB receivers with one of those just to see how well they work. > > The usb level is irrelevant. It is the PPS that is important. And pps > receivers are also coming down. In fact that UBLOCK probably has a PPS > output, which the manufacturer never bothered to hook upon the puck. > It is hard to feed ppd over usb with any accuracy. However a separate > pps line which you can attach to some irq line on the computer is > probably possible even for that cheap puck. Sigh, the USB level is highly relevant. There is nowhere in USB 2 interface to "hook up" a PPS signal. As USB does not have any lines other than serial data, any PPS signal would have to be emulated in the interface as two virtual serial ports and basically you can not do that with USB 2. With USB 3 you CAN have multiple virtual serial ports. Also, USB 3 is orders of magnitude faster than USB 2, which means the latency and jitter of the signals is much better. >> Yes, this scheme only gets my machines to within 10s of milliseconds to >> the actual time, but that is good enough for me. >> >> If I needed better, I would buy one of the $685 GPS GNSS Disciplined >> Rubidium clocks off ebay and get time to the nanosecond. > > There is still a wide gap between namosecond and 10s of milliseconds. > "If walking is too slow, I can always buy a X15 to get there." Actually > the difference there is far less than the difference between ns and msec. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear - more data
William Unruh wrote: > On 2021-06-25, Jim Pennino wrote:A >> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A >> public server that does NOT request use of DNS which yields 3 sources of >> time without using a pool or DNS lookups. > > Not at all sure what you are suggesting. DNS is a way of translating > names to IP addresses, which your machine MUST use to talk to a remote > machine not on your network. The remote machine has nothing to do with > this. Now some remote machines will as for the name associated with the > IP address of machines sending the remote machine a query, to try to see > if someone is spoofing the IP address, but as far as I know ntpd does > not do that. Takes too much time and would make the time responses > really bad. This is not quite correct. If a program has an IP address, as in put the IP address in ntp.conf, then the program already has the IP address and does NOT need to do a DNS query ever. Using a IP address for ntp pools is a bad idea as someone else has said. However, there are lists of publicly available ntp servers which list the owners preference for DNS usage. Some servers want you to use the fully qualified domain name and some servers don't care if you use the IP address. >> Or for $28/machine I could use 2 USB GPS receivers and my machine with >> PPS GPS, which also provides 3 sources of time without any network >>e access at all. > > Sure. The problem of course is that that $28 onlybuys you a pretty bad > time source (pretty bad meaning milliseconds rather than microseconds or > nanoseconds), which for most of man's history on this earth is > absolutely astonishingly, and inconceivably good. Except you are forgetting a few things: 1. I have a ntp server with a real PPS GPS attached which is good to microseconds. 2. My actual real time requirement is in the 10s of millisecond range. 3. Any accuracy past the requirements of number 2 is purely out of curiosity. > Note that hanging all three off of one machine can lead to conflict > between them as to interrupt processing, leading to degraded time > performance. But again that is at the microsecond level, not milli or > second level. As each will go into a separate plug, that is HIGHLY unlikely to happen. I never said anything about hanging three receivers on one machine, as two receivers are more than sufficient for normal, i.e. WWIII isn't happening, times. > Of course if you machine is at the bottom of a mineshaft in mountains, > gps receivers are pretty useless. Or in the basement of a highrise > without windows. At one place I worked at where the computer room was in the basement and they did care about accurate time, they bought a commercial ntp server black box that cost several thousands of dollars and ran a cable to the roof for the antenna. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear - more data
chris wrote: > On 06/25/21 17:28, Jim Pennino wrote: >> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A >> public server that does NOT request use of DNS which yields 3 sources of >> time without using a pool or DNS lookups. >> >> Or for $28/machine I could use 2 USB GPS receivers and my machine with >> PPS GPS, which also provides 3 sources of time without any network >> access at all. >> >> > > Your choice, but when I registered the ntp server here with the pool, I > just used the fixed ip address. That's what they ask for and it does > bypass dns altogether. The less translation the better, unless > you really need it... Actually what I plan to do is to put a $14 USB GPS on the machine that already has a PPS GPS attached and do away with ALL external machines. If there are two GPS receivers attached to the machine I have a backup if one receiver fails. As GPS receivers are highly unlikely to fail in some wonky mode, e.g. time being off by some large amount, but to fail completely, there is no need for any other reference source while I replace the failed receiver. Now if there is a Carrington-class coronal mass ejection or WWIII breaks out, I will lose all time references but I will have lots of other things to worry about that are much more important than the computer clock and it is likely that all internet access will also be down. Then on two other machines I attach two $14 USB GPS receivers and no external references. These three machines then provide time for all other machines on my network. The three machines will provide the redundancy needed for when one of those machines gets rebooted for updates/upgrades. Done. The only foreseeable change to that I might ever make is if and when USB 3.0 GPS receivers with PPS become cheap and available, I might swap out the USB receivers with one of those just to see how well they work. Yes, this scheme only gets my machines to within 10s of milliseconds to the actual time, but that is good enough for me. If I needed better, I would buy one of the $685 GPS GNSS Disciplined Rubidium clocks off ebay and get time to the nanosecond. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear - more data
chris wrote: > On 06/25/21 04:08, Jim Pennino wrote: >> William Unruh wrote: >> >> >> >>> I suspect it is the number of times that ntpd tries to contact the >>> server and fails rather than the time that is important. You could try >>> putting the server offline and then online again (I use chrony so do not >>> remember if ntpd has that option). >> >> No, it doesn't. >> > > You could use a one line cron script to restart every day, week, > whenever... Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a public server that does not request use of DNS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear - more data
William Unruh wrote: > On 2021-06-25, Jim Pennino wrote: >> chris wrote: >>> On 06/25/21 04:08, Jim Pennino wrote: >>>> William Unruh wrote: >>>> >>>> >>>> >>>>> I suspect it is the number of times that ntpd tries to contact the >>>>> server and fails rather than the time that is important. You could try >>>>> putting the server offline and then online again (I use chrony so do not >>>>> remember if ntpd has that option). >>>> >>>> No, it doesn't. >>>> >>> >>> You could use a one line cron script to restart every day, week, >>> whenever... >> >> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a >> public server that does not request use of DNS. > > You could try specifying the server by IP rather than by name, so DNS is > not needed. Of course this rule out using pool, unless you put them in > by IP. DNS is just used to translate names to IP, so if you use IP, then > DNS is not needed. Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A public server that does NOT request use of DNS which yields 3 sources of time without using a pool or DNS lookups. Or for $28/machine I could use 2 USB GPS receivers and my machine with PPS GPS, which also provides 3 sources of time without any network access at all. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear - more data
William Unruh wrote: > I suspect it is the number of times that ntpd tries to contact the > server and fails rather than the time that is important. You could try > putting the server offline and then online again (I use chrony so do not > remember if ntpd has that option). No, it doesn't. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear - more data
Jim Pennino wrote: > I was checking the stability of a new USB GPS refclock on a server which > is configured to use the GPS, servers from the ntp pool, and another server > of mine that has a PPS GPS receiver. > > I noticed that almost all the pool servers had disappeared. > > I then checked other machines that use my "good" server and the ntp > pool; most all of the pool servers had also disappeared on those > machines. > > This is a mix of PC linux, rasberry pi linux, rasberry pi buster, and > Windows 10 machines with Meinberg, all with the latest ntp from their distros. > > Long story short: I realized I had had a network outage and tested the > theory that was the cause. It was. > > It seems that any server in ntp.conf that is specified as a name, as > the pool servers are, will after a sufficiently long DNS outage just > disappear and not come back after the outage without restarting ntp. > > It would seem to me that ntp should only need to do a DNS lookup on > startup and from then on continue to use the address found. > > But that is not how ntp works. > > Anyway, the bottom line is that if the pool is your only source of time > and if there is a DNS failure for a sufficiently long time, you will > lilely not have any source of time afterwards. > > As for the USB GPS I was testing, it is called a VK-162 G-Mouse > available from Amazon for $14, uses the Windows 10 native driver so it > works with Meinberg ntp, and keeps the time within single digit > milliseconds without any other servers. Further testing shows the following: I took a machine and ran watch -p -n 10 ntpq -pn to monitor ntp status. I then pulled the network connection from the machine. After about 7 minutes the pool servers started to disappear. If the machine was reconnected to the network within about 15 minutes, the pool servers would reappear. If the machine was off the network for more than about 15 minutes, the pool servers do NOT reappear until ntp is restarted. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear
On Thu, Jun 24, 2021 at 10:04:32AM -0400, Danny Mayer wrote: > On 6/23/21 10:26 AM, Jim Pennino wrote: > > It seems that any server in ntp.conf that is specified as a name, as > > the pool servers are, will after a sufficiently long DNS outage just > > disappear and not come back after the outage without restarting ntp. > > > > It would seem to me that ntp should only need to do a DNS lookup on > > startup and from then on continue to use the address found. > > > > But that is not how ntp works. > > No, you shouldn't assume that once you have an IP address you can decide to > use it forever. The owner of any server has the right to change the DNS > entry used to point to a different server. We have had no end of problems > with clients bombarding an IP address with packets long after it has stopped > serving time. All well and good but essentially irrelevant to what I posted. > If you have a DNS issue then you should address that. How do I address network failures by my ISP? Should I stomp my feet or what? > ntpd should pick up > new addresses if one is available. If it doesn't do that please file a bug > report. Maybe it should, and I think it should, but it doesn't. Where do I file this bug report? -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear
William Unruh wrote: > On 2021-06-23, Jim Pennino wrote: >> William Unruh wrote: >>> On 2021-06-23, Jim Pennino wrote: >>> ... >>>> >>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse >>>> available from Amazon for $14, uses the Windows 10 native driver so it >>>> works with Meinberg ntp, and keeps the time within single digit >>>> milliseconds without any other servers. >>> >>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy, >>> after correction for the NMEA delay is probably in the 10s of ms, not >>> their claimed microsecond. But certainly for most people ms is more than >>> enough accuracy. >>> >> >> Correct, no PPS. >> >> From short term (day or so) testing looking at peerstats data: >> >> Samples: 3914 >> Avg offset: -0.00190137 >> Std dev:0.00921412 > > The problem is that that does not test the accuracy, just jitter. Ie, > the time could be off by a century, but it is repeatable, so ntp says > that the offset and standard deviation is small. > You need to compare with another time source that is known to be more > accurate than yours. Typically nmea signals are delivered late and the > length of the signal is long delaying things still more, expecially if > you choose an nmea sentence which reports lots of information, not just > the time. I didn't bother with the full story as I wanted to be brief unless someone had specific questions. A bit more detail: For testing purposes, ntp was configured to use my machine that has a real PPS GPS and about a half dozen public servers, most of them stratum 1. I also enabled all the statistics files. Initial, i.e. an hour or so, testing was with standard linux utilities, i.e. ntpq, ntpstat, ntptime, for a sanity check and a tweek of the fudge value, which came out to 0.027. After several days I ran a pile of sed/awk scripts to look at the statistics files and came to the conclusion that the absolute time error was always less than about 5 ms and typically around 1 ms, which for $14 I condider good enough. FYI I have tested a several other generic USB GPS pucks and found the jitter to be over an order of magnitude greater than this device with fudge times in the order of 0.500 and time errors in the several 10s of ms. >> >> ntpq typically shows offset and jitter at about 1 and the satellites in >> view are usually 14 or more with the puck in a window sill. > > And that means that the processor in the gps receiver has to work harder > and delays the report of the NMEA even longer. Now of course you may not > care -- 100ms may be perfectly acceptable (It is far more accurate than > a wrist watch for example) and then my comments are entirely irrelevant. > If you want higher accuracy however, then they start to become relevant. > Hook it up to the network and use some of the low stratum sources to get > the time. That should be accurate probably to better than a ms. That > will allow you to calibrate your gps delay and tell ntp to subtract the > persistant offset from the gps signal, and improve your accuracy. > > Again that is only important if you have some reason to care. Again, if > accuracy to the nearest second is good enough, ignore this. See above. I am assuming that the fudge time of 0.027 versus the typical generic GPS puck time of 0.500 means this thing is processing things much faster. FYI all this is done on a USB 2.0 interface. >> >> That is from a linux PC where there are more tools for testing things. >> >> The reason I bought it is that it is advertised to work with the Windows >> native USB driver, which produces a virtual com port, which makes it >> usable with Meinberg ntp without any other drivers or software. >> >> I have yet to do any Windows testing other than to verify it does work, >> but I see no reason why Windows would be much different. > > Probably not. But again, testing it against some good network ntp > sources should give you an idea of how well it is doing, if that is > important. > Of course we all like our stuff to be better than others. My system, > using pps from a gps is probably goot to a few microseconds. Do I need a > few microsecond accuracy. No. Even ms accuracy would be way more than I > need. But I like seeing how far I can push stuff. My only defence is > "its a hobby". >From my analysis of my real PPS GPS system, the absolue time on that machine is typically accurate to about a microsecond with a standard deviation of about 0.8 us. The time accuracy I actually need for stuff I do is in the order of about 50 ms, but like you, I too like seeing how far I can push stuff, especially for $14. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear
William Unruh wrote: > Certainly if it used the usb channel at its full speed, that should be > fine. I always thought that gps ran at serial port speeds, but clearly > that is not true. Well, stty -F /dev/ACM0, which is where this puck shows up as opposed to the generic /dev/USB0, says speed 9600 baud. I know of no way absent some sort of USB break out board and an oscilloscope to determine if that is actually true. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp pool servers disappear
William Unruh wrote: > On 2021-06-23, Jim Pennino wrote: > ... >> >> As for the USB GPS I was testing, it is called a VK-162 G-Mouse >> available from Amazon for $14, uses the Windows 10 native driver so it >> works with Meinberg ntp, and keeps the time within single digit >> milliseconds without any other servers. > > Looks like a nice cheap receiver-- no PPS I assume so that accuracy, > after correction for the NMEA delay is probably in the 10s of ms, not > their claimed microsecond. But certainly for most people ms is more than > enough accuracy. > Correct, no PPS. >From short term (day or so) testing looking at peerstats data: Samples: 3914 Avg offset: -0.00190137 Std dev:0.00921412 ntpq typically shows offset and jitter at about 1 and the satellites in view are usually 14 or more with the puck in a window sill. That is from a linux PC where there are more tools for testing things. The reason I bought it is that it is advertised to work with the Windows native USB driver, which produces a virtual com port, which makes it usable with Meinberg ntp without any other drivers or software. I have yet to do any Windows testing other than to verify it does work, but I see no reason why Windows would be much different. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntp pool servers disappear
I was checking the stability of a new USB GPS refclock on a server which is configured to use the GPS, servers from the ntp pool, and another server of mine that has a PPS GPS receiver. I noticed that almost all the pool servers had disappeared. I then checked other machines that use my "good" server and the ntp pool; most all of the pool servers had also disappeared on those machines. This is a mix of PC linux, rasberry pi linux, rasberry pi buster, and Windows 10 machines with Meinberg, all with the latest ntp from their distros. Long story short: I realized I had had a network outage and tested the theory that was the cause. It was. It seems that any server in ntp.conf that is specified as a name, as the pool servers are, will after a sufficiently long DNS outage just disappear and not come back after the outage without restarting ntp. It would seem to me that ntp should only need to do a DNS lookup on startup and from then on continue to use the address found. But that is not how ntp works. Anyway, the bottom line is that if the pool is your only source of time and if there is a DNS failure for a sufficiently long time, you will lilely not have any source of time afterwards. As for the USB GPS I was testing, it is called a VK-162 G-Mouse available from Amazon for $14, uses the Windows 10 native driver so it works with Meinberg ntp, and keeps the time within single digit milliseconds without any other servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pi 4 and Ultimate hat weirdness
On Tue, Jan 26, 2021 at 11:06:41AM +, David Taylor wrote: > On 25/01/2021 16:33, Jim Pennino wrote: > [] > > But the PPS has a lot of jitter. Note the xPPS(0) in the ntpq line. > > > []> The default for NTP is 4800 baud, but I am running at 9600 and there is > > no loss of data. > > > > It doesn't make any difference if I run the 20 driver in mode 1 (lower > > bits) or 13, it still has the uncorrectable offset problem. > > > > Right now, having been running for a little over 12 hours, ntpq shows: > > > > x127.127.20.0.GPS.0 l 14 16 3350.000 -761.21 > > 307.138 > > *127.127.28.0.SHM.0 l 12 16 3770.000 -30.575 > > 35.029 > > o127.127.22.0.PPS.0 l3 16 3770.000 -0.378 > > 0.034 > > > > I'm going to let it run for several days without disturbing anything. > > > > I doubt it will keep the 28 clock selected with that high jitter. > > If the PPS has a lot of jitter I would try to check it with an > oscilloscope. Possibly there is a poor connection, or if you are using > a very long cable (unlikely) there could be capacitive coupling between > signals. How did you correct the problem for your "over 12 hours" ntpq > report? The ultimate hat is a GPS board that has a connector that sits on top of the Raspberry Pi 4 GPIO connector. The "cable length" is about 1/4 of an inch. I'm don't know what you mean by "over 12 hours" ntpq report?". > I would suggest a much higher baud rate, and disabling sentences other > than $GPRMC. You don't then need any lower bits set. If you mean disabling sentences from the GPS board, I can find no documentation on how to control anything on the GPS. > Are you sure that the type 20 and type 28 driver can co-exist? I note > that minicom can't access ttyAMA0 when gpsd is using it. Well, they seem to be co-existing, but as I said before, I started with just the type 20 driver with NO gpsd and there does not seem to be any difference either way. All the message types show up in peerstats. Running both the type 20 and type 28 drivers at the same time was an act of desperation. sudo cat /dev/ttyAMA0 with gpsd running shows data. > From data I'm recording from another GPS I see offsets between -100 and > +100 milliseconds from a nominal, with an older Skylab SKG16B device > running at 9600 baud. > > Cheers, > David > -- > SatSignal Software - Quality software for you > Web: https://www.satsignal.eu > Email: david-tay...@blueyonder.co.uk > Twitter: @gm8arv > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pi 4 and Ultimate hat weirdness
On Mon, Jan 25, 2021 at 10:11:03AM -0800, Gary E. Miller wrote: > Yo Jim! > > On Sun, 24 Jan 2021 18:06:12 -0800 > Jim Pennino wrote: > > > I got a Pi 4 and Adafruit ultimate gps hat to play with and decided > > to see how good it was as a timekeeper. > > You will find it pretty good. With a bit of work it can keep > system time stable to about 100 ns. > > > First weird thing; xgps does not show a skyview but both xgps and cgps > > show at least 10 satellites in use. > > Before that: > > What versions of gpsd and xgps? gpsd -V gpsd: 3.17 (revision 3.17) ntpd --version ntpd 4.2.8p12@1.3728-o (1) > > From your distro of from source? Distro, totally up to date. > > Did xgps give any warnings on the command line when started from the > command line? xgps Gtk-Message: 13:45:00.966: Failed to load module "canberra-gtk-module" TypeError: Couldn't find foreign struct converter for 'cairo.Context' Makes me think the distro is missing a dependancy. > > > I don't care too much about this one as AFAIK xgps is broken on Pi. > > Nope. Works for me. On buster? > > > Second weird thing; I started the 20 driver in mode 0. ntpq showed > > lots of syntax errors on the $GPGGA message. > > Before that: > > How are you running gpsd? Root? With what command line? sudo systemctl start gpsd sudo systemctl start gpsd.socket > > What version of ntpd? From where? As above. > > How are you running ntpd? Root? With what command line? sudo systemctl start ntp ps -eo euser,egroup,args | grep gps gpsd dialout /usr/sbin/gpsd -n -r /dev/ttyAMA0 /dev/pps0 ps -eo euser,egroup,args | grep ntp ntp ntp /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 115:124 > > Then please copy the errors here. > > > I changed the mode to 29 to deselect $GPGGA; no errors from ntpq. So > > maybe it was a satellite thing, but whatever it was, no more errors. > > We can only guess without seeing what you see. Not a big deal to me if ignoring $GPGGA makes the errors go away. > > > Third and biggest weird thing; I had fudge 127.127.20.0 flag1 1 time1 > > 0.001 in ntp.conf. After everything settled down, the clock was > > showing an offset of -1043. OK, So I changed time1 to 1.044 even > > though it looked too big. ntp wouldn't lie to me... > > It can takes days for ntpd to calibrate your system. How long did you > wait? It your serial port rate from your GNSS is slow, then you can > easily get off one second. Or maybe the receiver does not have the > current leap second yet. The GPS has been powered up since I stuck in the battery for the on board RTC 5+ days ago. How long does it typically take a receiver to have the current leap second. BTW, the GPS has an external antenna with a good view of the sky and cgps alway shows 11+ satellites in view and always 8+ in use. > > > After everything settled down this time the offset was showing an > > average of -738. For grins and giggles I set time1 to 0.738 and now > > the average offset is -584. > > > > time1 offset > > 0.001 -1043 > > 1.044 -738 > > 0.738 -584 > > > > It seems there is no way to get time1 to correct the offset. > > I hope you waited an hour or more between changes? ntpd is a > phase locked loop, it takes time to settle. Of course. > > > Also the jitter times look high. At this moment ntpq shows: > > That is to be expected early on. Don't bother to look at the > jitter until the offset is stable for hours. Right now ntp has been running for about 18 hours. Here is what ntpq is showing now: *127.127.20.0.GPS.0 l7 16 110.000 -886.78 27.361 x127.127.28.0.SHM.0 l5 16 3770.000 -100.40 36.248 x127.127.22.0.PPS.0 l9 16 3770.000 -4.458 0.720 And this is from peerstats: showpeerstats 127.127.20.0 Count:4133 Avg offset:-0.514542 Std dev:0.257913 Avg Skew: 0.237029 Std dev:0.149433 127.127.22.0 Count:4945 Avg offset: 0.00498037 Std dev:0.0291266 Avg Skew: 0.00530061 Std dev:0.0110748 127.127.28.0 Count:4948 Avg offset: 0.00237325 Std dev:0.080877 Avg Skew: 0.0593658 Std dev:0.0643203 > > > For comparison, a GlobalSat BU-353-S4 USB GPS on a PC ubuntu system > > shows: *SHM(0) .SHM.0 l3 16 3770.000 > > -0.728 1.356 > > Which I assume had been running for months. Yes and no; the system was rebooted 4 days before. > > > Anyone got any suggestions other than to trash the Ulitmate hat and > > get another GlobalSat USB? > > The Ultimate HAT is a much better GNSS than the GlobalSat. The SiRF 4 > is not ve
Re: [ntp:questions] Pi 4 and Ultimate hat weirdness
On Mon, Jan 25, 2021 at 11:03:46AM +, David Taylor wrote: > On 25/01/2021 02:06, Jim Pennino wrote: > > I got a Pi 4 and Adafruit ultimate gps hat to play with and decided to see > > how good it was as a timekeeper. > > > > First weird thing; xgps does not show a skyview but both xgps and cgps > > show at least 10 satellites in use. > > > > I don't care too much about this one as AFAIK xgps is broken on Pi. > > > > Second weird thing; I started the 20 driver in mode 0. ntpq showed lots > > of syntax errors on the $GPGGA message. > > > > I changed the mode to 29 to deselect $GPGGA; no errors from ntpq. So maybe > > it was a satellite thing, but whatever it was, no more errors. > > > > Third and biggest weird thing; I had fudge 127.127.20.0 flag1 1 time1 0.001 > > in ntp.conf. After everything settled down, the clock was showing an > > offset of -1043. OK, So I changed time1 to 1.044 even though it looked > > too big. ntp wouldn't lie to me... > > > > After everything settled down this time the offset was showing an average > > of -738. For grins and giggles I set time1 to 0.738 and now the average > > offset is -584. > > > > time1 offset > > 0.001 -1043 > > 1.044 -738 > > 0.738 -584 > > > > It seems there is no way to get time1 to correct the offset. > > > > Also the jitter times look high. At this moment ntpq shows: > > > > xGPS_NMEA(0) .GPS.0 l6 16 3670.000 -849.36 > > 25.536 > > *SHM(0) .SHM.0 l4 16 3770.000 -106.55 > > 72.688 > > xPPS(0) .PPS.0 l4 16 3770.000 18.702 > > 18.812 > > > > For comparison, a GlobalSat BU-353-S4 USB GPS on a PC ubuntu system shows: > > *SHM(0) .SHM.0 l3 16 3770.000 -0.728 > > 1.356 > > > > Anyone got any suggestions other than to trash the Ulitmate hat and get > > another GlobalSat USB? > > I've been playing with the RPi4 recently and had mostly success. I've > used a couple of different devices including the Uputronics/ublox HATs. > > GPSD has proved problematical, and the only satisfactory way is not to > use the one in the distribution, but to build from scratch. > > https://www.satsignal.eu/raspberry-pi/UpdatingGPSD.html I have tried it without gpsd using just the type 20 and 22 drivers; no difference in the weird offset that can not be calibrated out. > > It's the PPS which matters, and for that I've found it most satisfactory > to use the type 22 driver. For time of day I tend to use other local or > Internet servers. I've been experimenting with an RTC, but > experimenting with its unstabilised drift first to understand how well > it might behave left for a day, week or month. One of the reasons for trying the ultimate hat is the on board, battery backed up, clock so there is some reasonable reference at boot. But the PPS has a lot of jitter. Note the xPPS(0) in the ntpq line. > > https://www.satsignal.eu/raspberry-pi/Uputronics-RTC.html > > Offsets near 1 second introduce an ambiguity and I would suggest > avoiding such devices. However, I would expect the AdaFruit to be good > - have you set a sufficiently high baud rate? Recent ublox are being > set to 115200 to capture all the data. IIRC, $GPRMC alone is enough. The default for NTP is 4800 baud, but I am running at 9600 and there is no loss of data. It doesn't make any difference if I run the 20 driver in mode 1 (lower bits) or 13, it still has the uncorrectable offset problem. Right now, having been running for a little over 12 hours, ntpq shows: x127.127.20.0.GPS.0 l 14 16 3350.000 -761.21 307.138 *127.127.28.0.SHM.0 l 12 16 3770.000 -30.575 35.029 o127.127.22.0.PPS.0 l3 16 3770.000 -0.378 0.034 I'm going to let it run for several days without disturbing anything. I doubt it will keep the 28 clock selected with that high jitter. > > Just some random thoughts, not a definitive solution! > > Cheers, > David > -- > SatSignal Software - Quality software for you > Web: https://www.satsignal.eu > Email: david-tay...@blueyonder.co.uk > Twitter: @gm8arv > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Pi 4 and Ultimate hat weirdness
I got a Pi 4 and Adafruit ultimate gps hat to play with and decided to see how good it was as a timekeeper. First weird thing; xgps does not show a skyview but both xgps and cgps show at least 10 satellites in use. I don't care too much about this one as AFAIK xgps is broken on Pi. Second weird thing; I started the 20 driver in mode 0. ntpq showed lots of syntax errors on the $GPGGA message. I changed the mode to 29 to deselect $GPGGA; no errors from ntpq. So maybe it was a satellite thing, but whatever it was, no more errors. Third and biggest weird thing; I had fudge 127.127.20.0 flag1 1 time1 0.001 in ntp.conf. After everything settled down, the clock was showing an offset of -1043. OK, So I changed time1 to 1.044 even though it looked too big. ntp wouldn't lie to me... After everything settled down this time the offset was showing an average of -738. For grins and giggles I set time1 to 0.738 and now the average offset is -584. time1 offset 0.001 -1043 1.044 -738 0.738 -584 It seems there is no way to get time1 to correct the offset. Also the jitter times look high. At this moment ntpq shows: xGPS_NMEA(0) .GPS.0 l6 16 3670.000 -849.36 25.536 *SHM(0) .SHM.0 l4 16 3770.000 -106.55 72.688 xPPS(0) .PPS.0 l4 16 3770.000 18.702 18.812 For comparison, a GlobalSat BU-353-S4 USB GPS on a PC ubuntu system shows: *SHM(0) .SHM.0 l3 16 3770.000 -0.728 1.356 Anyone got any suggestions other than to trash the Ulitmate hat and get another GlobalSat USB? -- Jim Pennino ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
