Re: [ntp:questions] Configuring FreeBSD 6.2 for use with Garmin GPS 18 LVC
Dennis Hilberg, Jr. wrote: If only the Linux kernel recompile process was as easy! I'd be interested in the problems you ran into? my mail addy is valid. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Configuring FreeBSD 6.2 for use with Garmin GPS 18 LVC
On Sun, 16 Dec 2007 23:34:48 -0800, Dennis Hilberg, Jr. [EMAIL PROTECTED] wrote: Thanks to everyone who replied to this thread. The server is running successfully. I had no problems recompiling and booting the kernel. If only the Linux kernel recompile process was as easy! The only issue I have is the GPS is loosing satellite sync periodically, whereas it rarely lost sync when it was hooked to the Linux box. Please post the output from command: uname -a Also, initially ntpd would stop using the GPS as the system peer shortly after startup, even though the GPS still had sync. I rebooted the system, thinking perhaps the links weren't created correctly, and that seems to have fixed that issue for now. Please post the contents of: /etc/devfs.conf I see a lot of this behavior in the ntp log: 16 Dec 12:06:21 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 12:06:21 ntpd[814]: kernel time sync status change 2101 16 Dec 12:07:04 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 12:07:04 ntpd[814]: kernel time sync status change 2107 16 Dec 15:30:05 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 15:34:26 ntpd[814]: kernel time sync error 2007 16 Dec 15:43:16 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 15:43:16 ntpd[814]: kernel time sync status change 2101 16 Dec 15:43:32 ntpd[814]: kernel time sync status change 2107 16 Dec 17:54:38 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 17:57:38 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 18:07:59 ntpd[814]: kernel time sync error 2307 16 Dec 18:08:17 ntpd[814]: kernel time sync status change 2107 16 Dec 21:13:28 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:22:12 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 21:28:30 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:32:16 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 21:33:54 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:36:43 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 21:44:27 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:51:25 ntpd[814]: synchronized to 64.125.78.85, stratum 1 16 Dec 21:55:16 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 23:15:18 ntpd[814]: kernel time sync error 2307 16 Dec 23:15:33 ntpd[814]: kernel time sync status change 2107 I don't know what 'kernel time sync error' and 'kernel time sync status change' mean, but I'm assuming that when ntpd switches from the GPS to one of the other internet servers that it's loosing sync. Thoughts? Please post the contents of: /etc/ntp.conf ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Configuring FreeBSD 6.2 for use with Garmin GPS 18 LVC
Speechless wrote: On Sun, 16 Dec 2007 23:34:48 -0800, Dennis Hilberg, Jr. [EMAIL PROTECTED] wrote: Thanks to everyone who replied to this thread. The server is running successfully. I had no problems recompiling and booting the kernel. If only the Linux kernel recompile process was as easy! The only issue I have is the GPS is loosing satellite sync periodically, whereas it rarely lost sync when it was hooked to the Linux box. Please post the output from command: uname -a apollo$ uname -a FreeBSD apollo.dennishilberg.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Dec 14 22:33:38 PST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC-PPS i386 Also, initially ntpd would stop using the GPS as the system peer shortly after startup, even though the GPS still had sync. I rebooted the system, thinking perhaps the links weren't created correctly, and that seems to have fixed that issue for now. Please post the contents of: /etc/devfs.conf apollo$ cat /etc/devfs.conf (comments ommitted) own cuad0 root:wheel permcuad0 0660 own cuad0.init root:wheel permcuad0.init 0660 own cuad0.lock root:wheel permcuad0.lock 0660 link cuad0 gps0 I see a lot of this behavior in the ntp log: 16 Dec 12:06:21 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 12:06:21 ntpd[814]: kernel time sync status change 2101 16 Dec 12:07:04 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 12:07:04 ntpd[814]: kernel time sync status change 2107 16 Dec 15:30:05 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 15:34:26 ntpd[814]: kernel time sync error 2007 16 Dec 15:43:16 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 15:43:16 ntpd[814]: kernel time sync status change 2101 16 Dec 15:43:32 ntpd[814]: kernel time sync status change 2107 16 Dec 17:54:38 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 17:57:38 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 18:07:59 ntpd[814]: kernel time sync error 2307 16 Dec 18:08:17 ntpd[814]: kernel time sync status change 2107 16 Dec 21:13:28 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:22:12 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 21:28:30 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:32:16 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 21:33:54 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:36:43 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 21:44:27 ntpd[814]: synchronized to 164.67.62.194, stratum 1 16 Dec 21:51:25 ntpd[814]: synchronized to 64.125.78.85, stratum 1 16 Dec 21:55:16 ntpd[814]: synchronized to GPS_NMEA(0), stratum 0 16 Dec 23:15:18 ntpd[814]: kernel time sync error 2307 16 Dec 23:15:33 ntpd[814]: kernel time sync status change 2107 I don't know what 'kernel time sync error' and 'kernel time sync status change' mean, but I'm assuming that when ntpd switches from the GPS to one of the other internet servers that it's loosing sync. Thoughts? Please post the contents of: /etc/ntp.conf apollo$ cat /etc/ntp.conf (comments omitted) restrict 127.0.0.1 server 127.127.20.0 minpoll 4 prefer fudge 127.127.20.0 flag3 1 server tick.ucla.eduiburst server nist1-sj.WiTime.net iburst server time.xmission.comiburst server ntp.your.org iburst driftfile /var/lib/ntp.drift logfile /var/log/ntp/ntp.log statsdir /var/log/ntp/ statistics loopstats peerstats sysstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen sysstats file sysstats type day enable filegen clockstats file clockstats type day enable -- Dennis Hilberg, Jr. timekeeper(at)dennishilberg(dot)com NTP Server Information: http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Why false tickers one day, and not the next day?
I'm trying to deterime why I'm having a problem with ntpd marking all the servers it contacts as false tickers one day and the next day everything is okay. I'm giving the explanation at the top of this posting, with the output of various ntpq's below. The setup is a two node FreeBSD cluster, node-A and node-B. They are on the same subnet and switch. Node-A's ntp.conf: server 210.173.160.27 # external NTP server server node-B iburst # other node server 127.127.1.1 fudge 127.127.1.1 stratum 9 driftfile /etc/ntp.drift Node-B's ntp.conf: server 210.173.160.27 # external NTP server server node-A iburst # other node server 127.127.1.1 fudge 127.127.1.1 stratum 11 driftfile /etc/ntp.drift The idea is that as the cluster expands, node-A and node-B will be time servers for the new nodes. Node-A's local clock has a lower stratum value than node-B's so in the case that the cluster loses connection to the external server, node-A is the preferred chimer for the cluster. If node-A loses its connection to the external server (but not to node-B), node-A will use node-B as its server, and vice versa. What's happening is that things go as expected for a short time with node-A and node-B using the external time server as their system peer, and using each other as candidate peers. But within a few minutes, the external time server gets marked as a false ticker by both nodes, and both nodes mark each other as false tickers. There is nothing logged by ntpd. The nodes' drifts are high: # cat /etc/ntp.drift node-A: 499.206 node-B: 497.070 The nodes and the external time server are in Asia. I have an identically setup cluster in North America using the same Asian time server, and that cluster has no problem keeping the Asian server as a peer, despite having a delay of about 120 msecs, nearly a 100 times higher than the Asian cluster's delay to the time server. The next day, after restarting ntpd on the nodes and resetting the time on all nodes with ntpdate, everything worked as expected with the time syncing properly, no false tickers, and the nodes' drifts are under 30.0. No network changes were made. Any idea on what's going on here? What would cause all the servers to be marked as false tickers, and then be fine the next day? Is there a way to configure ntpd so this won't happen? Here's the output of a number of sequential calls to ntpq -p: Just after starting up ntpd: node-A: remote refid st t when poll reach delay offset jitter node-A: == node-A: 210.173.160.27 210.173.176.251 2 u 112 256 17 1.447 -2.810 78.540 node-A: node-B .INIT. 16 u 273 5120 0.0000.000 4000.00 node-A: *LOCAL(1)LOCAL(1) 9 l 33 64 77 0.0000.000 0.002 node-B: == node-B: 210.173.160.27 210.173.176.251 2 u 101 256 17 1.358 -4.869 76.916 node-B: node-A .INIT. 16 u 265 5120 0.0000.000 4000.00 node-B: *LOCAL(1)LOCAL(1)11 l 36 64 77 0.0000.000 0.002 A few minutes later, node-A has the external server as a system peer and node-B as a candidate peer. But node-B marks the external server as a false ticker, and using Node-A as the system peer: node-A: remote refid st t when poll reach delay offset jitter node-A: == node-A: *210.173.160.27 210.173.176.251 2 u 290 512 37 1.447 -2.810 137.124 node-A: +node-B LOCAL(1)12 u 181 102410.109 -12.652 0.128 node-A: LOCAL(1)LOCAL(1) 9 l 14 64 377 0.0000.000 0.002 node-B: == node-B: x210.173.160.27 210.173.176.251 2 u 278 512 37 1.358 -4.869 133.904 node-B: *node-A LOCAL(1)10 u 172 10241 0.113 12.824 0.099 node-B: LOCAL(1)LOCAL(1)11 l 16 64 377 0.0000.000 0.002 A few minutes later. This looks great as it's what's expected: node-A: remote refid st t when poll reach delay offset jitter node-A: == node-A: *210.173.160.27 210.173.176.251 2 u 492 512 37 1.447 -2.810 137.124 node-A: +node-B LOCAL(1)12 u 383 102410.109 -12.652 0.128 node-A: LOCAL(1)LOCAL(1) 9 l 24 64 377 0.0000.000 0.002 node-B: == node-B: *210.173.160.27 210.173.176.251 2 u 480 512 37 1.358 -4.869 133.904 node-B: +node-A LOCAL(1)10 u 374 10241 0.113 12.824 0.099 node-B: LOCAL(1)LOCAL(1)11 l 24 64 377 0.0000.000
Re: [ntp:questions] Dimensioning NTP Server
Aggarwal Vivek-Q4997C wrote: Hi Iam planning to have NTP Server for something around 50,000 Clients in the Network Can Anyone guide me in dimensioning the NTP Server. What are the guidelines that I should take care for dimensioning the NTP Server I'd probably set up 3 stratum 1 servers at each site and then use multicast to distribute the NTP packets to the clients. The exact configuration can depend a great deal on what the clients need in the way of accuracy and how the network is laid out. While in general network topology is not important to NTP you can reduce the error budget by keeping the network stable. Also can I two NTP Servers running in active-stand by or in Load balancing scenario in the same network load-balancing has no meaning to NTP. You send a NTP packet and the server sends a response. You don't need anything in standby, just include all of the relevant servers in the DNS and NTP will do the rest. With the new pool conf option you can have it use all of the addresses listed in the DNS. This is not different from DNS which has no use for a load balancer or standby either. Danny Regards Vivek Aggarwal ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why false tickers one day, and not the next day?
The nodes' drifts are high: # cat /etc/ntp.drift node-A: 499.206 node-B: 497.070 500 ppm is the limit. The next day, after restarting ntpd on the nodes and resetting the time on all nodes with ntpdate, everything worked as expected with the time syncing properly, no false tickers, and the nodes' drifts are under 30.0. No network changes were made. There is/was some case where ntpd would get confused and bang its head against the limits. It would often recover if you rebooted the system or maybe just restarted ntpd. I think something in that area was fixed a while ago, but I don't remember the details and I could easily be wrong. I'm pretty sure you aren't the first person to ask a question like that. What version of ntpd are you using? Can you easily upgrade to a recent ntp-dev? Have you seen that more than once? -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
