Re: [ntp:questions] Performance?
On Dec 30, 2:16 pm, David Woolley wrote: > > Yes, and 0 V lies right in the middle of that, and teh behaviour is apt to > > be undefined. > > The behaviour for RS232 control lines is not undefined. O volts is > unequivocally OFF. In practice, the same receivers are used for data lines. > > The significance of the transition region is that drivers have to be > monotonic in that range. It's not a requirement on receivers. "Voltage levels Diagrammatic oscilloscope trace of voltage levels for an uppercase ASCII "K" character (0x4b) with 1 start bit, 8 data bits, 1 stop bit The RS-232 standard defines the voltage levels that correspond to logical one and logical zero levels. Valid signals are plus or minus 3 to 15 volts. The range near zero volts is not a valid RS-232 level; " Wikipedia. I thought it was plus or minus 3-12 volts with the range between -3 and +3 volts undefined. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 30, 9:28 am, Unruh wrote: > ober...@es.net (Kevin Oberman) writes: > >> From: dhavey > >> Date: Mon, 29 Dec 2008 12:07:25 -0800 (PST) > >> Sender: questions-bounces+oberman=es@lists.ntp.org > > >> Garmin specs say: The rising edge of the signal is aligned to the > >> start of each GPS second. This means edge on assert right? So flag2 > >> should be 0? > > >> What is going on here? > >On my clock (EndRun, not Garmin) the PPS is low true, so the rising edge > >is NOT the assert, but the rising edge at the end of the pulse. There is > >a difference between leading and rising. (I had to talk to an engineer at > >EndRun to confirm this was the case and it may not be for the Garmin.) > > Garmin defines the leading edge as the transition from 0V to 5V on the PPS > line. Now serial has two levels -12V and +12V. with capacitive coupling, > the garmin signal would be something like -2.5V to 2.5 V which really is > way out of spec for the serial port. (Or with the typicallysmall duty > cycle, more like -1V to 4V) > > >For EndRun, flag2 is 1. > >-- > >R. Kevin Oberman, Network Engineer > >Energy Sciences Network (ESnet) > >Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > >E-mail: ober...@es.net Phone: +1 510 486-8634 > >Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 I don't see much difference in offsets between the two machines either way. Something else must be wrong. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 30, 1:36 pm, dhavey wrote: > On Dec 30, 9:39 am, David Woolley > > > > wrote: > > Unruh wrote: > > > Garmin defines the leading edge as the transition from 0V to 5V on the PPS > > > line. Now serial has two levels -12V and +12V. with capacitive coupling, > > > There's no capacitive coupling; it is assumed that the transmission line > > and load behave as capacitive, but that is in parallel. > > > The transition region for RS232C is -3V to +3V into 4 to 5k. > > > > the garmin signal would be something like -2.5V to 2.5 V which really is > > > However, the expected hysterisis is in the 10s to 100s of mV range, and > > the actual threshold for control signals is supposed to be above zero, > > such that zero volts will give an unambiguous off state. > > > In practice, therefore, with real world RS 232 line receivers, there is > > no problem in feeding from TTL levels, as long as the cable is short > > enough to avoid ringing. > > > > way out of spec for the serial port. (Or with the typicallysmall duty > > > cycle, more like -1V to 4V) > > time.qnan.org seems to indicate that > flag2 0=pps edge on assert > or High to Low > is standard behavior for GPS devices. I don't see much difference in offsets between the machines either way: +192.168.0.29.GPS.1 u3 16 3770.090 3.084 0.254 *GPS_NMEA(0) .GPS.0 l- 16 3770.000 -0.276 1.722 +192.168.0.28.GPS.1 u 16 16 3760.001 -2.921 0.124 *GPS_NMEA(0) .GPS.0 l 15 16 3770.000 0.286 1.399 Something else must be wrong. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 30, 9:39 am, David Woolley wrote: > Unruh wrote: > > Garmin defines the leading edge as the transition from 0V to 5V on the PPS > > line. Now serial has two levels -12V and +12V. with capacitive coupling, > > There's no capacitive coupling; it is assumed that the transmission line > and load behave as capacitive, but that is in parallel. > > The transition region for RS232C is -3V to +3V into 4 to 5k. > > > the garmin signal would be something like -2.5V to 2.5 V which really is > > However, the expected hysterisis is in the 10s to 100s of mV range, and > the actual threshold for control signals is supposed to be above zero, > such that zero volts will give an unambiguous off state. > > In practice, therefore, with real world RS 232 line receivers, there is > no problem in feeding from TTL levels, as long as the cable is short > enough to avoid ringing. > > > way out of spec for the serial port. (Or with the typicallysmall duty > > cycle, more like -1V to 4V) time.qnan.org seems to indicate that flag2 0=pps edge on assert or High to Low is standard behavior for GPS devices. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 23, 12:42 pm, David Woolley wrote: > dhavey wrote: > > The performance is still really bad: > > You still don't have PPS. > > One of your other servers is in severe distress (stepping). Three of > the servers for the first machine, including GPS and the other statum 1 > have been declared false tickers. > > Do you really expect better than Windows performance? > > > remote refid st t when poll reach delay > > offset jitter > > == > > x192.168.0.2 69.25.96.13 2 u1 16 3770.130 > > 4.307 0.417 > > 192.168.0.26192.168.0.2 2 u 47 16 2100.0000.000 > > 130.357 > > 192.168.0.27.STEP. 16 u- 1600.000 > > 0.000 0.000 > > x192.168.0.29.GPS.1 u 11 16 3760.086 > > -199.29 0.172 > > xGPS_NMEA(0) .GPS.0 l4 16 3770.000 > > -220.73 2.039 > > > remote refid st t when poll reach delay offset > > jitter > > == > > 192.168.0.26192.168.0.2 2 u 13 16 420.007 > > 15.204 0.409 > > 192.168.0.27192.168.0.29 2 u 1214 1600.001 > > 40.722 0.000 > > 192.168.0.2871.80.83.0 3 u2 16 3770.018 > > 199.327 0.123 > > *GPS_NMEA(0) .GPS.0 l3 16 3770.000 > > 0.605 3.320 I was hoping for sub-millisecond precision. You were right. The PPS wasn't asserting itself. (it should learn to be more assertive ;) I'm sure I started it befor I left town. I have it started now but the offset is bouncing around badly (-3 to around 2 milliseconds) Ugh! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 24, 8:09 am, k...@uiowa.edu (David R. Andersen) wrote: > I have a Garmin 18LVC GPS set up at 9600 baud and emitting the GPGGA > sentence. PPS is connected to pin 1 of the DB9 (DCD pin). I typically > get 1-2 microsecond jitter with this setup and FreeBSD O/S. ntp.conf > statements to enable this clock are: > > server 127.127.20.1 mode 18 prefer # mode 2 enables $GPGGA operation, > mode 16 enables 9600 baud operation > fudge 127.127.20.1 time1 0.000 flag2 1 # flag2 0=pps edge on assert, > 1=pps edge on clear > > The server mode 18 parameter does two things - enable GPGGA operation > and enable 9600 baud operation. Fudge flag2 should be set or cleared > depending on your PPS signal. time1 should be set as appropriate for > your system. Also, be sure to set symlinks as appropriate in /dev so > that the clock driver can find the serial port. With FreeBSD I have > /dev/gps1 symlinked to /dev/cuad1. With linux, /dev/gps1 should be > symlinked to /dev/ttyS# where # is the number of the serial port you are > using. > > Dave > > > > dhavey wrote: > > On Dec 22, 5:41 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > > Murray) wrote: > > >>> I'm using Garmin LVC's. I used the windows config program on one of > >>> them and changed the baud rate to 9600, turned the PPS on, and enabled > >>> NEMA 3.x. > > >> The NMEA driver in ntpd is not expecting you to change the baud rate. > >> There may be some way to configure it to use other baud rates, but I > >> don't remember anything like that. > > >>> The other one I configured using cu. I turned off all of the output > >>> sentences except for GPGG and turned the PPS on. > > >> The default setup for the NMEA driver is to use the GPRMC sentence. > >> It can use a few others. Check the documentation or fix it to send > >> (only) the GPRMC sentence. > > >> -- > >> These are my opinions, not necessarily my employer's. I hate spam. > > > The performance is still really bad: > > remote refid st t when poll reach delay > > offset jitter > > == > > x192.168.0.2 69.25.96.13 2 u1 16 3770.130 > > 4.307 0.417 > > 192.168.0.26192.168.0.2 2 u 47 16 2100.0000.000 > > 130.357 > > 192.168.0.27.STEP. 16 u- 1600.000 > > 0.000 0.000 > > x192.168.0.29.GPS.1 u 11 16 3760.086 > > -199.29 0.172 > > xGPS_NMEA(0) .GPS.0 l4 16 3770.000 > > -220.73 2.039 > > > remote refid st t when poll reach delay offset > > jitter > > == > > 192.168.0.26192.168.0.2 2 u 13 16 420.007 > > 15.204 0.409 > > 192.168.0.27192.168.0.29 2 u 1214 1600.001 > > 40.722 0.000 > > 192.168.0.2871.80.83.0 3 u2 16 3770.018 > > 199.327 0.123 > > *GPS_NMEA(0) .GPS.0 l3 16 3770.000 > > 0.605 3.320 > > > ___ > > questions mailing list > > questi...@lists.ntp.org > >https://lists.ntp.org/mailman/listinfo/questions > > -- > > David R. Andersen > Professor > Department of Electrical and Computer Engineering > Department of Physics and Astronomy > The University of Iowa > Iowa City, IA 52242 > > Email: k...@uiowa.edu <mailto:k...@uiowa.edu> > Tel: (319) 335-2529 > Fax: (319) 353-1115 > Web:http://dx.eng.uiowa.edu/dave/ The sym links are ok. NTP doesn't seem to like 9600 baud with GPGGA. Reach is still zero. remote refid st t when poll reach delay offset jitter == *192.168.0.29.GPS.1 u2 16 3760.085 -0.457 0.021 GPS_NMEA(0) .GPS.0 l- 6400.000 0.000 0.001 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
Garmin specs say: The rising edge of the signal is aligned to the start of each GPS second. This means edge on assert right? So flag2 should be 0? What is going on here? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 22, 5:41 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >I'm using Garmin LVC's. I used the windows config program on one of > >them and changed the baud rate to 9600, turned the PPS on, and enabled > >NEMA 3.x. > > The NMEA driver in ntpd is not expecting you to change the baud rate. > There may be some way to configure it to use other baud rates, but I > don't remember anything like that. > > >The other one I configured using cu. I turned off all of the output > >sentences except for GPGG and turned the PPS on. > > The default setup for the NMEA driver is to use the GPRMC sentence. > It can use a few others. Check the documentation or fix it to send > (only) the GPRMC sentence. > > -- > These are my opinions, not necessarily my employer's. I hate spam. The performance is still really bad: remote refid st t when poll reach delay offset jitter == x192.168.0.2 69.25.96.13 2 u1 16 3770.130 4.307 0.417 192.168.0.26192.168.0.2 2 u 47 16 2100.0000.000 130.357 192.168.0.27.STEP. 16 u- 1600.000 0.000 0.000 x192.168.0.29.GPS.1 u 11 16 3760.086 -199.29 0.172 xGPS_NMEA(0) .GPS.0 l4 16 3770.000 -220.73 2.039 remote refid st t when poll reach delay offset jitter == 192.168.0.26192.168.0.2 2 u 13 16 420.007 15.204 0.409 192.168.0.27192.168.0.29 2 u 1214 1600.001 40.722 0.000 192.168.0.2871.80.83.0 3 u2 16 3770.018 199.327 0.123 *GPS_NMEA(0) .GPS.0 l3 16 3770.000 0.605 3.320 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 22, 3:01 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >Okay the ppstest is asserting and clearing but still no ntpq -p reach: > > The NMEA driver doesn't look at the PPS until it gets valid data > on the serial port. > > What type of GPS unit are you using? > > Have you changed any of the default settings? (like baud rate) > > -- > These are my opinions, not necessarily my employer's. I hate spam. I'm using Garmin LVC's. I used the windows config program on one of them and changed the baud rate to 9600, turned the PPS on, and enabled NEMA 3.x. The other one I configured using cu. I turned off all of the output sentences except for GPGG and turned the PPS on. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 22, 1:52 pm, dhavey wrote: > On Dec 22, 1:25 pm, Unruh wrote: > > > > > It is because you are using the nmea from them, not the PPS input and NMEA > > takes a few msec to go from the GPS to your computer ( 60 characters at > > 9600BD ). > > > dhavey writes: > > >This is the ntpq -p output from 2 machines connected to Garmin GPS's. > > >The machines ip's of the 2 machines are 192.168.0.28 and .29. They > > >are about a millisecond apart! That's no better than the server > > >without the GPS. What did I do to deserve such lousy performance.? > > >server 127.127.20.0 prefer minpoll 4 > > >fudge 127.127.20.0 refid GPS flag3 1 flag2 0 time1 0.0 > > > and the machines are peered together. > > > remote refid st t when poll reach delay > > >offset jitter > > >== > > >*192.168.0.2 69.25.96.13 2 u 83 1024 3770.898 > > >-0.201 0.456 > > > 192.168.0.26192.168.0.2 3 u 171 1024 3761.588 > > >-1.921 0.416 > > > 192.168.0.27192.168.0.2 3 u 204 1024 3761.206 > > >2.312 0.008 > > > 192.168.0.29192.168.0.28 4 u 323 256 1660.110 > > >0.908 0.299 > > > GPS_NMEA(0) .GPS.0 l- 1600.000 > > >0.000 0.001 > > > remote refid st t when poll reach delay > > >offset jitter > > >== > > >+192.168.0.26192.168.0.2 3 u 67 512 1770.100 > > >-2.753 0.374 > > >+192.168.0.27192.168.0.2 3 u 67 512 3770.055 > > >2.018 0.314 > > >*192.168.0.28192.168.0.2 3 u 120 512 1370.020 > > >-0.953 0.337 > > > GPS_NMEA(0) .GPS.0 l- 1600.000 > > >0.000 0.001 > > According to ./ppstest the GPS works until I start ntpd. Okay the ppstest is asserting and clearing but still no ntpq -p reach: remote refid st t when poll reach delay offset jitter == *192.168.0.2 69.25.96.13 2 u 12 64 770.141 1.222 0.564 192.168.0.26192.168.0.2 3 u 42 64 760.001 -0.109 0.506 192.168.0.27192.168.0.2 3 u1 64 770.083 5.219 0.516 +192.168.0.29192.168.0.26 4 u 15 64 760.001 0.478 1.144 GPS_NMEA(0) .GPS.0 l- 1600.000 0.000 0.001 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 22, 11:59 am, David Woolley wrote: > dhavey wrote: > > are about a millisecond apart! That's no better than the server > > without the GPS. What did I do to deserve such lousy performance.? > > 1) Not used PPS. > > 2) Not used a valid GPS input on either machine. > > > > > GPS_NMEA(0) .GPS.0 l- 1600.000 > > 0.000 0.001 > > The GPS reference clock is unreachable and is, therefore, being > rejected. Same for the other machine. > > Without PPS, some GPS receivers are barely good for the second. > > > GPS_NMEA(0) .GPS.0 l- 1600.000 > > 0.000 0.001 ./ppstest fails but there is output from the GPS: $GPRMC,211953,A,3426.0023,N,11950.9571,W, 000.0,332.6,221208,013.9,E,D*01 $GPGGA,211953,3426.0023,N,11950.9571,W,2,08,1.5,9.2,M,-32.5,M,,*74 $GPGSA,A,3,,05,10,12,18,21,24,29,303.1,1.5,2.7*32 $GPGSV,3,1,11,02,13,062,00,05,33,186,51,10,44,054,37,12,26,173,52*70 $GPGSV,3,2,11,18,16,204,47,21,37,267,46,24,69,334,49,29,68,351,48*7B $GPGSV,3,3,11,30,52,212,51,31,05,278,00,48,48,203,46*41 $PGRME,2.6,M,5.0,M,5.7,M*2D $PGRMB,,K,,,*2D I guess I have to muck around with the GPS settings some more. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance?
On Dec 22, 1:25 pm, Unruh wrote: > It is because you are using the nmea from them, not the PPS input and NMEA > takes a few msec to go from the GPS to your computer ( 60 characters at > 9600BD ). > > dhavey writes: > >This is the ntpq -p output from 2 machines connected to Garmin GPS's. > >The machines ip's of the 2 machines are 192.168.0.28 and .29. They > >are about a millisecond apart! That's no better than the server > >without the GPS. What did I do to deserve such lousy performance.? > >server 127.127.20.0 prefer minpoll 4 > >fudge 127.127.20.0 refid GPS flag3 1 flag2 0 time1 0.0 > > and the machines are peered together. > > remote refid st t when poll reach delay > >offset jitter > >== > >*192.168.0.2 69.25.96.13 2 u 83 1024 3770.898 > >-0.201 0.456 > > 192.168.0.26192.168.0.2 3 u 171 1024 3761.588 > >-1.921 0.416 > > 192.168.0.27192.168.0.2 3 u 204 1024 3761.206 > >2.312 0.008 > > 192.168.0.29192.168.0.28 4 u 323 256 1660.110 > >0.908 0.299 > > GPS_NMEA(0) .GPS.0 l- 1600.000 > >0.000 0.001 > > remote refid st t when poll reach delay > >offset jitter > >== > >+192.168.0.26192.168.0.2 3 u 67 512 1770.100 > >-2.753 0.374 > >+192.168.0.27192.168.0.2 3 u 67 512 3770.055 > >2.018 0.314 > >*192.168.0.28192.168.0.2 3 u 120 512 1370.020 > >-0.953 0.337 > > GPS_NMEA(0) .GPS.0 l- 1600.000 > >0.000 0.001 According to ./ppstest the GPS works until I start ntpd. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Performance?
This is the ntpq -p output from 2 machines connected to Garmin GPS's. The machines ip's of the 2 machines are 192.168.0.28 and .29. They are about a millisecond apart! That's no better than the server without the GPS. What did I do to deserve such lousy performance.? server 127.127.20.0 prefer minpoll 4 fudge 127.127.20.0 refid GPS flag3 1 flag2 0 time1 0.0 and the machines are peered together. remote refid st t when poll reach delay offset jitter == *192.168.0.2 69.25.96.13 2 u 83 1024 3770.898 -0.201 0.456 192.168.0.26192.168.0.2 3 u 171 1024 3761.588 -1.921 0.416 192.168.0.27192.168.0.2 3 u 204 1024 3761.206 2.312 0.008 192.168.0.29192.168.0.28 4 u 323 256 1660.110 0.908 0.299 GPS_NMEA(0) .GPS.0 l- 1600.000 0.000 0.001 remote refid st t when poll reach delay offset jitter == +192.168.0.26192.168.0.2 3 u 67 512 1770.100 -2.753 0.374 +192.168.0.27192.168.0.2 3 u 67 512 3770.055 2.018 0.314 *192.168.0.28192.168.0.2 3 u 120 512 1370.020 -0.953 0.337 GPS_NMEA(0) .GPS.0 l- 1600.000 0.000 0.001 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 18, 3:27 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >/dev/gps0 -> /dev/pps0 > >exists. > > That looks fishy. > > I'd expect something like: > /dev/gps0 -> /dev/ttyS0 > and > /dev/pps0 -> /dev/ttyS0 > > -- > These are my opinions, not necessarily my employer's. I hate spam. That was it! Your a freakin genuis! Tell your boss I said that you deserve a raise! ntpq -p remote refid st t when poll reach delay offset jitter == 192.168.0.26.INIT. 16 u 13 6400.000 0.000 0.000 192.168.0.27.INIT. 16 u- 6400.000 0.000 0.000 192.168.0.28192.168.0.2 3 u 11 6411.185 -1490.8 0.001 GPS_NMEA(0) .GPS.0 l- 1600.000 0.000 0.001 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
I ran the code in gdb and this is the stack trace. At refclock_nmea.c: 178 this code causes the crash nmea_port = atoi(strtok(NULL,":")); I am not really sure of why strtok is used on a NULL string. I assume strtok return a NULL based on the trace, and then atoi calls strtool which leads to a crash. Possibly, this is a libc64 bug, as I would expect atoi to detect a null string and not to crash. #0 0x003361a341ca in strtoll_l_internal () from /lib64/ libc.so.6 #1 0x003361a31ab2 in atoi () from /lib64/libc.so.6 #2 0x00443515 in nmea_start (unit=0, peer=0x69cb58) at refclock_nmea.c:178 #3 0x0042bb9c in refclock_newpeer (peer=0x69cb58) at ntp_refclock.c:276 #4 0x00422fab in newpeer (srcadr=0x7fff552f88a0, dstadr=0x6ef0b0, hmode=3, version=4, minpoll=4, maxpoll=10, flags=129, cast_flags=1 '\001', ttl=0, key=0) at ntp_peer.c:837 #5 0x004222ea in peer_config (srcadr=0x7fff552f88a0, dstadr=0x6ef0b0, hmode=3, version=4, minpoll=4, maxpoll=10, flags=128, ttl=0, key=0, keystr=0x4776c1 "*") at ntp_peer.c:525 #6 0x0040619a in getconfig (argc=0, argv=0x7fff552f8bd8) at ntp_config.c:864 #7 0x0040f5a6 in ntpdmain (argc=0, argv=0x7fff552f8bd8) at ntpd.c:846 #8 0x0040f0ec in main (argc=4, argv=0x7fff552f8bb8) at ntpd.c: 317 (gdb) up #1 0x003361a31ab2 in atoi () from /lib64/libc.so.6 (gdb) up #2 0x00443515 in nmea_start (unit=0, peer=0x69cb58) at refclock_nmea.c:178 178 nmea_port = atoi(strtok(NULL,":")); ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
Okay here it is ;)
What does all of that mean?
I'll try to get it out of daemon mode and then post the output from
gdb ;)
[r...@user4 ntp-4.2.4p5]# /usr/local/bin/ntpd -d -d -d -d -d -d -d -d -
d -d -l /var/log/ntpd.log -c /etc/ntp.gps
ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2)
addto_syslog: logging to file /var/log/ntpd.log
addto_syslog: logging to file /var/log/ntpd.log
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
addto_syslog: set_process_priority: Leave priority alone:
priority_done is <2>
addto_syslog: precision = 1.000 usec
create_sockets(123)
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket
boundary: 16
setsockopt SO_TIMESTAMP enabled on fd 16 address 0.0.0.0
bind() fd 16, family 2, port 123, addr 0.0.0.0, flags=0x89
flags for fd 16: 0x802
Searching for addr 0.0.0.0 in list of addresses - NOT FOUND
Added addr 0.0.0.0 to list of addresses
addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
setsockopt SO_TIMESTAMP enabled on fd 17 address ::
bind() fd 17, family 10, port 123, addr ::, flags=0x81
flags for fd 17: 0x802
Searching for addr :: in list of addresses - NOT FOUND
Added addr :: to list of addresses
addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled
update_interfaces(123)
address_okay: listen Virtual: 1, IF name: lo
address_okay: loopback - OK
examining interface #0: fd=-1, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
Searching for addr ::1 in list of addresses - NOT FOUND
create_interface(::1#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 18 address ::1
bind() fd 18, family 10, port 123, addr ::1, flags=0x5
flags for fd 18: 0x802
addto_syslog: Listening on interface #2 lo, ::1#123 Enabled
Searching for addr ::1 in list of addresses - NOT FOUND
Added addr ::1 to list of addresses
created interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
updating interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled: new - created
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
address_okay: listen Virtual: 1, IF name: eth0
address_okay: OK
examining interface #0: fd=-1, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = fe80::21d:9ff:fe18:815,
0a7b fe80 021d09ff fe180815 0200
bcast = 0.0.0.0,
mask = :::::,
0a7b
name = eth0
flags = 0x0011
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 2
peercnt = 0
phase = 1
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
create_interface(fe80::21d:9ff:fe18:815#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 19 address fe80::21d:
9ff:fe18:815
bind() fd 19, family 10, port 123, addr fe80::21d:9ff:fe18:815,
flags=0x11
flags for fd 19: 0x802
addto_syslog: Listening on interface #3 eth0, fe80::21d:
9ff:fe18:815#123 Enabled
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
Added addr fe80::21d:9ff:fe18:815 to list of addresses
created interface #3: fd=19, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815, Ena
Re: [ntp:questions] nmea patch
On Dec 18, 1:49 pm, David Woolley wrote: > dhavey wrote: > > What full debug? > > Depends on your development toolset, but for gcc, it means including the > -g flag and not doing anything that would strip the binary. > > For gcc, unoptimised means something like -O0 Like that? (gdb) run -l /var/log/ntpd.log -d -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -d -c /etc/ ntp.gps ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2) addto_syslog: logging to file /var/log/ntpd.log addto_syslog: logging to file /var/log/ntpd.log addto_syslog: precision = 1.000 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 192.168.0.29#123 Enabled local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 0040 addto_syslog: configure: keyword "ning" unknown, line ignored peer_crypto_clear: at 0 next 0 assoc ID 59506 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 59506 refid INIT newpeer: 192.168.0.29->192.168.0.26 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59507 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 59507 refid INIT newpeer: 192.168.0.29->192.168.0.27 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59508 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 59508 refid INIT newpeer: 192.168.0.29->192.168.0.28 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key Breakpoint 1, 0x003361a341ca in strtoll_l_internal () from / lib64/libc.so.6 (gdb) backtrace #0 0x003361a341ca in strtoll_l_internal () from /lib64/ libc.so.6 #1 0x00407c79 in getconfig (argc=, argv=0x4) at /usr/include/stdlib.h:336 #2 0x0040c90b in ntpdmain (argc=0, argv=) at ntpd.c:846 #3 0x003361a1d8b4 in __libc_start_main () from /lib64/libc.so.6 #4 0x00404a79 in _start () (gdb) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 18, 1:49 pm, David Woolley wrote: > dhavey wrote: > > What full debug? > > Depends on your development toolset, but for gcc, it means including the > -g flag and not doing anything that would strip the binary. > > For gcc, unoptimised means something like -O0 Like that? (gdb) run -l /var/log/ntpd.log -d -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -d -c /etc/ ntp.gps ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2) addto_syslog: logging to file /var/log/ntpd.log addto_syslog: logging to file /var/log/ntpd.log addto_syslog: precision = 1.000 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 192.168.0.29#123 Enabled local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 0040 addto_syslog: configure: keyword "ning" unknown, line ignored peer_crypto_clear: at 0 next 0 assoc ID 59506 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 59506 refid INIT newpeer: 192.168.0.29->192.168.0.26 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59507 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 59507 refid INIT newpeer: 192.168.0.29->192.168.0.27 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59508 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 59508 refid INIT newpeer: 192.168.0.29->192.168.0.28 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key Breakpoint 1, 0x003361a341ca in strtoll_l_internal () from / lib64/libc.so.6 (gdb) backtrace #0 0x003361a341ca in strtoll_l_internal () from /lib64/ libc.so.6 #1 0x00407c79 in getconfig (argc=, argv=0x4) at /usr/include/stdlib.h:336 #2 0x0040c90b in ntpdmain (argc=0, argv=) at ntpd.c:846 #3 0x003361a1d8b4 in __libc_start_main () from /lib64/libc.so.6 #4 0x00404a79 in _start () (gdb) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
Okay here it is ;)
What does all of that mean?
I'll try to get it out of daemon mode and then post the output from
gdb ;)
[r...@user4 ntp-4.2.4p5]# /usr/local/bin/ntpd -d -d -d -d -d -d -d -d -
d -d -l /var/log/ntpd.log -c /etc/ntp.gps
ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2)
addto_syslog: logging to file /var/log/ntpd.log
addto_syslog: logging to file /var/log/ntpd.log
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
addto_syslog: set_process_priority: Leave priority alone:
priority_done is <2>
addto_syslog: precision = 1.000 usec
create_sockets(123)
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket
boundary: 16
setsockopt SO_TIMESTAMP enabled on fd 16 address 0.0.0.0
bind() fd 16, family 2, port 123, addr 0.0.0.0, flags=0x89
flags for fd 16: 0x802
Searching for addr 0.0.0.0 in list of addresses - NOT FOUND
Added addr 0.0.0.0 to list of addresses
addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
setsockopt SO_TIMESTAMP enabled on fd 17 address ::
bind() fd 17, family 10, port 123, addr ::, flags=0x81
flags for fd 17: 0x802
Searching for addr :: in list of addresses - NOT FOUND
Added addr :: to list of addresses
addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled
update_interfaces(123)
address_okay: listen Virtual: 1, IF name: lo
address_okay: loopback - OK
examining interface #0: fd=-1, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
Searching for addr ::1 in list of addresses - NOT FOUND
create_interface(::1#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 18 address ::1
bind() fd 18, family 10, port 123, addr ::1, flags=0x5
flags for fd 18: 0x802
addto_syslog: Listening on interface #2 lo, ::1#123 Enabled
Searching for addr ::1 in list of addresses - NOT FOUND
Added addr ::1 to list of addresses
created interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
updating interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled: new - created
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
address_okay: listen Virtual: 1, IF name: eth0
address_okay: OK
examining interface #0: fd=-1, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = fe80::21d:9ff:fe18:815,
0a7b fe80 021d09ff fe180815 0200
bcast = 0.0.0.0,
mask = :::::,
0a7b
name = eth0
flags = 0x0011
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 2
peercnt = 0
phase = 1
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
create_interface(fe80::21d:9ff:fe18:815#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 19 address fe80::21d:
9ff:fe18:815
bind() fd 19, family 10, port 123, addr fe80::21d:9ff:fe18:815,
flags=0x11
flags for fd 19: 0x802
addto_syslog: Listening on interface #3 eth0, fe80::21d:
9ff:fe18:815#123 Enabled
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
Added addr fe80::21d:9ff:fe18:815 to list of addresses
created interface #3: fd=19, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815, Ena
Re: [ntp:questions] nmea patch
On Dec 18, 11:47 am, dhavey wrote: > On Dec 17, 11:03 pm, David Woolley > > wrote: > > Hal Murray wrote: > > > In article > > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > > dhavey writes: > > >> and it segfaults. Any clues? > > > > Does /dev/gps0 exist? Often, it's a symlink to whatever > > > your OS uses for /dev/tty stuff. > > > What is that OS and what does the debugger say was the location of the > > crash when you run an unstripped version? Can you reproduce with an > > unoptimised full debug build? > > /dev/gps0 -> /dev/pps0 > exists. > dmesg says: > ntpd[11347]: segfault at 0 ip 003361a341ca sp 7fff3b8ca680 > error 4 in libc-2.5.so[3361a0+14a000] > > Where is the ntp log? > What full debug? > Okay chill, I'm going to read the README ;) ntp.log 18 Dec 13:11:16 ntpd[11838]: logging to file /var/log/ntpd.log 18 Dec 13:11:16 ntpd[11838]: precision = 1.000 usec 18 Dec 13:11:16 ntpd[11838]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 18 Dec 13:11:16 ntpd[11838]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #1 wildcard, ::#123 Disabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #2 lo, ::1#123 Enabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #4 lo, 127.0.0.1#123 Enabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #5 eth0, 192.168.0.29#123 Enabled 18 Dec 13:11:16 ntpd[11838]: kernel time sync status 0040 18 Dec 13:11:16 ntpd[11838]: configure: keyword "ning" unknown, line ignored 18 Dec 13:11:16 ntpd[11838]: refclock_setup fd 6 tcgetattr: Inappropriate ioctl for device gdb looks like this: (gdb) run -l /var/log/ntpd.log -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -c /etc/ ntp.gps [Detaching after fork from child process 11958. (Try `set detach-on- fork off'.)] Program exited normally. (gdb) I took the -o2 flag out of the Makefile. I don't know what you mean by an "unstripped version". ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 17, 11:03 pm, David Woolley wrote: > Hal Murray wrote: > > In article > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > dhavey writes: > >> and it segfaults. Any clues? > > > Does /dev/gps0 exist? Often, it's a symlink to whatever > > your OS uses for /dev/tty stuff. > > What is that OS and what does the debugger say was the location of the > crash when you run an unstripped version? Can you reproduce with an > unoptimised full debug build? > > It's centos with kernel version 2.6.27.3 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 17, 11:03 pm, David Woolley wrote: > Hal Murray wrote: > > In article > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > dhavey writes: > >> and it segfaults. Any clues? > > > Does /dev/gps0 exist? Often, it's a symlink to whatever > > your OS uses for /dev/tty stuff. > > What is that OS and what does the debugger say was the location of the > crash when you run an unstripped version? Can you reproduce with an > unoptimised full debug build? > > I think this is what you meant: /usr/local/bin/ntpd -d -l /var/log/ntpd.log -c /etc/ntp.gps ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2) addto_syslog: logging to file /var/log/ntpd.log addto_syslog: logging to file /var/log/ntpd.log addto_syslog: precision = 1.000 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 192.168.0.29#123 Enabled local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 0040 addto_syslog: configure: keyword "ning" unknown, line ignored peer_crypto_clear: at 0 next 0 assoc ID 5670 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 5670 refid INIT newpeer: 192.168.0.29->192.168.0.26 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 5671 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 5671 refid INIT newpeer: 192.168.0.29->192.168.0.27 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 5672 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 5672 refid INIT newpeer: 192.168.0.29->192.168.0.28 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 5673 key_expire: at 0 peer_clear: at 0 next 4 assoc ID 5673 refid INIT addto_syslog: refclock_setup fd 6 tcgetattr: Inappropriate ioctl for device Segmentation fault ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 17, 11:03 pm, David Woolley wrote: > Hal Murray wrote: > > In article > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > dhavey writes: > >> and it segfaults. Any clues? > > > Does /dev/gps0 exist? Often, it's a symlink to whatever > > your OS uses for /dev/tty stuff. > > What is that OS and what does the debugger say was the location of the > crash when you run an unstripped version? Can you reproduce with an > unoptimised full debug build? > > /dev/gps0 -> /dev/pps0 exists. dmesg says: ntpd[11347]: segfault at 0 ip 003361a341ca sp 7fff3b8ca680 error 4 in libc-2.5.so[3361a0+14a000] Where is the ntp log? What full debug? Okay chill, I'm going to read the README ;) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] nmea patch
I just installed ntp-4.2.4p5 with the nmea patch and this configure: ./configure --disable-all-clocks --disable-parse-clocks \ --enable-NMEA --enable-LOCAL-CLOCK and it segfaults. Any clues? the relevant portion of my ntp.conf looks like this: server 127.127.20.0 prefer minpoll 4 fudge 127.127.20.0 refid GPS flag3 1 flag2 0 time1 0.0 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Running GPS under NTP
On Dec 11, 9:03 pm, "David J Taylor" wrote: > dhavey wrote: > > [] > > > 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 wouldn't worry about a couple of milliseconds, but I am surprised by how > much it seems to vary throughout the day - almost 3:1 from 1ms average at > 30,000 seconds to 3ms average at 65,000 seconds - if I'm reading your > graph correctly. Caused by other activity on that PC? Surely not by > temperature? > > David I was using libserial to send the serial data. I think it may have been doing some buffering. I am using low level c functions now. I'm still seeing about 2000 usecs of offset but I don't know how much variance I will see throughout the day yet because I just finished writing it ;) I'll post a graph tomorrow with the results for today. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Running GPS under NTP
On Dec 11, 1:59 pm, Unruh wrote: > dhavey writes: > >On Dec 10, 10:45 pm, Unruh 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
Re: [ntp:questions] Running GPS under NTP
On Dec 10, 10:45 pm, Unruh 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.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. Any hints/ideas/suggestions? Why so much offset? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
