Re: [ntp:questions] Garmin LVC 18x jitter problem
David Woolley writes: > On 12/07/2019 11:32, William Unruh wrote: > > Do not use nmea as a time source. It it has a long delay ( hundreds of > > ms) which depnds on the speed of connection, on length of the nmea > > sentance, etc. EAch character takes from 100 of usec to ms to be > > delivered, and the lengthof sentences is variable, and the gps sends out > > a sentence only when it is not terribly busy ( which depends on how many > > sattelites it is trying to handle, etc) It is good for setting the > > seconds (sometimes-- if you ask it to send too many sentences it can be > > out by more than a second totally messing up your timing). > > One sentence (RMA) and a high baud rate make it useful for setting the > > second. > > I believe the OP is using it for seconds. The problem is, I think, that > ntpd will only use it, and only accept the PPS, if it is a true chimer. Exactly. I need NMEA for seconds only _and_ it must be accepted as true chimer, otherwise PPS does not work. > Moreover, I think the OP's problem is that the NMEA timing is too > repeatable, so its root dispersion is too small to cover the static > error, although, if they had a lot of jitter, they would then advertise > a root dispersion that doesn't give credit to the PPS accuracy. Almost: The NMEA timing is too repeatable, so its root dispersion is too small for covering the /actual dynamic/ error, so once the jitter center moves, which it does in unpredictable ways, I get a falseticker. The static error is already configured: fudge 127.127.28.0 time1 0.518 refid GPS The time1 was measured by peerstats for some days and agrees with the value documented in other installations. Of course the root cause is awful NMEA jitter behaviour by the device, but I can't change that, and the LVC 18x is already one of the better devices. If the jitter was gauss distributed or equally distributed, ntp would estimate the jitter correctly. The window had to cover a few days as it is, which is not feasible. I would prefer setting a minimum instead of a fixed NMEA jitter to allow ntpd still calculating the jitter value and kicking NMEA out as false ticker in case of malfunction. I just need ntpd not to believe the low NMEA root dispersion it often sees. :) Some examples, just a minute apart: remote refid st t when poll reach delay offset jitter == *SHM(0) .GPS.0 l6 16 3770.000 -17.468 18.600 *SHM(0) .GPS.0 l6 16 3770.000 21.772 20.134 *SHM(0) .GPS.0 l3 16 3770.000 13.032 8.446 In the second and third example, the GPS jitter window around the GPS offset no longer covers the PPS jitter window around the PPS offset, because the GPS jitter value does not react quickly enough. Without setting "tos mindist 0.1", once PPS is used, the root dispersion of my clock is determined by PPS and very low - until the falseticker problem kills it. I noticed chrony allows to set a "precision" value, but from the documentation it was not clear if that's the jitter value and if it just enforces a minimum or sets it fixed. That option does not exist in ntpd. Michael ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 06/20/19 23:39, Chris wrote: Have a couple of surplus gps based ntp servers that have been used for time sync in the lab for few years. They are on a UPS with several hours backup and seems like a good idea to use them to contribute to the ntp global network. Don't want to expose them directly to the net, so plan to isolate them, either via a Solaris zone or FreeBSD jail. This will have 2 network interfaces, ntp subnet facing and the other to internet via the firewall. The ntp side will run ntp client, internet side runs ntp server. Question is, will such an intermediate machine degrade the time served, or will it still be reported as a stratum 1 source. Seems a waste otherwise. ntpq -p currently reports: remote refid st t when poll reach delay offset disp = *chronos .GPS. 1 u 23 64 377 0.18 -0.018 0.03 +nts100 .GPS. 1 u 21 64 377 0.46 -0.071 0.08 Thanks, Chris Got back to this project and have what seems to be at last partially working system. FreeBSD 12 on a minix mini pc with 2 network ports. Also 3 network ntp servers, collected over the years, each with a 1pps output. Rebuilt the kernel with the pps support and added the 1pps hardware wiring. The 1pps from a timeserver has a positive edge, which then goes to an rs232 converter, an inversion, which is then connected to the dcd line on the mini pc serial port, also an inversion, so the leading edge of the 1pps signal to the dcd line is a positive edge. Initially, was getting a false ticker flag on the 1pps, but did a bit more digging and found that at least one of the time sources needs to have the prefer keyword. Chose the .168 source,as that provides the 1 pps. Restart ntpd and get the following: remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l38 170.000 -0.993 0.316 +192.9.200.167 .GPS. 1 u 31 6415.1314.095 1.533 *192.9.200.168 .GPS. 1 u 30 6410.1744.467 0.475 +192.9.200.169 .GPS. 1 u 29 6410.5164.242 0.583 -ntp0.uk.uu.net .GPS. 1 u 32 641 33.0619.896 0.248 After 24 hours or so: remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l58 3770.0000.001 0.000 +192.9.200.167 .GPS. 1 u 12 64 3775.1564.584 1.049 *192.9.200.168 .GPS. 1 u1 64 3770.1785.007 0.054 +192.9.200.169 .GPS. 1 u7 64 3770.3934.982 1.791 -ntp0.uk.uu.net .GPS. 1 u 19 64 177 31.7569.495 0.084 So it looks like it's working. The only other question relates to the 1pps signal. Depending on the time server in use, the pulse may be positive or negative going, but the leading edge is the timing point, not the trailing edge some time later. There's a fudge factor to define the edge in use and have that set for a rising positive edge, but can't find anything in the docs that discuss that. If the wrong edge is used, the 1pps would be out by the width so assume that needs to be right. At present, am using the serial port for the 1pps, but have some differential driver / receiver devices that will be tested on the parallel port some time next week hopefully. Meantime can anyone suggest other tests to check accuracy, correct operation, statistics etc ?... Thanks, Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
