Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
On Dec 18, 7:56 pm, Unruh unruh-s...@physics.ubc.ca wrote: That you PPS has an offset of 20-40usec does surprize me. It should be much better than that (2-4ms is more typical) Running time was not long enough at that point. In the last 12 hours I have these values: Min: -4 us, Max: +6.9 us, Average: 319 ns ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Hi there Hal Murray wrote: That site is unlikely to be down for long. It's still down. I can ping time.nist.gov, but it won't FTP. Are you behind a NAT box? I need to use the passive mode for ftp. No. I also tried the shell box at my ISP. Same result. Regards, Rob ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Hi there David L. Mills wrote: I am told the file is on all NTP servers operated by NIST. See the list of public servers at NIST or www.ntp.org. ftp://ntp-a.boulder.nist.gov/pub/leap-seconds.3427142400 works Thanks! Regards, Rob ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] GPS Trimble Acutime Gold - USB Interface
I have a Trimble Acutime Gold GPS[1] and I got some problems installing that device in both FreeBSD and Linux. That GPS has an USB Interface with FTDI support. FreeBSD configuration: 1) kldload uftdi 2) dmesg: ucom0: FTDI Dual RS232, class 0/0, rev 2.00/5.00, addr 2 on uhub3 ucom1: FTDI Dual RS232, class 0/0, rev 2.00/5.00, addr 2 on uhub3 3) ln -s /dev/cuaU0 /dev/palisade0 (I tried cuaU1 with no success) 4) ntpd.conf configured without event polling [2]: # The Primary reference server 127.127.29.0 # Trimble Palisade GPS. # Set packet delay fudge 127.127.29.0 time1 0.020 # and set flag2 to turn off event polling. fudge 127.127.29.0 flag2 1 First problem: For some reason event polling (fudge options commented) does not work. The GPS turn unreachable. Second problem: My GPS is a falseticker: $ ntpq -np remote refid st t when poll reach delay offset jitter == x127.127.29.0.GPS.0 l3 16 3770.000 -45.446 21.072 *192.168.193.5 .GPS.1 u 50 6434.849 110.134 7.145 192.168.192.61 192.168.193.52 u 48 6436.084 110.903 9.221 +192.168.254.229 192.168.0.42 2 u 49 643 11.550 110.253 7.524 I appreciate any help. [1] http://www.trimble.com/timing/acutime-gold-gps-antenna.aspx?dtID=overview [2] http://doc.ntp.org/4.1.2/driver29.htm -- Pedro ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
On 19 dez, 09:43, Rob van der Putten r...@sput.nl wrote: Hi there David L. Mills wrote: I am told the file is on all NTP servers operated by NIST. See the list of public servers at NIST orwww.ntp.org. ftp://ntp-a.boulder.nist.gov/pub/leap-seconds.3427142400works Thanks! Regards, Rob Hi there, I used the below tutorial to set the leapseconds, but, the leap_armed is not showed when the command ntpq is executed. I´m using freebsd 7.0 and the ntp version ntp-dev-4.2.5p150. : What can be wrong ? Thank´s NTPQ # a# ntpq -c rv status=01fd leap_none, sync_atomic, 15 events, event_13, version=ntpd 4.2.5p...@1.1795-o Fri Dec 19 16:47:03 UTC 2008 (1), processor=i386, system=FreeBSD/7.0-RELEASE-p6, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.239, refid=PPS, reftime=ccf66913.a1585ecd Fri, Dec 19 2008 16:40:19.630, clock=ccf66914.66d46964 Fri, Dec 19 2008 16:40:20.401, peer=49506, tc=4, mintc=2, offset=0.002, frequency=40.487, sys_jitter=0.003, clk_jitter=0.000, clk_wander=0.000, tai=33, leapsec=20090101, expire=20090628 # ## LOG ### # /usr/local/bin/ntpd -d -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f / var/db/ntpd.drift ntpd 4.2.5p...@1.1795-o Fri Dec 19 16:47:03 UTC 2008 (1) addto_syslog: proto: precision = 1.396 usec addto_syslog: ntp_io: estimated max descriptors: 11095, initial socket boundary: 20 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 bce1, 200.160.7.186#123 Enabled restrict: addr c8a007ba mask mflags 3000 flags 0001 addto_syslog: Listening on interface #3 lo0, fe80::1#123 Enabled addto_syslog: Listening on interface #4 lo0, ::1#123 Enabled addto_syslog: Listening on interface #5 lo0, 127.0.0.1#123 Enabled restrict: addr 7f01 mask mflags 3000 flags 0001 addto_syslog: Listening on routing socket on fd #26 for interface updates loop_config: item 1 freq 0.00 event at 0 0.0.0.0 c010 0d system event: kern kernel time sync enabled restrict: addr mask mflags flags 0192 restrict: addr c8a00300 mask ff00 mflags flags 01b0 restrict: addr c8a00500 mask ff00 mflags flags 01b0 restrict: addr c8a00100 mask ff00 mflags flags 01b0 restrict: addr c8a00780 mask ff80 mflags flags 0190 restrict: addr c8ba7dc8 mask mflags flags 01b0 restrict: addr c8a1 mask ffc0 mflags flags 01b0 restrict: addr c8bd2801 mask ffc0 mflags flags 01b0 restrict: addr c8c0e801 mask ffc0 mflags flags 01b0 restrict: addr c814ba5e mask mflags flags 01b0 restrict: addr c814ba4b mask mflags flags 01b0 restrict: addr c8a007a5 mask mflags flags 01b0 restrict: addr c8137778 mask mflags flags 01b0 restrict: addr 8f6bff0f mask mflags flags 01b0 restrict: addr c02bf412 mask mflags flags 01b0 restrict: addr c00529d1 mask mflags flags 01b0 restrict: addr c814ba4b mask mflags flags 01b0 addto_syslog: leap epoch 3439756800 expire 3455136000 TAI offset 34 from /etc/ntp.leap addto_syslog: set_peerdstadr(127.127.6.0): change interface from null to 127.0.0.1 key_expire: at 0 associd 28259 peer_clear: at 0 next 1 associd 28259 refid INIT audio_config_read: reading /etc/ntp.audio0 idev /dev/audio0.0 cdev /dev/mixer0 agc line 12 monitor vol 0 audio_init: /dev/audio0.0 bufsiz 320 audio_init: orig: play_size 128, rec_size 128 audio_init: want: play_size 320, rec_size 320 audio_init: set: play_size 128, rec_size 128 audio_init: play_rate 8000, rec_rate 8000, play_format 0x1, rec_format 0x1 audio_show: ctl_fd 6 event at 0 IRIG_AUDIO(0) 8011 81 peer event: mobilize assoc 28259 newpeer: 127.0.0.1-127.127.6.0 mode 3 vers 4 poll 4 4 flags 0xa9 0x1 ttl 0 key addto_syslog: set_peerdstadr(127.127.22.0): change interface from null to 127.0.0.1 ## TUTORIAL ## 1) Download to /etc the NIST leapseconds file leap-seconds.3427142400 (or the latest) from ftp://time.nist.gov/pub/ by passive ftp. Then make a symlink from the generic name ntp.leap to the file: | # cd /etc/ | # wget --passive-ftp ftp://time.nist.gov/pub/leap-seconds.3427142400 | # ln -s leap-seconds.3427142400 ntp.leap 2) Add to /etc/ntp.conf this line: | leapfile /etc/ntp.leap 3) Restart the NTP daemon. After it is synced, you can verify all worked well using the ntpq readvar command, by checking the current TAI offset, looking at the date of the (future) leap event, and at the validity limit of the leapfile: | $ ntpq -c rv 0 leap,tai,leapsec,expire | associd=0 status=0259 leap_none, sync_lf_radio, 5
Re: [ntp:questions] Linux and mlockall()
In article %sbusjd...@khar-pern.talamasca.ocis.net, Michael Deutschmann mich...@talamasca.ocis.net writes: Michael One thing I thought I knew about the standard NTP distribution, was Michael that it uses the mlockall() call, when available, to prevent Michael swapping and thus gain more repeatable latencies. Yup, and if there is enough memory on the box that it doesn't swap, there is less need for mlockall(). As I recall, there are OSes wher mlockall() will reserve extra memory for the future, and that may be where the problem lies. Michael However, recently I had cause to run nm on ntpd, and was Michael surprised to note no references to mlockall(). A check with ps Michael confirmed that ntpd was indeed no longer locked in memory. Michael I checked the source, and it seems back in 2004 someone altered the Michael source to suppress detection of mlockall() on Linux (my platform), Michael citing resolver problems. I have a vague recollection of that. Michael I haven't seen any discussion of this on this newsgroup yet. Michael Considering that people who object to mlockall() usage on the Michael grounds that it prevents running stock ntpd on limited-real-memory Michael toasters have been given the cold shoulder, four years is a long Michael time to deprive Linux users of its benefits. OK. Michael Since ntpd does its resolving from a secondary process, it would Michael seem that the problem could be avoided by moving the mlockall() Michael call to after the intres process is forked. Except that until we get an async resolver library, there is still a very real possibility that somebody will use a runtime config command to add a new server which will fork a resolver process again... Michael resolver problems probably wouldn't bite me, since I use IP Michael addresses only in my configuration files, so that I can start ntpd Michael before named. So it should be safe for me to hack the configure Michael script so mlockall() is used anyway, right? Yes, and I'd be real curious to see how big a memory footprint ntpd takes for you before and after this change. Michael Also, calling this a Linux problem is likely careless. I'd Michael imagine the root of the incompatibility is probably in the GNU libc Michael that is widely used with the Linux kernel. You are probably right, and the only places folks ever complained to me about the mlockall() problem was on linux-based systems, so that is what I called it. To change this would require a way to see if the kernel is using libc and test for it that way, instead of the current test which simply checks the type of the target host triplet. Please see http://support.ntp.org/bin/view/Support/LockingNtpdInMemory and the related links on that page. http://support.ntp.org/bin/view/Dev/NewNtpConfFormat#Memory_locking also has some information that might be useful. Please feel free to add questions or comments if you like. -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS Trimble Acutime Gold - USB Interface
Pedro, First, USB serial devices generally have a *lot* of jitter on them. Second, have you seen: http://support.ntp.org/Support/ConfiguringTrimblePalisadeAcutimeRefclocks -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS Trimble Acutime Gold - USB Interface
Hi Pedro, You will be in good shape with USB serial if you can find some other way to get a PPS signal into your box. H -- Hi Harlan, Trimble native serial GPS was discontinued. I just received the device without opportunity to choise other. Yes, I have seen the support page about Trimble/Palisade but I could not find any thing to justify the reported problems. offset now ~ 150ms :( Thanks, Pedro On Fri, Dec 19, 2008 at 7:27 PM, Harlan Stenn st...@ntp.org wrote: Pedro, First, USB serial devices generally have a *lot* of jitter on them. Second, have you seen: http://support.ntp.org/Support/ConfiguringTrimblePalisadeAcutimeRefclocks -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS Trimble Acutime Gold - USB Interface
I see this has an event capture input. Has anyone tried using this vs bringing in the pps to see if they can lower the jitter on interrupt handler? -Original Message- From: questions-bounces+gdowd=symmetricom@lists.ntp.org [mailto:questions-bounces+gdowd=symmetricom@lists.ntp.org] On Behalf Of Harlan Stenn Sent: Friday, December 19, 2008 3:43 PM To: Pedro Torres Cc: Harlan Stenn; questions@lists.ntp.org Subject: Re: [ntp:questions] GPS Trimble Acutime Gold - USB Interface Hi Pedro, You will be in good shape with USB serial if you can find some other way to get a PPS signal into your box. H -- Hi Harlan, Trimble native serial GPS was discontinued. I just received the device without opportunity to choise other. Yes, I have seen the support page about Trimble/Palisade but I could not find any thing to justify the reported problems. offset now ~ 150ms :( Thanks, Pedro On Fri, Dec 19, 2008 at 7:27 PM, Harlan Stenn st...@ntp.org wrote: Pedro, First, USB serial devices generally have a *lot* of jitter on them. Second, have you seen: http://support.ntp.org/Support/ConfiguringTrimblePalisadeAcutimeRefclock s -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS Trimble Acutime Gold - USB Interface
Hi Harlan, Trimble native serial GPS was discontinued. I just received the device without opportunity to choise other. Yes, I have seen the support page about Trimble/Palisade but I could not find any thing to justify the reported problems. offset now ~ 150ms :( Thanks, Pedro On Fri, Dec 19, 2008 at 7:27 PM, Harlan Stenn st...@ntp.org wrote: Pedro, First, USB serial devices generally have a *lot* of jitter on them. Second, have you seen: http://support.ntp.org/Support/ConfiguringTrimblePalisadeAcutimeRefclocks -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
