Re: [ntp:questions] How do I validate my PPS clocks?
On 24/02/2013 23:11, bodo...@gmail.com wrote: I can't find or figure out how to validate my ntp results. I (currently) have two Linux boxes with PPS via the NMEA driver from Garmins (18 18x) and a Sure board connected to a purpose built NTP server. When I set up my first Garmin all of my remote offsets were negative which seemed unlikely so I set time1 to 5.3ms which also seems unlikely but which brought me into congruence with some nearby stratum 1 servers. Below is the output* from an intermediate machine on my home network (3Mb ADSL) which is temporarily connected to several servers. 192.168.0.2 is running with time1 5.3ms. 192.168.0.244 is running with time1 132us. 192.168.0.210 is the appliance and has currently has no adjustments.** Should I expect /all/ (ignoring the high jitter ones) of the remote clocks to have negative offsets? Is there a sensible to way to make this assessment purely within the NTP system? remote refid st t when poll reach delay offset jitter == +192.168.0.2 .GPS.1 u 14 16 3770.109 -5.429 0.006 *192.168.0.244 .GPS.1 u1 16 3770.1120.000 0.008 +192.168.0.210 .GPS.1 u 15 16 3770.567 -0.001 0.007 -216.66.0.142130.207.244.240 2 u 54 64 377 63.526 -7.131 0.192 -38.229.71.1 204.123.2.72 2 u 25 64 377 67.175 -4.368 0.472 -63.240.161.99 72.26.198.2333 u 19 64 377 70.797 -3.284 0.320 #204.235.61.9128.105.201.11 2 u 17 64 177 73.331 -9.732 0.426 -216.229.4.69216.229.0.1792 u- 64 377 78.848 -4.987 1.337 -199.7.177.206 64.147.116.229 2 u 13 64 377 86.072 -7.451 0.235 #2604:180::8138: 164.244.221.197 2 u 56 64 377 91.521 -33.681 25.573 -198.101.234.139 128.138.140.44 2 u 35 64 377 97.360 -2.065 0.584 #2604:2880::870: 139.78.135.142 u 23 64 377 115.057 -12.785 22.738 -207.7.148.214 204.123.2.5 2 u2 64 377 123.982 -8.091 0.747 *This billboard is sorted by delay. **You'd have to recompile the control software. For comparison, my results with a number of different stratum-1 servers are here: http://www.satsignal.eu/ntp/ntp-offsets.txt This includes FreeBSD, Linux, and Windows stratum-1 servers. Unless those PCs are very slow, I would suggest that the time1 value should be well under 1 millisecond, and likely under 50 microseconds. My own results mostly show a positive offset for remote servers, which I put down to asymmetry on my consumer Cable Modem connection (30 Mb/s down, 3 Mb/s up). The remote servers are a mixture of pool and other servers, some stratum-2 and some stratum-3. Be aware that some of the national stratum-1 servers can be rather overloaded, producing poorer performance than the better stratum-2 servers. Equally, servers in the pool may well be not as good as the best stratum-2 servers. So it's a little pot luck! Does that help? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How do I validate my PPS clocks?
On 02/25/2013 12:11 AM, bodo...@gmail.com wrote: I can't find or figure out how to validate my ntp results. I (currently) have two Linux boxes with PPS via the NMEA driver from Garmins (18 18x) and a Sure board connected to a purpose built NTP server. When I set up my first Garmin all of my remote offsets were negative which seemed unlikely so I set time1 to 5.3ms which also seems unlikely but which brought me into congruence with some nearby stratum 1 servers. You can put tight boundaries on it by using what you have, and adding up all the delays: I did this measurement on the 18x: http://n1.taur.dk/gps18x/ and found the PPS, measured on the 18x before the cable, to be [85ns..140ns] slow. When the signal has passed though 10m cable, it becomes [115ns..0.5us] slow. Whether you are feeding PPS directly to DCD, or through an RS232 driver, mostly only matters for noise suppression. The input propagation delay of a typical RS232 receiver is ~500ns, and 4us more if you use a really slow (external) RS232 driver in front of it. So the PPS arrives on the pin of the UART chip on the motherboard [115ns .. 5us] slow. From the PPS arrives, and to the kernel timestamps it, is a very long time. I wrote this to measure it: http://n1.taur.dk/edgetest.c (you will need a linux machine, gcc, and kernel-headers to compile) You use it on an NTP server that has had time to settle. It then does a polled test on the port, and the result is a bracket, without interrupt delay being a problem, within which the transition is guaranteed to have taken place: Falling edge: __ \ \ \ \ \_\_ | | | -9 ---+ | | -7 --+ | -4 -+ This is from my ntp server. What it tells me is that the falling edge of the PPS pin on the chip on the motherboard happened somewhere between 9 and 4 us before '0 seconds' on the server, that is, my server is provably slow compared to the PPS. My time1 value is already 42 us, but should apparently be 49 us to compensate for the (very large) interrupt delay. (I have an RS232 driver between the GPS and the serial port, thus I am interested in the negative edge.) Picking the wrong edge on the 18x gives you 20ms min, 100ms default, error, so that's easy to spot. The conclusion is that your path to the internet most likely has 11ms difference in the in- and outbound delays. /Kasper Pedersen ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How do I validate my PPS clocks?
On Mon, Feb 25, 2013 at 01:44:02PM +0100, Kasper Pedersen wrote: From the PPS arrives, and to the kernel timestamps it, is a very long time. I wrote this to measure it: http://n1.taur.dk/edgetest.c (you will need a linux machine, gcc, and kernel-headers to compile) Very interesting, thanks! For my machine it shows that the interrupt latency is around 12 us. I'm wondering if the kernel module could have an option which would enable a polling method to time stamp the PPS events. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How do I validate my PPS clocks?
On 2013-02-25, Miroslav Lichvar mlich...@redhat.com wrote: On Mon, Feb 25, 2013 at 01:44:02PM +0100, Kasper Pedersen wrote: From the PPS arrives, and to the kernel timestamps it, is a very long time. I wrote this to measure it: http://n1.taur.dk/edgetest.c (you will need a linux machine, gcc, and kernel-headers to compile) Very interesting, thanks! For my machine it shows that the interrupt latency is around 12 us. I'm wondering if the kernel module could have an option which would enable a polling method to time stamp the PPS events. When I ran a test many years ago I used a program to put out a rising pulse onto one of the printer port output pins, and then connected that to the parallel port nack pin. I timestamped the time just before I put out the pulse, and the time at which the interrupt occured and got roughtly 1 to 2 microseconds delay. Ie, the interrupt service was of the order of 1us. 12us seems really long. Now this might be a difference between the serial and parallel interrupts or a difference in the interrupt sevice routine, but 12us still seems a long time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
On 2/20/2013 5:00 PM, E-Mail Sent to this address will be added to the BlackLists wrote: On 2/20/2013 12:17 PM, Richard B. Gilbert wrote: The Thunderbird Mail Client does NOT automagically insert line breaks when the sender has failed to do so. Fortunately, almost everyone limits their line length to what will fit on most video terminals. Thank you and please continue to limit your line length! Thunderbird, there is [CRTL]R Edit ReWrap Also in Thunderbird you can change you config as needed: e.g. Tools - Options - Advanced: Config Editor, mailnews.display.disable_format_flowed_support false mailnews.send_plaintext_flowed true mailnews.wraplength 65 mail.compose.wrap_to_window_width true mail.wrap_long_lines true Below is a 1000 char line that displays as about 150 characters per line on my full screen display, I guess we'll see how it comes out on the other end. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Thunderbird Mail/News Client renders the above as seven, nine character columns. The columns are separated by single spaces. No problem reading it! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How do I validate my PPS clocks?
On Tuesday, February 26, 2013 6:32:53 AM UTC+10, unruh wrote: When I ran a test many years ago I used a program to put out a rising pulse onto one of the printer port output pins, and then connected that to the parallel port nack pin. I timestamped the time just before I put out the pulse, and the time at which the interrupt occured and got roughtly 1 to 2 microseconds delay. Ie, the interrupt service was of the order of 1us. 12us seems really long. Now this might be a difference between the serial and parallel interrupts or a difference in the interrupt sevice routine, but 12us still seems a long time. Awhile back when I did similar using a parallel port pin to trigger dcd with the p3-600 I am currently using for my ntp server there was an average of 2.6us difference between the 2 time stamps. For pps I use a time stamp taken at the beginning of handle_irq() in arch/x86/kernel/irq_32.c. Using a 3.5.7 kernel there is a 11us difference between that time stamp vs the serial pps time stamp taken in the ldisc code. Add some cpu load and the difference climbs to 14us. The 12us delay mentioned above is close to what I am seeing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How do I validate my PPS clocks?
On 2013-02-26, rama...@gmail.com rama...@gmail.com wrote: On Tuesday, February 26, 2013 6:32:53 AM UTC+10, unruh wrote: When I ran a test many years ago I used a program to put out a rising pulse onto one of the printer port output pins, and then connected that to the parallel port nack pin. I timestamped the time just before I put out the pulse, and the time at which the interrupt occured and got roughtly 1 to 2 microseconds delay. Ie, the interrupt service was of the order of 1us. 12us seems really long. Now this might be a difference between the serial and parallel interrupts or a difference in the interrupt sevice routine, but 12us still seems a long time. Awhile back when I did similar using a parallel port pin to trigger dcd with the p3-600 I am currently using for my ntp server there was an average of 2.6us difference between the 2 time stamps. For pps I use a time stamp taken at the beginning of handle_irq() in arch/x86/kernel/irq_32.c. Using a 3.5.7 kernel there is a 11us difference between that time stamp vs the serial pps time stamp taken in the ldisc code. Add some cpu load and the difference climbs to 14us. The 12us delay mentioned above is close to what I am seeing. Hm. That tells me that ldisc code really is pretty bad. In my case I used a parallel port module which I adapted from Linux Device Drivers by Alessandro Rubini and Jonathan Corbet. to time the parallel port IRQ handling. And I only saw 1-2 us difference. Why are you getting 12us on the ldisc code? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
