dhavey <[email protected]> writes: >On Dec 10, 10:45 pm, Unruh <[email protected]> wrote: >> [email protected] (Bruce Kling) writes: >> >Hello, >> >> >I am currently running GPS as a separate process, independent of NTP and >> >I am able to achieve microsecond accuracy If I run GPS under NTP as a >> >reference clock driver will this impact on the accuracy of time in any >> >way? Thank you. >> >> Not sure what you mean. GPS is, in this context a hardware timing process. >> What do you mean "running GPS as a separate process"? You have a program >> which reads GPS, or which interrupts whent eh GPS PPS hits. How do you know >> you have "microsecond accuracy" and what has microsecond accuracy? And what >> does "impact the accuracy" mean? >> >> The GPS PPS can be used to discipline the local lock on a computer using >> ntp to a few microseconds standard deviation. I have a computer which does >> that. You can see the results >> onwww.theory.physics.ubc.ca/chrony/chrony.htmland look at string, which is a >> computer running ntp driven by the GPS PPS signal. As you can see the >> offsets tend to be around 3 usec. (mainly due to clock reading jitter, but >> also due to the reaction of ntp to thermal fluctuations of the computer.) >> >> (Mind you I have written a separate interrupt routine to read the clock on >> the parallel port interrupt, feeding the info to ntp via the shm refclock, >> so whether or not the various possible other refclocks do as well or better >> or worse I have no idea. >> )
>This is interesting. I am using shmpps and the NMEA patch for NTP >just like you describe. I have four time servers connected to garmin >lvc stratum 0 devices. Ntpq -p reports sub micro-second offsets which >is nice ;) >However, three of the time servers are connected to the fourth using >rs232 serial connections. Each of the three stratum 1 time servers >runs the same program: >1. Wait for the begining of the next second. >2. Get the current timestamp. >3. Write the timestamp to the serial port. >The fourth time server runs three programs, one for each of it's >peers. Each program does the same thing: >1. Wait to recieve data from the serial port. >2. Get the current timestamp. >3. Write both timestamps to a data log. >I am seeing 2000 - 4000 micro-second offsets from the serial port >experiments. >Here is a graph: >http://cs.ucsb.edu/~dhavey/gps/offset.pdf >I think I will connect a null modem cable between two serial ports on >one machine and measure the delay. AAArgh. Serial ports are horribly slow. Just calculate how long it takes to transfer your numbers over a serial line at say 9600Bd. That is why ntp works as it does. It sends out a time stamped packet, that packet is received by the server, and immediately time stamped. It is then timestamped again immediately before it is sent out again and finally time stamped by the client. If you assume that the packets have taken the same amount of time in transmission, the difference between the average time stamped by the client and those by the server is the best estimate of the true time difference between the two. If the two packets are exactly the same size ( and this is why the ntp packets are identical except for the contents of the registers) then the transmission times should be the same. >Any hints/ideas/suggestions? Why so much offset? _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
