On Dec 11, 1:59 pm, Unruh <unruh-s...@physics.ubc.ca> wrote: > dhavey <dha...@gmail.com> writes: > >On Dec 10, 10:45 pm, Unruh <unruh-s...@physics.ubc.ca> wrote: > >> bruce.kl...@exfo.com (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.htmlandlook 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?
Okay, my bad. I just read what you said on the in the terrifyingly incomplete ntp documentation. I'll try the funny formula. Alice is trying to find the PPS signal ;) Chill PS...I also tested the rs232 from ttyS1 to ttyS2 at 115200 and you are right. It is horibly slow. Peace. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions