Re: [ntp:questions] Using Trimble TSIP under Linux
On 31/10/2012 21:58, E-Mail Sent to this address will be added to the BlackLists wrote: [] IIRC the Raspberry pi has a GPIO pin 24 Hard PPS patch, so the USB Serial PPS issue can be avoided. Correct - and it works very well: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#pps -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 31/10/2012 21:04, unruh wrote: On 2012-10-31, Richard B. Gilbert rgilber...@comcast.net wrote: [] NTPD is a slow starter! Ideally, you will only start it once and let it run for a few months. How slow is a slow start?. It can take NTPD up to ten hours to synchronize within + or - 50 nanoseconds with whatever you are using as It will never get to within 50nsec. The interrupt processing is far more variable than that. You might get to withing a few micro seconds. On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
David Taylor wrote: On 31/10/2012 21:04, unruh wrote: On 2012-10-31, Richard B. Gilbert rgilber...@comcast.net wrote: [] NTPD is a slow starter! Ideally, you will only start it once and let it run for a few months. How slow is a slow start?. It can take NTPD up to ten hours to synchronize within + or - 50 nanoseconds with whatever you are using as It will never get to within 50nsec. The interrupt processing is far more variable than that. You might get to withing a few micro seconds. On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. I'm on NetBSD-6 and ntpd 4.2.6p5 although I don't believe the previous versions were any worse. The rstarts are usually within around 15-30 min to be better than 1 ms and replying to requests. I lost 7 x pcs Jun-Sept this year after local mains substation transformer self destructed so my system with GPS is down. That would be within a few usec within an hour but was sensitive to large temperature and load changes with nightly excursions to 30 usec for short periods. The example I've seen as to getting sub usec was GPS combined with a remote stable system clock source (from a TAPR board). I've too much on at the moment repairing/replacing the failed systems to setup the Ru clock I bought off ebay. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 01/11/2012 08:40, David Woolley wrote: David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? That's the offset as stated by NTP. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Intel i210 and timed transmission (802.1Qav)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm researching how to increase the precision one can achieve by using our NTP-servers, and bumped into this chip (Intel i210) today. It seem that 802.1Qav support adds LaunchTime, to tell the transmit buffer when a packet is supposed to go out on the wire. Is it just me or could this be used in conjunction with T4 in the NTP-packet for increased precision, just as the goal with interleaved mode? At the same time the chip, just as Intel 82580 and i350, supports per-packet timestamping on the RX side. Any comments? Given that i210 is supposed to replace 82574 it should hopefully be found everywhere quite soon. Announcement: http://communities.intel.com/community/wired/blog/2012/10/18/i210-launch-announcement Product brief: http://www.intel.com/content/www/us/en/ethernet-controllers/i210-ethernet-controller-family-brief.html Datasheet (specifically 7.2.2.2.3): http://www.intel.com/content/www/us/en/ethernet-controllers/i210-ethernet-controller-datasheet.html // Jonatan Walck Netnod Internet Exchange -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQkS3QAAoJEFwg9i9GDX+nCSMP/368yVaVf3c0OD3sft0yzbXp 0jZOtjEcwSiGDTFdv7fz1foNUypZo79BuB7Bcr9dYL770eD337WPMPK8fLc3BZ6C y30r8MxBbaf2YxMbfZJs5Fyg1CK79PHONo7+1L3Ht4sK7GFtpq+PfXoLAFTczWy2 kaxxWAyd6wjDi9Uuylj7nAT5YMZuu9c0PcE5nZ3R0uuBupZu1CyEEBWwzrrqhS8/ 5OYwQpS/p5kWcY09OWhrDqaIVZweE4L7sBZezlwNaCP0tAE+IO/Dh6oKLZAKbYI9 +mEuSl6/XYoJgcofDtFuzHHMjmrRcIulDuZEBgffSA790m0o+jQunTDBH5Q2DFCB doiSl7GcDcZ/8q6p+tffp0fdPR3oSf5HA9GIj0F+mQgZFE2yLD0BDuTKDkAIPM9h mCpDtKKITf+60i+ZnRxeR2pBo7uysBlW+uDMRatFze9IziMxkqK187zC/7HjjSJS p1QjgFBDiEFjHpuEc2KMUnWNqdXxYuhMovM0hHGLkk0RTtm9r7ECyABJw4LPe17y 3/5gOQ4bAUDyrNoTjM/eOMv6Q33GVk1nffyKUom7HndufYm19aAMmJTs3Nhli33C AFN2BOjITMpHegn+/sDEi20SQPxchJpDqdXdnQe/93fj38wz1uOaaVCMnxfFENpL 0y9Kmm7bqCqzZBtmiPyQ =lyNL -END PGP SIGNATURE- ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
David Taylor wrote: On 01/11/2012 08:40, David Woolley wrote: David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? That's the offset as stated by NTP. That's not the time error. Under ideal circumstances, it is several times higher than the actual error, but with a low value like that, it could easily be orders of magnitude worse (e.g. if there were interrupt latencies in the 100s of microseconds and up, or, for network time, if there were asymmetric delays in the milliseconds). At 250 microseconds, do they all have the same sign? The claim for chrony would be that it gets to the state where the offsets are balanced about zero, much faster. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Getting precise variables?
Is there any way to poll ntp for full precision variables? If you do an ntpq query for offset, you get 1 us precision: locke:~# ntpq -c rv 0 offset locke offset=-0.001 But loopstats records offset with 1 ns precision: locke:~# tail -n 1 /var/log/ntpstats/loopstats.20121101 56232 50257.989 -0.01426 0.039 0.0 0.000774 4 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 2012-11-01, David Woolley david@ex.djwhome.demon.invalid wrote: David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? I think he means the clock offset from a PPS signal. (otherwise that does not mean much) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 2012-11-01, David Woolley david@ex.djwhome.demon.invalid wrote: David Taylor wrote: On 01/11/2012 08:40, David Woolley wrote: David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? That's the offset as stated by NTP. That's not the time error. Under ideal circumstances, it is several times higher than the actual error, but with a low value like that, it could easily be orders of magnitude worse (e.g. if there were interrupt latencies in the 100s of microseconds and up, or, for network time, if there were asymmetric delays in the milliseconds). Interrupt latencies in my measurements tended to be at the one or 2 microsecond level. (drive a pin on the parallel port up, measuring when you did that, and then measuring the interrupt output time and looking at the difference.) Of course they are all one way, so averaging does not make this error smaller. When I once tried to cascade two interrupt service routines on the same interrupt togetter, the second was about 10usec later than the first-- indicating the interrupt service time of the first. At 250 microseconds, do they all have the same sign? The claim for chrony would be that it gets to the state where the offsets are balanced about zero, much faster. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
unruh wrote: On 2012-11-01, David Woolley david@ex.djwhome.demon.invalid wrote: David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? I think he means the clock offset from a PPS signal. (otherwise that does not mean much) Well actually, he means the offset from the estimated PPS time, not the actual PPS time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
unruh wrote: Interrupt latencies in my measurements tended to be at the one or 2 microsecond level. (drive a pin on the parallel port up, measuring when The Raspberry Pi is basically a headless PDA, using smart phone type processors. It is optimised for power consumption, not speed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 2012-11-01, David Lord sn...@lordynet.org wrote: David Taylor wrote: On 31/10/2012 21:04, unruh wrote: On 2012-10-31, Richard B. Gilbert rgilber...@comcast.net wrote: [] NTPD is a slow starter! Ideally, you will only start it once and let it run for a few months. How slow is a slow start?. It can take NTPD up to ten hours to synchronize within + or - 50 nanoseconds with whatever you are using as It will never get to within 50nsec. The interrupt processing is far more variable than that. You might get to withing a few micro seconds. On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. I'm on NetBSD-6 and ntpd 4.2.6p5 although I don't believe the previous versions were any worse. The rstarts are usually within around 15-30 min to be better than 1 ms and replying to requests. I lost 7 x pcs Jun-Sept this year after local mains substation transformer self destructed so my system with GPS is down. That would be within a few usec within an hour but was sensitive to large temperature and load changes with nightly excursions to 30 usec for short periods. Yes, ntp is slow to respond to rate changes. That is its main problem in getting the ultimate accuracy (since rate changes due to temp changes are probably the dominant source of inaccuracy on most systems). chrony responds to such rate changes much faster, and keeps the time on track with utc much better. It probably comes at the cost that the rate of the system clock is not as well disciplined as on ntp, although that is irrelevant if the rate keeps changing due to temp changes. what I mean is that if your noise model is gaussian random noise on the packet timing, then ntpd will settle down to a better rate correction than will chrony. But that is not the dominant noise source on most systems. The example I've seen as to getting sub usec was GPS combined with a remote stable system clock source (from a TAPR board). I've too much on at the moment repairing/replacing the failed systems to setup the Ru clock I bought off ebay. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting precise variables?
On 01/11/2012 14:00, Mike S wrote: Is there any way to poll ntp for full precision variables? If you do an ntpq query for offset, you get 1 us precision: locke:~# ntpq -c rv 0 offset locke offset=-0.001 But loopstats records offset with 1 ns precision: locke:~# tail -n 1 /var/log/ntpstats/loopstats.20121101 56232 50257.989 -0.01426 0.039 0.0 0.000774 4 Yes, I agree with that request, and the kind folks Markus Schöpflin, Harlan Stenn, Martin Burnicki, and Dave Hart responded to the bug I reported: http://bugs.ntp.org/show_bug.cgi?id=2164 You may like to update to a more recent version (ntp4.2.7p304 or later) and get nanosecond precision from ntpq -c rv: C:\Users\Davidntpq -c rv 192.168.0.14 associd=0 status=011d leap_none, sync_pps, 1 event, kern, version=ntpd 4.2.7p314@1.2483 Mon Oct 29 15:30:42 UTC 2012 (3), processor=armv6l, system=Linux/3.2.27-pps-g965b922-dirty, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.180, refid=PPS, reftime=d43d2c0f.12a81e6b Thu, Nov 1 2012 17:12:47.072, clock=d43d2c1b.31e62411 Thu, Nov 1 2012 17:12:59.194, peer=7335, tc=4, mintc=3, offset=-0.000546, frequency=-44.649, sys_jitter=0.001907, clk_jitter=0.000, clk_wander=0.000 -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 01/11/2012 09:27, David Lord wrote: [] I lost 7 x pcs Jun-Sept this year after local mains substation transformer self destructed so my system with GPS is down. [] David Very sorry to hear about that David, a true pain! Perhaps a chance to replace with some lower-power kit, though? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 01/11/2012 13:36, David Woolley wrote: David Taylor wrote: [] That's the offset as stated by NTP. That's not the time error. Under ideal circumstances, it is several times higher than the actual error, but with a low value like that, it could easily be orders of magnitude worse (e.g. if there were interrupt latencies in the 100s of microseconds and up, or, for network time, if there were asymmetric delays in the milliseconds). At 250 microseconds, do they all have the same sign? The claim for chrony would be that it gets to the state where the offsets are balanced about zero, much faster. Well, it's the best data I have available to plot, and seems to indicate well how changes in configuration of hardware and software affect timekeeping. The device shows NTP offsets in the order of 10 microseconds from other PPS-driven network sources. I believe the interrupt latency on that 700 MHz processor is around 30-50 microseconds with the Raspberry Pi hardware. For what I need it's more than adequate - an absolute error of less than a millisecond would not be noticed by the applications I run. Using different software isn't going to affect the interrupt latency unless it had some way of measuring that with external hardware. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
On 2012-11-01, David Woolley david@ex.djwhome.demon.invalid wrote: unruh wrote: On 2012-11-01, David Woolley david@ex.djwhome.demon.invalid wrote: David Taylor wrote: On a recent restart from cold, the server here took about 15 minutes to get to within 250 microseconds, and about an hour to be within 10 microseconds. Ultimately it is within about 3 microseconds. 3 microseconds of what? How are you measuring the difference between software clock time and UTC, independently of NTP? I think he means the clock offset from a PPS signal. (otherwise that does not mean much) Well actually, he means the offset from the estimated PPS time, not the actual PPS time. If you mean by estimated the time offset as determined via the interrupt processing then I agree. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step in GPSserver?
David Taylor wrote: On 01/11/2012 09:27, David Lord wrote: [] I lost 7 x pcs Jun-Sept this year after local mains substation transformer self destructed so my system with GPS is down. [] David Very sorry to hear about that David, a true pain! Perhaps a chance to replace with some lower-power kit, though? Four of those were/are 50W each and a low power Soekris equivalent is too expensive for me if the existing motherboards and ram are still working. I need two or three ethernet and am unable to find equivalent boards for less than arm + leg prices. How many watts do I need to save for spending an extra 200 quid per board? I now have a couple of new Atom boards but overlooked the lack of eide interfaces :-( I've never tried PXE-boot but that'ts option one. After first one the remainder will be very easy. I'm also investing in a DIY surge protector per system as the three UPS I had were no protection and failed. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What is the NTP recovery time from 16s step inGPSserver?
That is one description. Another would be it is a fully functional linux computer with LAN, HDMI, SVideo, Audio, USB, Serial, and a GPIO bus with the footprint of a credit card, no moving parts which draws only 2-3 watts for US$35. My pi units run various processes such as NTP, web hosting and data IO at a fraction of the cost of conventional hardware. Step changes in computing technology are pretty rare. Having developed on them a couple of months, I put the pi into that category. Oh yes, and the silence of the pi's is worth the US$35 alone. It really depends if you prefer your glass to be half full or half empty ;-) regards pk -Original Message- From: questions-bounces+p.kennedy=fugro.com...@lists.ntp.org [mailto:questions-bounces+p.kennedy=fugro.com...@lists.ntp.org] On Behalf Of David Woolley Sent: Friday, 2 November 2012 12:32 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] What is the NTP recovery time from 16s step inGPSserver? unruh wrote: Interrupt latencies in my measurements tended to be at the one or 2 microsecond level. (drive a pin on the parallel port up, measuring when The Raspberry Pi is basically a headless PDA, using smart phone type processors. It is optimised for power consumption, not speed. ___ 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
