Assuming the Delay, Offset, and Jitter column units are msec, after letting it run overnight and half of the next day I still see PPS with 0 delay, 4.559 msec offset, and 3.123 msec jitter.
The PPS source is the Meinberg TCR511PCI card, as seen here: http://www.meinberg.de/english/products/tcr511pci.htm The card itself is accepting the unmodulated IRIG B signal from the Arbiter 1093C clock, and shows itself as locked and synced with 100% signal. I suppose there could be a few reasons why PPS is so bad: 1) The cable used to move the IRIG signal from the clock to the Meinberg card acts as both the input (of the IRIG signal into the card's serial port) as well as the output (of the PPS signal into COM1 of the computer). We cut into the middle of the cable and made a tap with another RJ-45 endpoint which we plugged into the COM1 port. The sheer ugliness of the cable itself might be the cause. 2) The Meinberg card also outputs the standard Meinberg ASCII timecode over the serial cable...so there are technically three different signals travelling over this cut-into cable: IRIG B, PPS, and Meinberg's ASCII timecodes. The pins must be different, otherwise the card wouldn't be able to lock onto the IRIG B signal, right? 3) The system is normally under pretty heavy load, being only a single core system (with hyperthreading) and it averages 60-100% CPU usage most of the time. The problem is that the card only has one serial port and needs to accept unmodulated IRIG B as well as output PPS...our solution was to cut into the cable and tap another line out of it, so we can also connect it to the COM1 port. However, that means the IRIG signal is reaching both the Meinberg card as well as the PPS driver, potentially causing interference. Thoughts? I realize Windows isn't the best system for time accuracy, but I just want to see how close/stable it can get. Thanks, Ken On Wed, May 4, 2011 at 11:50 PM, David J Taylor <david-tay...@blueyonder.co.uk.invalid> wrote: >> It appears all I needed to do was swap the TX and CD pins to get it to >> start polling and synced to PPS. Thanks! > > Great! > >> Now, a behavioral question. Will PPS be selected as the peer if and >> only if the peer marked "preferred" is also synced? What if I want PPS >> to act as a supplement to whichever of the stratum 1+ peers NTP sees >> available and decides to sync to? PPS will be the only stratum 0 >> reference source available to this system, but if the preferred peer >> goes down I would expect PPS to continue to correct the jitter of >> whichever other peer NTP decides to sync to (that doesn't seem to be >> the case). > > My understanding is that if you have the ATOM driver present and working > (server 127.127.22.1 with serialpps.sys), that is used to refine whatever > server NTP marks with a "*" in the ntpq -p display - the "system peer". The > ATOM driver itself will be marked with an o" character. > >> Also, it appears that while the preferred peer continues to be synced >> and polled every 64 seconds, the PPS peer seems to "toggle" from being >> a PPS peer to being rejected nearly every poll (of 16 seconds). Is >> this because the polling rate is different between the PPS source and >> the other sources, or is my serial cable too jittery? The PPS source >> claims to have an offset of +/- 10 ms and a jitter of between 2-3 ms >> depending on the poll. >> >> Thanks, >> Ken > > On a FreeBSD system, the PPS offset shows 0, and the jitter is currently > 0.004 (4 microseconds). > > On the Windows systems here, PPS offset is typically less than 0.030 (30 > microseconds), and the jitter less than 0.050 (50 microseconds). If you > have a Garmin GPS 18x LVC with firmware later than 3.20, it's offset of the > serial data from the PPS can exceed one second, which confuses NTP about > which second the PPS actually was! In such circumstances, you can stop the > serial data being used with a "noselect" modifier: > > server 127.127.20.1 minpoll 4 noselect > > Even without the kernel-mode serialpps.sys driver, the offset should be far > less than 10 milliseconds, and the jitter far less than 2-3 milliseconds. > > Cheers, > David > _______________________________________________ > 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
