[questions] Re: Unknown peer listed in ntpq -p output
On 2022-04-22, A C <4433...@gmail.com> wrote: > Recently I was looking at the output of the ntpq -np command on a > stratum 2 server I manage and noticed an IP I did not recognized in > the output. (The 3 usual stratum 1s were there, but then a fourth one > (a stratum 3) was also listed.) That fourth entry is listed as a > stratum 3, and the associations details show that it is using NTP > authentication, so I assume this is a legitimate client that is using > a symmetric key to authenticate with my NTP server. > My ntp stratum 2 server is configured with the "restrict default > nomodify notrap nopeer noquery" so I assume that external clients > cannot add servers to the list using tools such as ntpq/ntpdc. If they have a valid key, they can create symmetric associations with your server by specifying your server as a peer in their config. You would need to have the "noepeer" option in the restrictions to prevent that, but this option is not supported in the ntp package you are using. -- Miroslav Lichvar -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server
On 2021-05-18, Andreas Schick wrote: > One further idea I had was just modifying some startup scripts (which > run before ntpd process is started and after the network is up) to > include some from of a ntpd-run-sync-and-quit or ntpdate call that > steps the clock at system startup on the ARM device. Another possibility is to start ntpd normally and wait for it to set the clock. There is the ntp-wait script for that. On systemd-based distributions there is a time-sync target which delay start of services that need accurate clock. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 2036 rollover problem
On Tue, Mar 16, 2021 at 03:20:13PM +0300, Евгений Никишин wrote: > I am currently working on the Y2036 problem. My app receives the current > time from an NTPv4 compatible server (ntpd). As far as I understand, the > ntpd server response contains a timestamp in NTP Timestamp format (i.e. as a > combination of Seconds and Fraction). I want to change it to NTP Date > Format, but I don't understand if it is supported by the standard. Could you > clarify whether or not there are any packet header parameters that allow > querying the time in NTP Date Format (i.e. as a combination of Era Number, > Era Offset and Fraction). NTPv4 doesn't exchange the era number. It's a feature that was proposed for NTPv5, but that's likely too far in the future to be available. In your client you can hardcode a minimum NTP timestamp (e.g. from the build time) and add 2**32 seconds to any timestamp smaller than that. That should work as long as you update/rebuild the application at least once per ~136 years. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How is the BIG guys (Google. FB etc) DNS and NTP architecture
On 2020-10-21, William Unruh wrote: > On 2020-10-21, CRasch Net wrote: >> Facebook is now using Chrony, you can read about their implementation: >> >> Building a more accurate time service at Facebook scale >> https://engineering.fb.com/production-engineering/ntp-service/ > > Interesting. While I agree that chrony is more precise, I think that > their results for ntpd are worse than they should be. ntpd can > certainly do better than 1ms scatter/accuracy (and chrony can do better > than 100us.There is something weird about their network paths.) About 10 > years I ran a number of tests of chrony vs ntpd. and got about a fctor > of 3-10 better, not 100. Interrupt latency/clock reading for chrony gave > about 1us fluctuations. It's not clear how ntpd and chrony were configured in their tests. The ntpq/chronyc outputs show a poll of 6, which is too long for a highly stable synchronization in a local network. If they were using the default minpoll 6 and maxpoll 10, a factor of 100 would not surprise me. ntpd doesn't adjusts its polling very well when it has stable measurements, so it would be effectively comparing ntpd polling at 10 vs chrony polling at 6. > I find this whole thing about leap second smoothing to be a real farce. > Just let the step occur instead of delivering the wrong time for hours. > Or if you want, run your clocks on TIA not UTC and make the leapsecond > conversion in the interpretation as is done for timezones. Would anyone > advise leap day smoothing every 4 years so that we do not have trouble > with our calenders? Well, yes. The trouble is that there are applications that break on backward step, they need synchronized clocks, and not all NTP clients can be configured to make a consistent slew on the leap second. So, the easiest way to fix this is to make a slew on the server and hide the leap second from the clients. When you internally do this everywhere and you want to provide a public NTP service, it's easier to just serve your internal leap-smeared time. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On Mon, Oct 19, 2020 at 12:43:47PM +0200, Vitezslav Samel wrote: > On Mon, Oct 19, 2020 at 09:49:36AM +0200, Miroslav Lichvar wrote: > > Not an FPGA, but the Intel I210 costs about $50 and it has a nice > > hardware clock with PPS input/output, which is well supported in > > Linux. It's a NIC, so you can use the same clock for timestamping PPS > > and NTP packets, avoiding any asymmetries on the PCIe bus between the > > PPS-timestamping hardware, CPU, and the NIC, which allows you to make > > an NTP server accurate to few tens of nanoseconds. > > Any pointers/info how to use this in Linux? In the Linux kernel source there is a testptp utility in the tools/testing/selftests/ptp directory, which can enable the PPS input and/or output and print the captured timestamps. For configuring NTP (chrony), see this blog post from Dan Drown: https://blog.dan.drown.org/apu2-ntp-server-2/ Note that he uses an onboard variant of the NIC, which doesn't have a pin header for the SDP and requires some soldering, but that's not an issue with the I210: http://linuxptp.sourceforge.net/i210/i210-SDPs.jpg With the described configuration there is some extra jitter in NTP timestamps due to the system clock being used as the main clock. If you wanted to avoid that to improve stability, you would need to patch chronyd to serve time directly from the hardware clock. Let me know if you want more details. If you just want to synchronize the hardware clock to its PPS input, or you want to provide a PTP service with ptp4l, in the linuxptp package there is a ts2phc program for that. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote: > Another thing that gets into the way are the energy saving strategies > modern CPUs employ, like reducing the clock speed and distribute load > over cores. So unless you nail down the IRQ to a certain core and > prevent cores from going to full sleep, the interrupt rescheduling can > add another few usecs. IRQ processing was never a high speed thing on > x86 platforms to start with, and it never kept up with speed boost all > other parts of the architecture got, AFAIK. Setting the CPU to a fixed frequency (e.g. using the userspace governor) can help a lot with the stability of timestamping, not just of the PPS signal, but also received NTP packets. > In short, your numbers look familiar, and I don't know how to improve > the much without dedicated hardware. I'm dreaming of some FPGA hardware > on a PCIe board at an affordable price... Not an FPGA, but the Intel I210 costs about $50 and it has a nice hardware clock with PPS input/output, which is well supported in Linux. It's a NIC, so you can use the same clock for timestamping PPS and NTP packets, avoiding any asymmetries on the PCIe bus between the PPS-timestamping hardware, CPU, and the NIC, which allows you to make an NTP server accurate to few tens of nanoseconds. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions] Performance estimation
On Wed, Jun 17, 2020 at 09:09:22AM +0100, David J Taylor wrote: > I don't know what the path is on the RPi for the PPS interrupt but I would > expect it to be similar to that on the BBblack, so that latency graph is of > interest - thanks! FWIW, there is a polling version of the GPIO PPS driver, which avoids the interrupt latency with a busy loop and which might be useful for measuring the latency. It will make the system clock more accurate, but it might have a negative impact on the accuracy of the NTP server as the PPS interrupt latency compensates the NIC interrupt latency (when the NIC driver is not polling). In my tests with a RPi 3B+ the RX timestamping error was about 20us larger than the TX error. The driver is here: https://github.com/mlichvar/pps-gpio-poll Getting it to work with the Raspbian kernel might be tricky. IIRC I didn't work for me the last time I tried. I prefer OpenWrt on these small computers. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-16, David Taylor wrote: > The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock > resolution is in the nanosecond range. For best timekeeping performance, you would want to set the CPU frequency to a fixed value. > I would also like to see whether the characteristics of the GPS and its > location make a measurable difference to the RPi's timekeeping. For > example: is it better to have a GPS with 3 service capability at a > location where the signal is poor, or is it masked by the RPi's > performance? All this with kernel-mode PPS. The interrupt latency of the PPS timestamping is probably much larger than any errors related to GPS, so I'd say it doesn't matter. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-15, David Taylor wrote: > [Been trying to send through e-mail to ntp-questions, but anything I > send gets rejected!] The news<->mail gateway has been broken for a very long time, e.g. responses to the mailing list are not getting back to the original posters in the ntp group, so maybe it would be better to turn it off and ask people to subscribe to both if interested. > The lightly-loaded Raspberry Pi cards are all showing low numbers of > jitter, and it would be really useful to get that in more than three > decimal places of milliseconds. You would probably need to patch ntpd to report the values in a better precision. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-14, David Taylor wrote: > When using the ntpq -crv command, which is the better measure of system > performance - clk_jitter or sys_jitter? I've look for the definitions > and I'm thinking sys_jitter but perhaps someone could please remind me > of the difference? clk_jitter seems to be the jitter of the system clock as it is being updated with offsets, and sys_jitter seems to be the jitter of the selected peer, or the combined peers after clustering. https://www.eecis.udel.edu/~mills/ntp/html/cluster.html -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
On 2020-06-08, a...@avtodoria.ru wrote: > Currently i'm looking at ntp sources. as i said i have read data from > SHM at June 4th, now i'm trying to write them into SHM. What i see in > ntpq output: ... > You can see reftime is June 4th, but nevertheless offset is small. How > does it work? When i debug it small offset is before even clock select > algotirhm, so who calculates such small offset at June 8th It's not possible to replay old SHM data at a different time. Have a look at the SHM structure. There are receiveTimeStamp fields, which tell at what time the sample was captured (system time) and clockTimeStamp fields which tell what time the reference clock had at the time of the capture. The difference is the offset. If you want to replay an offset, you need to put in the SHM segment the current system time and the same time adjusted for the offset, so their difference is the offset as it was before. But this completely ignores the process that is controlling the clock, so I'm not sure what value this exercise has. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
On 2020-06-08, a...@avtodoria.ru wrote: > понедельник, 8 июня 2020 г., 10:52:36 UTC+3 пользователь Miroslav > Lichvar написал: >> If you need something to report a large offset to ntpd via SHM, you >> could try this program for testing leap seconds: >> >> https://github.com/mlichvar/leapshm > Thank you ver much. Please can you explain the params program uses. > Second can be path to unix socket or something else starting not with > "/" to use SHM. What about third param ? It's the number of seconds before the hardcoded leap second time (1 Jul 2015 00:00:00 UTC) where the time fed by the program should start. E.g. if it was 600, it would start 10 minutes before the midnight of the leap second. You would probably want to start with a larger number (if you don't want to test a leap second) and also change the LEAP_TIME constant to a current date. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
On 2020-06-04, a...@avtodoria.ru wrote: > I want to add two another sources to fullfill the complect of three > generals)) but at first i want to understand how to cheat ntpd as gpsd > regularly does. I think i did all i need. But it looks like i did > something wrong in that test. Ntpd eats my data but doesn't touch > system time. And i can't understand why If you need something to report a large offset to ntpd via SHM, you could try this program for testing leap seconds: https://github.com/mlichvar/leapshm With some small modifications, it should be able to report any offset you want. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin LVC 18x jitter problem
On 2019-08-17, Michael Haardt wrote: > Miroslav Lichvar writes: >> I think you do. To prevent the source from being rejected as a >> falseticker it needs to have a larger root distance. That could be from >> a larger dispersion or delay. You modified the refclock jitter, which >> ends up in the peer dispersion (after some weighting). Another approach >> would be to specify a minimum for the peer dispersion directly. There >> could be also an option to specify a minimum delay. But adjusting it in >> the refclock specific code, as you did, makes perfect sense to me. > > Which of the alternatives do you prefer? I got one way working, but I > am willing to test any other in case you have a patch or could at least > tell me where to enforce the minimum in the code to create a patch. >From the three approaches I'd probably prefer yours, i.e. keep it as a refclock-specific option. But maybe see if there is a better name for the option. "minjitter" might be confusing, at least in my understanding of the NTP terminology. If you would like to try the other suggestions, I think they could be implemented in the clock_filter(), clock_select(), or root_distance() function. > In the end, it would be great to get the needed functionality into > ntpd. If you want to get it in the ntp code, you should open a bug in the ntp bugzilla, attach the patch, and see what the maintainers think. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin LVC 18x jitter problem
On 2019-08-14, Michael Haardt wrote: > keyid=0, ttl=0, offset=-21.688, delay=0.000, dispersion=199.450, > jitter=7.766, > filtdelay= 0.000.000.000.000.000.000.000.00, > filtoffset= -21.69 -24.50 -21.05 -20.86 -24.06 -31.32 -18.34 -39.11, > filtdisp=200.00 200.24 200.48 200.72 200.96 201.20 201.44 201.68 > > Indeed I used minjitter 0.2. > > I can't say that I understand the difference, though. Do I modify what > I should modify? I think you do. To prevent the source from being rejected as a falseticker it needs to have a larger root distance. That could be from a larger dispersion or delay. You modified the refclock jitter, which ends up in the peer dispersion (after some weighting). Another approach would be to specify a minimum for the peer dispersion directly. There could be also an option to specify a minimum delay. But adjusting it in the refclock specific code, as you did, makes perfect sense to me. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS via USB-to-serial adapter
On 2019-08-14, Per Hedeland wrote: > Anyway, back to the FreeBSD post, it seems there are actually two > questions: > > 1) Is the ~ 200 usec offset reported by ntpd really semi-constant (and >thus "easy to deal with")? My understanding is that the error in the measurement is moving in an interval at a speed which depends on a hidden frequency offset. ntpd uses a median from multiple samples for controlling the clock. If the frequency offset is large enough and the polling interval long enough, the median should be stable and close to the middle of the interval. If the error is moving only very slowly, the sawtooth pattern would be visible in the offset reported by ntpd. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS via USB-to-serial adapter
On 2019-08-11, Per Hedeland wrote: > https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html > > TL;DR^2 The author carried out a pretty sophisticated (IMHO) test with > two different USB-to-serial adapters feeding PPS to ntpd, and found an > offset of some 200 usec with 20-30 usec jitter. You can of course tell > ntpd to correct for the offset (once you know how large it is...), and > the jitter doesn't seem too bad to me, although it is of course higher > than for more "direct" connections. An offset of 200 microsecond is much larger than a typical error of NTP in a local network, so maybe that's why people don't like refclocks over USB. However, with a custom driver and firmware it's possible to reduce the offset and jitter to few microseconds. See this great post from Dan Drown: https://blog.dan.drown.org/pps-over-usb/ -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin LVC 18x jitter problem
On 2019-08-12, Michael Haardt wrote: > I would appreciate if we could focus on the major issues first, like > why the modified jitter is not shown by ntpq. I think the explanation is that you are modifying jitter of individual samples, but ntpq -p is showing jitter between offsets. Print all variables of the peer with ntpq -c "rv $ASSID" and look for "jitter" and "filtdisp". -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin 18x LVC - degraded precision ?
On Tue, Aug 06, 2019 at 08:37:44PM -0400, Brandon Applegate wrote: > I haven’t made any software or config changes. The GPS puck hasn’t been > moved. I’ve rebooted the server as well as power cycled the puck. I’m not > quite sure what else I can look at. > > Could it be my 18x is “dying a slow death” ? Has anyone ever seen this > behavior or have any advice ? Any changes in the environment that could cause faster changes in the temperature? Like a new powerful AC unit cycling on and off? A plot of the offset and frequency over time might give a hint on whether it's a larger jitter or the clock is less stable. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How often does ntpd refresh its DNS lookup?
On Sat, Aug 03, 2019 at 02:38:45PM -0500, Jason Rabel wrote: > > For server-entries in ntp.conf, how does ntpd (4.2.8p13) time refreshing > > of hostnames? > > As far as I know, for regular server entries once it's done the > initial lookup on startup, that's it... Yes, that's my understanding too. > I believe for pool entries it will do a lookup to grab new IPs if a > pool server goes silent. Maybe that's what you were referring to? If it's unreachable, or serving wrong time (falseticker). Not periodically as that might cause clock hopping and possibly overload the DNS servers. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] symmetricom tp1100 stratum and leap indicator behavior
On 2019-08-02, Andrew Harrison wrote: > I should also have clarified, I understand patience is required. I > was careful not to rush through these troubleshooting steps because I > know these changes take time. At this point, I'm right at the last > step where I mentioned I had again unplugged the GPS antenna. This > was three days ago and the Symmetricom with no GPS that is not > reporting a stratum level is still primary. That's odd. When a source becomes unsynchronized (stratum == 16 or leap == 3), the reachability should drop to 0 after 8 polls and ntpd should select another source, even if the source was specified with the "prefer" options. Can you please post a tcpdump output showing the server responses and output of "ntpq -c as -c rv &1" command? > remote refid st t when poll reach delay offset jitter >== > *172.99.99.100 .GPS.1 u 83 256 3772.9240.010 0.185 > -172.99.99.200 .GPS.1 u 31 256 3773.9780.165 2.811 > +10.99.99.100.GPSi. 1 u 12 256 3771.465 -0.125 0.110 > +10.99.99.20010.99.99.100 2 u 55 256 3772.238 -0.015 0.107 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Reference 'sntp' utility: how do you set the destination port number
On Mon, Jul 22, 2019 at 11:32:07AM +0200, Marco Marongiu wrote: > On 21/07/2019 01:26, stua...@longlandclan.id.au wrote: > > after no on-list replies > > Just to say that I *do* see on-list replies from "A C" and Harlan Stenn > himself, so not sure what you mean here... Those (and yours) didn't make it back to the newsgroup where the question was posted. The gateway seems to work only in the direction to the mailing list. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] authenticated packet using alternate digest algorithms
On Tue, Apr 30, 2019 at 04:08:47PM +, greg.d...@microchip.com wrote: > However, in operation things get weird. Md5 and sha1 are fine. Ripemd160 is > successful but I think that is just lucky because it has a 160bit digest that > ends up looking like a sha1 mac. However, I "think" because I don't have > support in openssl, sha224, 256, and 384 don't even try to send MAC frames, > just regular no auth. So they look like they work but they have no MAC. > Sha512 actually generates a 64 byte mac and stuffs all of it in the frame so > 68 bye HMAC (with key) but this gets parsed as an extension and fails. > > So what's up? Is this like somewhere in the middle of development? I > remember discussions about have an extension field to either negotiate or at > least identify digest algorithms but I don't think this is that. Latest ntp-4.2.8 versions should truncate digests longer than 160 bits (192-bit MAC). What version were you testing? I'm not sure in which one exactly this was introduced. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Mu whole Internet crashes when server is in the pool rotation
On 2019-04-27, jelisko...@gmail.com wrote: > NTP server is working properly, I wanted to join the official pool. My > score is 19.2 which is excellent, but my whole internet crashes ! > > Even if I choose the lowest speed it is same. If I make schedule for > deletion the server I presume is immediately remove from pool rotation > everything is back to normal. That sounds like your router/firewall is trying to track all the NTP clients and exceeding the maximum number of connections. Is connection tracking disabled for the NTP port? With iptables it can be configured like this: iptables -t raw -I PREROUTING -p udp -m udp --dport 123 -j CT --notrack iptables -t raw -I OUTPUT -p udp -m udp --sport 123 -j CT --notrack -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP packets with MACs longer than SHA1
On Tue, Mar 12, 2019 at 01:24:52PM -0400, Danny Mayer wrote: > On 3/12/19 4:22 AM, Miroslav Lichvar wrote: > > On 2019-03-11, Nelson Bolyard wrote: > >> NTPv3 supported MD5 and SHA1 Message Authentication Code (MACs) of > >> length 16 and 20 bytes respectively. RFC 5906 says that NTP V4 > >> supports any MAC, but offers no advice about how to send MACs that are > >> longer than 20 bytes, such as SHA256 MACs. > >> > >> Are longer MACs sent in their entirety? > >> Are they truncated to 20 bytes? or to 16 bytes? > > The digests are truncated to 20 bytes in order to follow RFC 7822. > > > Actually it says that they can be no longer than 24 unless otherwise > negotiated by client and server. See Section 7.5.1.3. In the > introduction it says it can be 20 or 24 bytes. Right. The MAC includes a 32-bit key ID, so the digest has to be shorter by 4 bytes, which is what the OP seemed to be interested in truncating (it may depend on the actual implementation). -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP packets with MACs longer than SHA1
On 2019-03-11, Nelson Bolyard wrote: > NTPv3 supported MD5 and SHA1 Message Authentication Code (MACs) of > length 16 and 20 bytes respectively. RFC 5906 says that NTP V4 > supports any MAC, but offers no advice about how to send MACs that are > longer than 20 bytes, such as SHA256 MACs. > > Are longer MACs sent in their entirety? > Are they truncated to 20 bytes? or to 16 bytes? The digests are truncated to 20 bytes in order to follow RFC 7822. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting ntp broadcast packets
On Wed, Feb 27, 2019 at 08:39:45AM -0900, John Thurston wrote: > And since I'm on a switched ethernet LAN, my network port is only going to > see traffic destined for my own MAC (or broadcast) anyway. So I really can't > see any benefit to enabling promiscuous mode. What am I missing? Nothing. I was aiming for simplicity. For lowest CPU usage the other approach with an NTP broadcast client configured to log packets might be better as it would avoid the BPF filter. > Wouldn't this work just as well? > > tcpdump -U -p -n -s 128 'broadcast and port 123 and udp[8] & 7 == 5' Yes, assuming nothing is using multicast messaging or switches are snooping and your machine didn't join the group. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting ntp broadcast packets
On Tue, Feb 26, 2019 at 09:58:06AM -0900, John Thurston wrote: > B) use snoop or tcpdump to look at broadcast packets and tell me if it > uncovers any ntp > > Is there already a better way to watch and warn of such packets? An easier way would be to use tcpdump to print all NTP packets (not just those sent to a broadcast address) that have the mode field equal to 5 (broadcast). tcpdump -n -i eth0 'port 123 and udp[8] & 7 == 5' If it doesn't print anything, nothing in the network is using the NTP broadcast mode. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Legitimate Source Ports for NTP traffic?
On Tue, Nov 20, 2018 at 11:19:24AM -0600, Jason Rabel wrote: > In response to my own question I looked a little deeper into the odd > traffic using tcpdump. Best I can tell they are indeed properly > formatted NTP requests, the curious bit is seeing most of these > requests having a precision of -6 or -7. While I know some older MS OS > set their internal time update to around that, they also use the > microsoft time servers by default. Precision of -6 seems to be common. It's used by ntpdate for example. Not sure about -7. I suspect the number one reason for getting requests from privileged ports different than 123 is NAT. If there are two NTP clients behind NAT using port 123, one of them will have to get a different port. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Conflicting information on packet field types
On Tue, Oct 30, 2018 at 10:31:58PM -0500, Jason Rabel wrote: > However, RFC 4330 goes a little more in-depth saying, "This is a > 32-bit signed fixed-point number indicating the total roundtrip delay > to the primary reference source, in seconds with the fraction point > between bits 15 and 16. Note that this variable can take on both > positive and negative values, depending on the relative time and > frequency offsets. Interesting. RFC 1305 has signed root delay and dispersion too. I never noticed that. I thought the only differences in the format of NTPv3 and NTPv4 packets was the IPv6 reference ID and extension fields. > I know this is all a bunch of 'what if' scenarios that probably will > never happen... Especially with the packet NTP sends out apparently is > unsigned for root delay. But again my thoughts are about other time > programs out there. I'm going to take a wild guess and say that (under > normal circumstances) if NTP (or any time program) is calculating a > negative delay (and likely a huge time offset), it's probably also > considering itself unsynced and won't send out time to any clients > that request it until things normalize. The two NTP implementations I'm most familiar with both work with an absolute value of the delay. So, even if the frequency error is so large that the measured delay is negative, the root delay should accumulate a positive value. A potential issue is with values in the 32768-65536 range, which could be used by a server that lost synchronization long time ago and old clients following RFC 1305/4330 would misinterpret it as a negative value. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Conflicting information on packet field types
On Fri, Oct 19, 2018 at 05:11:48PM -0500, Jason Rabel wrote: > I'm writing my own little query script to decode NTP packets and I've come > across some conflicting information in the RFCs and other white papers that > I'm hoping an authoritative source would know the answer to. > Specifically for the 'Poll Interval' and 'Root Dispersion' fields in the > NTP packet, some documents say they are unsigned variables, others say they > are signed... The RFC 5905 (NTPv4) should be the authoritative source here. For the poll field it has: 8-bit signed integer representing the maximum interval between successive messages, in log2 seconds. For the root dispersion there is: The 32-bit short format is used in delay and dispersion header fields where the full resolution and range of the other formats are not justified. It includes a 16-bit unsigned seconds field and a 16-bit fraction field. So, poll is signed and root dispersion is unsigned. Which documents have conflicting information? I think ntpd internally uses an "unsigned" poll variable, but I'm not sure if it really is an issue as it doesn't support sub-second polling intervals. In tcpdump there was a bug that it printed the poll field as unsigned. That was fixed some time ago. > I can't think of a reason for Root Dispersion to be negative... 0 would be > the best and I think max is clamped to 16? The maximum is ~65536 seconds. Large values may be used by servers that have lost their time source. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS not working on newer kernel/distros
On Mon, Oct 15, 2018 at 07:31:02AM -0400, Brandon Applegate wrote: > > On Oct 15, 2018, at 1:51 AM, Vitezslav Samel wrote: > > > > ntpq -c kerninfo > > Hmm, thanks for the tip. I guess even though I have flag3 set to 1 I’m > 'falling back' to userland PPS ? It's not a userland PPS. The PPS timestamps are still from the kernel. The difference is in the clock discipline. Instead of kernel using the PPS samples directly to control the clock, they are processed by ntpd and fed back to the kernel PLL/FLL loop at the normal update interval. > root@ice:~# ntpq -c kerninfo | grep ^kernel > kernel status: pll nano > > So would this be a kernel issue causing this ? The kernel PPS discipline is not supported in the NOHZ "tickless" configuration, which I think is enabled in all major Linux distributions. AFAIK the only thing that has changed in the last few years is how ntpd handles the error when the PPS discipline cannot be enabled. It used to be ignored. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Support SHA2 or not
On Sat, Oct 13, 2018 at 10:19:44PM -0400, Danny Mayer wrote: > Sorry for the delay in responding. No, it doesn't work right now. I did > test this out several years ago but the problem with SHA2 is the length > of the resultant hash. There's no problem creating and sending such a > MAC but the other side needs to be changed to be able to properly handle > the resulting MAC. There are plans to change the code to properly deal > with this and other types of hashing algorithms. I think that may already have been implemented. Recent ntp versions seem to truncate long MACs to 160 bits, so it should work with any hash function supported by openssl. However, ntp-4.2.6p5-28.el7 from RHEL/CentOS doesn't support it. > > Danny > > On 10/8/18 2:29 AM, Sharma12, Sachin wrote: > > Hi, > > > > We are using ntp-4.2.6p5-28.el7, Please let us know whether the NTP support > > SHA2 with FIPS enable and disable? > > > > If not then please let us know when NTP support for SHA2 in future release? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] xntpd and Timekeeper
On 2018-09-03, Peter wrote: > When NTP version 4 is stopped and start NTP version 3 the figures look > like (after running for ~1hr): You may need to wait longer for things to settle down. > # ntpq -p > remote refid st t when poll reach delay offsetdisp >== > +host1 .PTP.1 u 27 64 377 0.99 -90.2992.09 > +host2 .PTP.1 u 14 64 377 0.11 -90.6421.79 > -host3 .PTP.1 u 11 64 377 1.34 -90.7172.01 > *host4 .PTP.1 u 49 64 337 0.09 -89.8251.75 > > With this host, the binary for ntpq is the same for xntp as for > ntp…(ie the same binary is being used to produce both results above) > Similar symptoms are noted for AIX and Solaris. Does this happen also when you reset the kernel frequency with "ntptime -f 0" before starting xntpd, or remove the drift file? I think it could be due to a difference in how ntpd and xntpd are controlling the clock. If xntpd didn't use the kernel discipline, it would need to correct for the kernel frequency offset that was set by ntpd. If that doesn't help, please enable the loopstats log and post it here after xntpd has been running for at least a day. I doubt this is an issue with the server. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] xntpd and Timekeeper
On 2018-08-27, Peter wrote: > Having recently deployed some new appliances running FSMlabs > Timekeeper software as NTP servers, I have noticed an apparent > incompatibility from older Solaris hosts running xntpd. All hosts > running NTP version 4 are synchronising correctly. Older AIX and > Solaris hosts running NTP version 3 (xntpd) are experiencing > excessively large offsets when compared to using NTP version 4. Can you show some examples? If you use ntpd on the server, the xntpd clients work ok? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] understanding assocID and ntpq>readvar
On 2018-07-24, valizadeh...@gmail.com wrote: > My questions: > 1-how assocIDs are assinged to ntp peers? They are assigned randomly and they cannot be predicted AFAIK. > 2- is there any way to use Peers IP address instead? to use in "ntpq readvar" Not addresses, but indexes. E.g. ntpq -c as -c 'rv &1' to get the variables of the first association. > 3- why ((ntpq -c "rv 23023 status")) don't work? I guess it's because associd and status are not variables returned as data in mode 6 packets, but they have their own special fields in the packets. I'm not sure if it's possible to get them from ntpq separately from the real variables. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] More than one PPS source on Raspberry Pi?
On Mon, Dec 04, 2017 at 04:25:26PM -0500, Brian Utterback wrote: > Doesn't adding a second PPS signal mean that the accuracy can only go down? > If the two PPS signals are really in sync then they will be clocking > essentially simultaneously. They won't get serviced simultaneously so one > will either be ignored or will be serviced after a delay. I think some GPS units can be configured to shift the PPS edge by a specified offset to avoid two PPS signals triggering an interrupt at the same time. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How to get shared memory access from gpsd to ntpd to work?
On Wed, Aug 16, 2017 at 01:52:44PM +0100, Etaoin Shrdlu wrote: > Hi all, > > I've been battling for some time with getting ntpd to set the date/time > from gpsd's shared memory locations. My GPS device is on the network > and sends GPS messages every minute over UDP. This is picked up by gpsd > and it appears I get a good fix with all the required data. It also > looks as if the shared memory locations are being set up correctly. But > whatever I do, ntpd time source "reach" stubbornly remains at zero, > even when running ntpd as root. I would be most grateful if someone > could cast their eyes on the configurations and log output below, and > let me know if you can see were it's going wrong! There is a ntpshmmon program included with gpsd, which should show you if gpsd is actually writing to the SHM segments and whether it's a problem on the gpsd or ntpd side. However, I'm not sure if this is supposed to work with GPS over network. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trouble with ntpd and gpsd
On 2017-07-03, Thomas Schweikle <tschwei...@gmail.com> wrote: > # Other options you want to pass to gpsd > GPSD_OPTIONS="" > Starting ntpd I'd awaited gpsd to be available, but "reach" keeps "0": > SHM(0) .GPS.0 l- 1600.000 > 0.000 0.000 > SHM(1) .UPPS. 0 l- 160 > 0.0000.000 0.000 > > > I've looked after rights on /dev/ttyACM0 and added ntp to dialout, but > this shall not be neccessary, since ntpd uses 127.127.28.0 to access > port 2947 with its nmea-driver. I just didn't find anything helpful > with google for my case. Anybody out there having an idea how to get > the whole thing working? BTW: iptables are not active. SeLinux or > apparmor are off too. Have you seen the gpsd time service howto? http://catb.org/gpsd/gpsd-time-service-howto.html You might need to add -n to GPSD_OPTIONS. From your ipcs output it seems both gpsd and ntpd are attached to the same SHM segments, so that should not be a problem. It's either gpsd not writing anything there, or ntpd rejecting the samples it gets. It would help to see output from the ntpshmmon command. If you don't see any samples, try running gpsd from command line with -D 9. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS-PPS, standalone server. NTP
On Tue, Jun 20, 2017 at 06:13:14AM -0700, Fida Hasan wrote: > From this point onward, if I set up ntp, it get fix with the drivers and > working fine. However, according to the instruction here: > http://catb.org/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd > > 3. I installed chrony and gpsd into my system. And always ensured that Chrony > is Running before gpsd. > > > allow 0/0 > > refclock SHM 1 refid GPS precision 1e-1 offset 0. delay 0.2 > refclock SOCK /tmp/chrony.ttyS0.sock refid PPSS > > But I don't get any result. It is sure that chrony does not get feed from > GPSD. With the pps-gpio module gpsd doesn't know that /dev/pps0 is related to /dev/ttyS0. You might need to start gpsd with both devices specified on the command line. I'm not sure since what version that is supported. If that doesn't work and chrony was compiled with PPS support, you could use gpsd just for the message-based samples provided in SHM 0 and use the PPS device directly. For example: refclock PPS /dev/pps0 poll 2 lock NMEA refid GPS refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ***SPAM*** How to sync my system clock when there is high offset
On Fri, Jun 09, 2017 at 04:28:07PM +0200, Mike Cook wrote: > > Le 9 juin 2017 à 12:52, Ashish Kurian <ashish...@gmail.com> a écrit : > > In my ntpq -p output, I see that the offset is around 70 milli second. How > > can I force my system clock to sync with the NTP server time. If I wait for > > a day, I know that the value will come down, but how can i get it synced > > without such long wait? > > Again, and I would say « as usual » , not enough info in the question to > make a reasonable guess. A bit like answering the question « how long is a > piece of sting? ». > That said, if you detected that just after starting ntpd, it probably means > the you need the « -g » option on startup. You mean the -G option which was added in recent ntp versions? The -g option just temporarily disables the panic threshold and should't make a difference (unless the initial offset is larger than 1000 seconds). With older ntp versions it's recommended to run ntpdate -b before starting ntpd in order to speed up the initial synchronization. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server sync
On Fri, Jun 02, 2017 at 10:32:38AM +0200, Ashish Kurian wrote: > I have setup ntp servers on Ubuntu virtual machines. The configuration > files are exactly the same on both the machines. I am attaching the conf > file along with this email for you to have a look into it. > Why is it that on old Linux kernel only the LOCL server is shown and on the > newer Linux kernel both the LOCL and POOL are shown? Does it mean that the > two VMs are synced differently? Do they use the same ntp version? I think only ntpq from newer (4.2.8) versions can display the POOL line. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trying to make NTP daemon as one of the Sync source
On Tue, May 30, 2017 at 04:21:14PM +0530, akash saxena wrote: > *Hi all, * > *I am trying to implement a system where NTP daemon will be a Sync source > like others (GNSS/PTP/NL). * > *These all sync sources (GNSS/PTP/NL) provide a CLOCK REPORT based on their > accuracy. * > *Which consist * > >- *TimeError, * >- *FrequencyError, * >- *Time Uncertainty and * >- *Frequency Uncertainty.* > > *Can i get these four parameters in ntpq -pcrl output so that i can > implement NTPD as a sync source. presently i am getting the ntpq -pcrl > output like below.* It would help if we knew what exactly are those four values supposed to represent. One way to map the values from ntpq would be: offset -> TimeError clk_jitter -> Time Uncertainty clk_wander -> Frequency Uncertainty ntpd does't estimate the current frequency error of the clock. You might want to set FrequencyError to 0 or "undefined". -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] trying to get broadcast to work
On Mon, May 29, 2017 at 09:43:08PM +0200, folkert wrote: > Hi, > > I'm trying to get broadcasts to work. > client 192.168.64.150 > - > driftfile /var/lib/ntp/ntp.drift > > restrict -4 default kod notrap nomodify nopeer > restrict -6 default kod notrap nomodify nopeer > > restrict 127.0.0.1 > restrict ::1 > > disable auth > broadcastclient > So I wonder: what am I doing wrong? what could be the cause? I think you need to remove the nopeer restriction on the client, or enable authentication (server and client sharing a symmetric key). -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: > Thanks. I agree that the appliance doesn’t appear to exist. It’s a shame that > it doesn’t, I think it would be a good idea. > > The 50 msec isn’t that hard to reach on an average basis, but we routinely > see drifts away from that on occasions. The minpoll idea would probably fix > this, but was hesitant to poll that frequently. I just found NIST’s NTP page > and they specify to not poll more frequently that every 4 seconds (minpoll > 2). I wouldn’t have thought that they would want polling with minpoll 3, but > it appears I was wrong. This may fix the issue by itself. Using such a short polling interval over Internet would be a horrible idea. NIST servers are overloaded and located in a network that has problems with asymmetric routing. It's better to avoid them if accuracy is a requirement. I thought you were using those stratum-1 servers you have and the requirement for accuracy was 10 or 100 microseconds, not milliseconds. Anything should do better than 50 milliseconds as long as it's on local network. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Fri, May 26, 2017 at 09:35:14AM +, Matthew Huff wrote: > The OXCO oscillator requirement is for hold-over, but we are looking for less > jitter in the system. We could strip down the OS machines and run only NTP > and make other system adjustments that would accomplish much of the same, but > to dedicated a server just for NTP when an appliance is available seems a > waste. If the stratum-1 servers have stable clocks for hold-over, will OXCO on stratum-2 server make much of a difference? Also, why not point the clients directly to the stratum-1 servers? > FINRA has made new timing requirements that are pushing this. Switching to > PTP is ultimately the solution, but the switches in our core data center > don't support it, and would be very costly to migrate to. You might want to consider using NTP with HW timestamping if you have servers with NICs that support it. In my experience that usually reduces the jitter down to a sub-microsecond level. Unless the network is heavily loaded for longer periods of time, it should not be necessary to use PTP and expensive switches. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Thu, May 25, 2017 at 11:31:27AM +, Matthew Huff wrote: > For the last 20 years I've run our stratum 2 ntp servers under Solaris then > Linux. I'm looking to replace them with an appliance for a number of reasons. > One of the main one is clock stability. We have 2 microsemi GPS synced > stratum 1 servers with rubidium oscillators. I am not looking for a > linux/bsd/unix box running NTP, but a dedicated non-os appliance. I don't know if such an appliance exists (all I saw that had a real NTP client ran a regular OS), but I'm curious what problems is the (in)stability of an ordinary computer oscillator causing. Are the servers supposed to be able to hold over long periods of time in case the stratum-1 servers fail? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP under AIX?
On Thu, May 18, 2017 at 03:32:42PM -0400, Paul wrote: > On Thu, May 18, 2017 at 3:06 PM, Brian Inglis < > brian.ing...@systematicsw.ab.ca> wrote: > > A lot of these types of boxes appear to be some type of SoC board with > > some GPS module, some Linux distro, some NTP release, probably GPSd, > > and with little in the way of docs, specs (typical: <1us!), guarantees, > > or likely support and maintenance. They often feature pictures of fancy > > I assume here you are referring to classic NTP appliances from folks like > Spectracom, MicroSemi or EndRun (if they still exist). I would expect the > LeoNTP to be more like Tharp's Laureline (V2) ( > https://partiallystapled.com/pages/laureline-gps-ntp-server.html) and not > actually run anything one would recognize as NTP -- except for network > packets. I think of these things as being network attached GNSS modules > that use NTP compatible packets for time transfer. Yes, it doesn't look like the LeoNTP runs a regular OS. From what I hear it actually delivers what they promise. One issue I've heard which may affect accuracy is that it doesn't support 1gbit ethernet and the difference in link speed may create an asymmetric delay in the network switch. Does anyone sell an NTP appliance with sub-microsecond accuracy and 1gbit ethernet? As modern NICs support hardware timestamping, it's possible to synchronize computers to few tens or hundreds of nanoseconds, but the choice of NTP servers with such accuracy is very limited. For people who don't want to spend money on new switches with PTP support, it may be better to buy a PTP grandmaster and connect it directly to a machine with two NICs, which would be a PTP slave and an NTP server for other machines in the network. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] dynamic stratum changes
On Tue, May 09, 2017 at 02:56:46PM +, Szuch, Paul wrote: > Hi, I'm setting up ntp on an isolated net. > Some of our linux machines run a custom time protocol that synchronizes the > kernel to GPS time to sub millisecond accuracy. > I've got my ntpd.conf using the local oscillator (127.127.1.1) clock at > stratum 1. > > I'm looking to see what I should do when my custom time protocol has an error > and can't synchronize time anymore. > I would like to degrade my stratum so that other machines will choose a > better source of time, depending on how bad my custom protocol fails. Degrading the stratum is not enough for NTP clients to ignore that source. It could still break their selection. It should change its leap status to unsynchronized (or change stratum to 0), or increase its root dispersion as NTPv4 servers normally do when they lose their synchronization. > I'd rather not kill and restart ntpd, as that just puts load on the machine > for no good reason, and seems very inelegant. > I looked into ntpdc "fudge" command, but it doesn't support the stratum > option. > Is there some elegant way of making the local ntpd change its reported > stratum? > > Do I have to customize the local oscillator driver to input the health status? I think a good approach would be to modify your driver to work as a SHM reference clock and let ntpd synchronize the system clock. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP server - Number of received petitions.
On Tue, Mar 21, 2017 at 12:30:01PM +, Raúl wrote: > So, using "ntpdc -c iostats", the numbers under the labels "received > packets" and "packets sent" are the total number of requests > received/served since the last server reboot? Yes, except the numbers include all received and transmitted NTP packets, not just clients' requests and responses. That is, it will include also ntpd's own requests and responses from its servers, and also ntpdc/ntpq requests and responses, even from localhost. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP server - Number of received petitions.
On Tue, Mar 21, 2017 at 12:01:21PM +, Raúl wrote:
> But I don't need anything special, I'm just looking how to know the load of
> my NTP server, how many request I'm receiving from clients. I thought that
> doing that would be easy.
If you just need current rate of requests and don't care about
individual clients, you could periodically call ntpdc -c iostats and
calculate the rate from the total number of received packets using awk
for instance:
while true; do ntpdc -c iostats; sleep 1; done | \
awk '/received packets/{ print $3 - last; last=$3}'
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
On Fri, Mar 10, 2017 at 02:34:51AM -0500, Majdi S. Abbas wrote: > On Thu, Mar 09, 2017 at 05:24:35PM +0100, Miroslav Lichvar wrote: > > Couldn't the malicious client create a larger number of ephemeral > > associations, using multiple IP addresses, in order to outvote good > > servers? > > If it has a bunch of IP addresses, maybe... but you'd have to > be close enough to the existing clock to capture the peer.. (read: > close/low latency and jitter path, and serve better time than the > configured servers for a while). I'm not sure if distance and jitter really matter here. The source selection algorithm discards falsetickers before distance/jitter are involved in the clustering and combining. I was able to reproduce the issue with ntp-4.2.8p9. The server was configured with three good stratum-1 server. Four clients that had a valid key were off by 10 minutes. They created symmetric associations with the server and were able to outvote the good servers, even though their distance and jitter was much larger. remote refid st t when poll reach delay offset jitter == xgood-server1.GPS.1 u 21 64 3770.244 -60 0.096 xgood-server2.GPS.1 u 24 64 3770.241 -60 0.112 xgood-server3.GPS.1 u 56 64 3770.233 -60 0.066 +bad-client1 LOCAL(1) 3 S 22 64 377 31.424 -0.752 2.211 +bad-client2 LOCAL(1) 3 S 17 64 377 36.3100.015 1.741 +bad-client3 LOCAL(1) 3 S 27 64 377 34.9190.462 2.441 *bad-client4 LOCAL(1) 3 S 38 64 377 31.443 -0.491 1.401 > ...and that assumes you aren't using prefer on your chosen servers. You mean the true option? The prefer option doesn't seem to have an effect on falsetickers. Another way to avoid this problem might be allowing authentication of server packets with keys that are not marked as trusted with the trustedkey directive. If clients used untrusted keys for authentication of the server, they wouldn't be able to create symmetric associations. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
On Thu, Mar 09, 2017 at 10:56:22AM -0500, Majdi S. Abbas wrote: > On Thu, Mar 09, 2017 at 03:16:57PM +, Moser, Stefan wrote: > > Now assume that one of the remote NTP clients turns bad, deliberately > > configures forged > > time, and enters "peer " in its ntp.conf. This > > (correct me > > if I'm wrong) creates a dynamic mobilization with my local NTP server, and > > my local > > NTP server will eventually believe in the client's (now it's a peering > > server) time. > The peer, even if authenticated and malacious, needs to pass all > the filtering and selection algorithms any source of time does. > Authentication authenticates the peer and the the timestamps -- it does > not assure quality of the time provided, and ntpd does not make that > assumption. Couldn't the malicious client create a larger number of ephemeral associations, using multiple IP addresses, in order to outvote good servers? To me it seems the only defense against this is the new extended keyfile format which can restrict keys to specific IP addresses. If each client had its own key and the key was restricted to one address, the client could create just one ephemeral symmetric association. Of course, if multiple clients coordinated in this attack, it would be still be a problem. The documentation clearly says the nopeer option applies only to unauthenticated packets, but it's not very clear to me what was the reason for that. Do you think it would make sense to modify its behavior to apply to both authenticated and unauthenticated packets? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How common is LI=3 (clocks not synchronized)?
On 2017-02-03, Jakob Bohm <jb-use...@wisemo.com> wrote: > On 03/02/2017 04:15, Robert Scott wrote: >> When the two LI bits come back as 11 (clocks not synchronized) I have >> been treating that as a fatal error for that server. I ignore that >> packet and do not attempt to retry my query for that server. However >> I have found that LI=11 is not all that uncommon for servers from the >> pool. Is my response to LI=11 the correct one? Should I discard the >> response and should I write off that server for retries? So far, the >> only reason I might retry a server is if my recvfrom() socket call >> times out. >> > > I suspect this is the expected response from a time server which has > recently booted and has not yet synchronized itself, probably combined > with stratum=15 or more. But I haven't double checked this against > code or RFCs. Another reason for the "unsynchronized" leap bits might be a recent step of the system clock. If the clock is unstable, ntpd may need to step the clock often (after reaching the threshold of 128ms). I think I've seen some servers in the pool that behaved like that. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time syncing with something other than ntpd
On 2017-02-02, sean <s...@sean.eternal-september.org> wrote: > I don't know if I'll be able to join the pool because I don't > have a static IP. Although, if I register with a DNS name, couldn't I > just update the A record if/when it changes? > something like time.example.com. That won't work. The pool works with IP addresses and they are not supposed to change. I'm in a similar situation. I have at home a nice low-power stratum-1 server using a u-blox neo-6m GPS with good network connection, but I can't add it to the pool, because its address may change without notice (although it rarely does). So I have a VPS that is synchronised to it and its time is served indirectly. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time syncing with something other than ntpd
On 2017-02-01, sean <s...@sean.eternal-september.org> wrote: > On 2017-01-30, William Unruh <un...@invalid.ca> wrote: >> You do not say which OS you use. Windows (which version?), Mac, linux, >> BSD? > > Primarily FreeBSD and OpenBSD, but also Linux. Knowning that, what's > that mean in terms of a ntp client? IIRC openntpd runs on all these systems, but reference clocks are supported only on OpenBSD. chrony supports FreeBSD and Linux (both with refclocks), but not OpenBSD. ntpd supports everything. >> chrony does not work on windows. ntpd is what what tends to ship with >> linux distros. chrony gives better time discipline but has a smaller >> user group. > > Well if I use Chrony with a GPS unit on something like a raspberry pi, > would I be able to be apart of the NTP pool or is it limited to NTPD > users only? Yes, you can do that. The pool project page recommends ntpd, but it's not a requirement. There are quite a few openntpd and chrony servers in the pool, including a couple of my own. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time syncing with something other than ntpd
On 2017-01-30, David Taylor <david-tay...@blueyonder.co.uk.invalid> wrote: > I have been running NTP on multiple systems since 2002, including Linux > and Windows (2000 and later), both with hardware sync (GPS18, GPS18x and > multiple GPS devices for the Raspberry Pi), and with LAN and Wi-Fi > network sources. I find NTP easy to manage and monitor over multiple > systems, and the fact that it runs on Windows, and can accept GPS > devices on Windows very valuable. You can easily get within 10 > microseconds in Linux (but be careful of the temperature and GPS antenna > location), and within 200 microseconds on Windows when using an attached > GPS/PPS device. Speaking of Windows, does anyone know how well (if at all) work the NTP implementations in the Windows Subsystem for Linux (WSL) that's now available in Windows 10? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] restrict source available from which version?
On Sat, Dec 31, 2016 at 01:09:46AM -0700, Brian Inglis wrote: > On 2016-12-30 16:32, Ask Bjørn Hansen wrote: > >>> restrict 127.0.0.1 > >>> restrict -6 ::1 > >>> > >>> pool 0.pool.ntp.org > > Add preempt to pool statements to drop unselected servers and > acquire new servers to maintain a majority clique - see below. Does the preempt option actually do anything in the pool directive? I thought servers added from pool are always "preemptable". > >> How many servers should the client use at the same time? The > >> default value of tos maxclock is 10, so it would use 10 servers. > >> That seems a bit excessive. If it should be equivalent to the > >> current recommendation, the config would need to include > >> > >>tos maxclock 4 > > Keep it odd - tos maxclock 5 - for sync, majority clique requires > truechimers *>* falsetickers - truechimers == falsetickers is > *unsynced* - 5 allows 2 servers "off" in some way at the same time > (e.g. during weekend maintenance windows when servers often drop > out - YMMV) see http://doc.ntp.org/current-stable/select.html . Is it common to get two falsetickers at the same time? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] restrict source available from which version?
On Fri, Dec 30, 2016 at 03:32:51PM -0800, Ask Bjørn Hansen wrote: > On Tuesday, September 6, 2016 at 1:41:10 AM UTC-7, Miroslav Lichvar wrote: > > On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote: > > > restrict default kod nomodify notrap nopeer noquery > > > restrict -6 default kod nomodify notrap nopeer noquery > > > > I think this line shouldn't be necessary as restrict default specified > > without -4 and -6 should apply to both. > > Ok, thank you. Is that the case for older versions of ntpd, too? There's > obviously a bit of cargo cult going on here, I appreciate the help getting to > an actual best practices recommendation. :-/ I think the last version that needed that -6 line was 4.2.4. > For Martin's comment about kod and limited: > > I'm not sure if 'limited' works on a reasonably busy NTP server (hundreds to > a few thousand queries a second) and I don't think anyone has shown that KoD > packets does something useful for a meaningful number of the "bad clients", > so I should probably just take 'kod' out. Makes sense to me. > > How many servers should the client use at the same time? The default > > value of tos maxclock is 10, so it would use 10 servers. That seems a > > bit excessive. If it should be equivalent to the current recommendation, > > the config would need to include > > > > tos maxclock 4 > > How does that work if the client is dual-stack? I'd like to avoid the client > (sometimes) just getting IPv6 if it's dual-stack. That probably won't work. If the client selects only IPv6 addresses from all addresses the name has resolved too, I think it will replace them with IPv4 addresses only when they are unreachable. > > Would it make sense to use 2.pool.ntp.org in the config instead of > > 0.pool.ntp.org in order to get IPv6 addresses? > > My plan is to make the "bare" name have IPv6 soon. I've also been planning to > change it to have explicit "I'm an SNTP client" vs "I'm an NTP client" names > though. The difference being that SNTP clients resolve the name before each NTP query? I'm not sure if all SNTP clients do that. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Use ntp orphan mode to sync time two stand-alone computers
On Sat, Aug 13, 2016 at 09:28:52PM -0400, Jason Beach wrote: > I have two arm-based Linux (ubuntu 14.04) computers, a Jetson TK1 and TX1 > that will fly on a multicopter and hence have no internet connection (they > are networked together onboard). They also do not have RTC's built-in but > I have added a smll external one (https://www.adafruit.com/product/255) to > the Jetston TK1. The TK1's time gets set on boot from this RTC no problem > (using a `sudo hwclock -s -f /dev/rtc0` in rc.local). I am trying to get > the TX1 to sync to the TK1's time using ntp. If you need to sync one machine to another, you should use the LOCAL driver (127.127.1.0) and not the orphan mode. Orphan mode is for cases where a server should be automatically selected from a group of unsynchronised servers. In your case only machine can be a server (the one with RTC). -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] reference clock, shm and ntpd
On Thu, May 26, 2016 at 08:15:26PM -0700, Stuart Maclean wrote: > Thanks for the info Dan, I have to concede I don't even know what the > 'frequency' is or what it means, much less know why the value is 500. How > might I reduce that value? I am fairly sure my reference clock is good, and > that my Linux system clock ticks slow compared to the ref clock. You could try increasing (or decreasing?) ADJ_TICK by 5 and see if that helps. It should move the ntpd's frequency range by 500 ppm. I doubt it will help, however. I think stable ofset and frequency pushed to the limit indicates something is very wrong and it's not just local clock being too fast or slow. To me it looks like either the kernel is broken or the reference time is actually based on the local system time. Or maybe something else is messing with the clock, overwriting the ntpd's adjustments. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] issue with the hmac-md5 digest
On Fri, Apr 01, 2016 at 07:37:15AM +, Sukanya K. wrote: > But when I sending ntp packet with symmetric key, client is not synchronizing. > > The hmac md5 digest which is generated by the client is not matching with the > calculated digest from server side. > > I have evaluated my hmac-md5 code by giving the all test cases(rfc2202) as > per the rfc. And all the digest were matched. > > But it is not matching with the clients ntp packet message digest. NTP doesn't use HMAC. The NTP MAC uses hash calculated over the symmetric key concatenated with the NTP packet. See 7.3 in RFC 5905. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntpwg] Idea to improve ntpd accuracy
On Fri, Feb 26, 2016 at 02:21:47PM +0100, Martin Burnicki wrote: > Tal Mizrahi wrote: > > Sounds a bit like interleave mode, right (a bit similar to PTP two-step > > clocks)? > > But the problem is still that (again, AFAIK) NTP interleave mode works > only in broadcast mode. It works also in the symmetric mode. > In broadcast mode ntpd only tries to measure the packet delay when the > association is first created, but the network route etc. can change at > any time, so IMO interleave mode provides only limited benefit. It probably wouldn't be difficult to modify ntpd to run the delay measurement periodically. A bigger problem is that the delay is measured using the client/server mode packets, for which there is no interleaved mode. If the delay is inaccurate, the offset is inaccurate too, even if the tx timestamp in the broadcast packet was accurate. Broadcast clients would need to create ephemeral symmetric associations with the server in order to measure the delay accurately. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Idea to improve ntpd accuracy
On Thu, Feb 25, 2016 at 01:52:03PM -0800, Weber wrote: > The NIC generates an interrupt after the packet is sent which can result in > a fairly accurate trailing hardstamp. The problem is...the packet is already > gone and has the wrong transmit timestamp. ntpd actually supports an "interleave" mode that was designed for this. It allows exchange of timestamps that were captured after the packet was sent. But it can work only in the symmetric (peers) and broadcast mode. For the ordinary client/server mode there is nothing like that. > What if the poll response packet contained a flag or indication of some sort > which means "this is an approximate transmit timestamp". That packet would > then be immediately followed by a second response packet with a more > accurate transmit time. The second packet could be otherwise identical to > the first, or it could be a new flavor of packet that contained only the > transmit time (that would save on network bandwidth). This could work, but there would be a problem with traffic amplification. For one request packet there would be two packets in reply. In PTP, which was designed for local networks, it doesn't really matter, but if it should work over internet, this would need to be addressed. One option would be to require a large extension field in the request. The server would still send twice as many packets, but at least the amount of traffic would be similar in both directions. A better solution might be saving the follow-up timestamps on the server in some buffer and the client would ask for it with a separate request. Another approach to get accurate tx timestamps is to implement a "one-step" NTP server using the launch time feature that's present on some NICs. Instead of capturing the timestamp after the packet is sent, the time of the transmission can be set in advance and there is no need for a follow-up. If there was an extension field to account for delays in the processing of the packet on the network path between the client and server, and it was supported in switches/routers similarly to PTP, sub-microsecond accuracy would be possible. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd sensitivity to ordering of servers in ntp.conf?
On Thu, Feb 25, 2016 at 02:49:48AM -0800, Weber wrote: > ntp.conf is specifies both servers with minpoll 4/maxpoll 4. Peer and loop > statistics are enabled. > By just changing the order of servers in ntp.conf the delay and offset > values in peerstats are swapped. Now it is A with 60us delay and B has 85us. > Similarly, A's offset is not -5us and B is showing +5us. > > It appears there is something in ntpd where measurements on server A in > ntp.conf come out slightly different depending its ordering in ntp.conf. When A is specified as first in the config, the interval between polling of A and B will be 1 second and the interval between B and A will be 15 seconds. When you swap the servers, the intervals will be swapped too. I think there could be a lot of things than would happen in 15 seconds, but not in 1 second. Maybe some power saving feature is activated or maybe some cache entry expires. You could try adding B manually via ntpq -c config:, timing the command so that the polling is exactly between two polls of B, and see what happens with the delays. Or you could run ping against the servers to keep the link "up". The direction in which the offset changed suggests it's the processing of the server packet that has the extra delay. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] kod and limited
On Fri, Nov 20, 2015 at 04:40:24PM +0100, Marco Marongiu wrote: > Now I have two options: > 1. remove "kod" altogether > 2. add "limited" > > The defaults for discard seem sensible[3] and adding "limited" shouldn't > result in problems. On the other hand, I am worried that (for example) > local clients using burst/iburst or running ntpdate -q repeatedly for > debugging purposes may be denied the service. Am I just worrying too much? > > What option would you recommend? I think the recommendation is to not use the limited option at all. Some people reported that it may actually increase the amount of traffic, apparently there are broken clients that send a new request soon after missing a reply. Also, there is a security issue that an attacker can prevent a client from getting replies by sending spoofed packets to the server. See the archive of the ntp-hackers list for more information. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second resources
On Thu, Jun 04, 2015 at 05:52:47PM +0200, Marco Marongiu wrote: As you may have noticed from my messages in this list, I've also been running leap second simulations with ntpd on Debian during the past few weeks. If you're using Debian Linux systems you may find the post I've just published useful: http://syslog.me/2015/06/04/a-humble-attempt-to-work-around-the-leap-second-2015-edition/ That is an interesting idea to use -x on both server and client. Does it make the leap second correction easier for the clients to follow and reduce the offset between them? In your offset plot there are two large (~0.5 second) swings. It doesn't look like the client is fast enough to follow that, but maybe the course of the correction is less variable? In my tests when only clients were using -x I saw offsets between them up to 0.8 seconds when one client overshoot a lot and the other didn't. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote: On 12/05/15 11:28, Marco Marongiu wrote: Hi there In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in the future less than 28 days, the leap warning bits are set. What are the practical consequences of the warning bits being set? Will they cause the leap second to be armed in the kernel eventually? What if the kernel discipline is disabled? To be a bit clearer, further down it says When a majority of the survivors show warning, a leap is programmed at the end of the current month. What does that programmed stand for...? I think it means setting of the leap status that's reported in NTP packets and if the kernel discipline is enabled it also sets the kernel leap status bits. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On Wed, May 13, 2015 at 11:44:37AM +0200, Marco Marongiu wrote: I understand that the leap second is not armed in the kernel if only the warning is set. Rather, it seems that the warning is used by a client to understand if it should believe its upstreams when they claim there will be a leap second by this month. I think my interpretation is correct but I'd really appreciate if someone could either confirm or clarify, so that I/we know exactly what to expect. I'm not sure what exactly are you asking here. Do you see in your testing or the source code something different from what is described in the document? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trouble Simulating Leap Seconds
On Wed, Apr 08, 2015 at 12:31:18PM -0400, Jim Witschey wrote: Thanks for the pointer, Chris -- that didn't seem to help, though. I'd been setting the clock to 23:50, and INS wasn't set at midnight when I changing that to 23:45. With what ntp version are you trying this and does is it have a valid drift file on start? If it's a 4.2.6 or older and there is no drift file, it will need at least 15 minutes to estimate the initial frequency and only then it can set the leap status. Also, is the server reporting synchronized status right from the start? You might want to start at 23:30 to be sure both server and client had enough time to synchronize. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trouble Simulating Leap Seconds
On Mon, Apr 06, 2015 at 01:56:48PM -0400, Jim Witschey wrote: Do I understand correctly that add_leap_second is an NTP-internal flag, while INS is a kernel flag? If so: when does the INS flag get set in the kernel? Should I expect ntpd to do so? ntpd should set the kernel flag by calling ntp_adjtime()/adjtimex() with STA_INS in the status field. You could run ntpd in strace to verify that. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trouble Simulating Leap Seconds
On Wed, Apr 01, 2015 at 04:20:57PM -0400, Jim Witschey wrote: The server's warning for the upcoming leap second seems to propogate to the clients, as I see `leap_armed` in the output for `ntpq -c rl` before midnight, and `leap_event` afterwards. However, when I loop `date -u` over the leap second, I don't see a leap second getting inserted -- I expect 23:59:59 to last for 2 seconds, but it doesn't. The time goes straight from 23:59:59 to 00:00:00 the next day. In addition, I don't see any information about inserted leap seconds in the logs when I search with `dmesg | grep leap` or `sudo grep leap /var/log/syslog`. Does status printed by ntptime include INS before midnight? Any chance ntpd is started with the -x option or there is tinker step command in ntp.conf? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote: On 21/02/2015 17:52, William Unruh wrote: [] It will do that too. The crucial item there is the only method of time correction is manual entry which is different from ntpd and orphan mode. I have no idea why this conversation is continuing. The two are different. The two methods are trying to solve the same problem (timekeeping of isolated systems) but doing so in a different manner. If you like one better than the other, that is fine. But they are not the same. Bill, please enlighten me why I cannot, using NTP's orphan mode, set the time on one PC manually and have another PC sync to it? Well, you can, but it's not as easy. You need to find the orphan parent first (i.e. the system with the smallest refid), somehow figure out its phase and frequency error to the real time, and correct them behind ntpd's back (possibly with the date and ntptime -f commands). With chrony you just run chronyc -a settime xx:xx:xx once in a while on the server and it will do the rest for you. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 04:15:45PM +, Rob wrote: The default PPS refclock driver poll is 0 (1s), this be changed too if the PPS signal has a higher rate. Some GPS units seems to have this configurable (e.g. ublox NEO-6T). The PPS really is 1 PPS, but I am not sure if chrony is evaluating each pulse separately or is averaging 16 pulse measurements into one clock adjustment group. (as it says poll 4) It's the latter. The PPS samples collected in one poll interval are processed by a median filter and the result is used to update the source statistics and update the clock. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 10:58:14PM +, Harlan Stenn wrote: Would the temperature monitoring script and coefficient generation/processsing stuff be a good GSoC project? Not really, it would be probably easier to write the scripts than write the GSoC application. I'd be more interested in some research on software temperature compensation itself, how good the measurements need to be for a given time reference to be useful etc. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Wed, Feb 18, 2015 at 10:00:08PM -0500, Paul wrote: On Wed, Feb 18, 2015 at 8:53 PM, William Unruh un...@invalid.ca wrote: On 2015-02-19, Paul tik-...@bodosom.net wrote: In the specific case of PPS I don't see any advantage. Well, no. Lichvar did some tests with PPS and found that chrony disciplined the clock much better than did ntpd (factors of over 10). I think that is a difference. Do you have a link to that? The graphs I saw were all for (simulated?) clients. But it's been a while. It could be this post http://lists.ntp.org/pipermail/questions/2010-March/026157.html My update to that after the years would be that 3x is not really the minimum difference. If the clock is stable enough, they can perform similarly. A difference is not necessarily an advantage (I said advantage not difference) but I would have assumed that https://github.com/mlichvar/chrony/blob/master/README was correct which says one microsecond* (I assume offset but it's unclear) but let's go with 10x NTPd. On my machines NTPd offsets and jitter can be sub-microsecond. So the target is O(10) nanoseconds? I don't think 10 nanoseconds is possible with 1us jitter and normal unstabilized clock. When using a PTP clock on PCIe as a reference it can get quite close though, see this graph from stats collected over a few hours: https://mlichvar.fedorapeople.org/chrony/refclock_phc0.png -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote: We have systems in places that are not temperature controlled and then chrony is much better. I am looking for the best way to find the values to use in the tempcomp configuration directive. What resolution does the sensor have? Don't expect good results with 1C or 0.5C resolution that sensors on mainboards typically have. Ideally there would be a program that analyzes a log of momentary temperature and frequency values to find the coefficients, but how is such a logfile even generated? Should I enter a tempcomp line with zero coefficients and then use the tempcomp logging? Yes, you can use that or you can collect data from the sensor file with a while true; do echo $(date +'%s'; cat /sys/...); sleep 1; done script independently from chronyd. After collecting enough data over a wide range of temperature you need to pair the temperature values with frequency from the tracking log and find the coefficients for the quadratic function, or (with 2.0-pre1) it's easier to create a file containing list of (temperature, correction) points for the second form of the tempcomp configuration. For example, you could divide temperature in 0.1C intervals and use mean frequency offset as the correction. Not sure if it needs to be negated or not, I always forget. I agree it would be nice to have a script that would automate this process. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 02:42:39PM +, Rob wrote: Ok but of course we are using PPS and a 16 second polling interval. (or maybe the PPS refclock polls even faster although it displays 4 as the poll interval indicator) You may want to try a shorter polling interval and see if the swings are still there. If poll 3 doesn't help, you can try even shorter, but normal timekeeping when the temperature isn't changing rapidly will likely get worse. The default PPS refclock driver poll is 0 (1s), this be changed too if the PPS signal has a higher rate. Some GPS units seems to have this configurable (e.g. ublox NEO-6T). -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: I am still finding out what sensor is best to use, we do have a room temperature sensor that has .1C resolution and is readable via snmp, and there are the usual sensors for board- and inlet air temperature. (and of course CPU temperature) It does not matter if it is only a course indication, the room temperature varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not bad relative to that. In my tests using a sensor with 1C resolution it was barely useful with NTP sources and 1024s polling interval. If the sensitivity is around 0.1 ppm per degree, 1C resolution means the compensation jumping the frequency in 0.1ppm steps. That's a lot, especially if you compare it to the tracking skew with a refclock. I'd probably try a shorter polling interval first and maybe get a PPS with higher rate if possible to minimize the swings due to temperature changes. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 07:19:39PM +, Rob wrote: The PPS refclock has changed is refid from PPP0 to PPP1 with this version. That is a bug, the refid numbering wasn't supposted to change in the new version. Fixed in git. Thanks. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 03:30:52PM +, Rob wrote: Miroslav Lichvar mlich...@redhat.com wrote: On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote: Is chronyc of 1.31 compatible with chronyd 2.0? Yes, old configuration should still work. But you can use acquisitionport 123 as a workaround if you prefer stable version. Well I tried that before and it did not solve that issue. Hm, you are right. I tried it again and it seems this works only with 1.30 and not 1.31. What I mean is can I manage a mix of 1.31 and 2.0 servers from a single system with one version of chronyc. Yes, that should be compatible. The cmdmon protocol was just extended (with one command - runtime makestep configuration) between 1.31 and 2.0. With 2.0 chronyc you can do everything 1.31 chronyc does, with 1.31 chronyc you can do everything except that one command. For 2.0, you will need to add bindcmdaddress 0.0.0.0 to chrony.conf for as it binds to the loopback interface by default now. It would be nice when chronyd could be contacted using ntpq with at least the -p and the -c rv commands. Then the monitoring system does not need to know what kind of ntp daemon is running on the servers. It would make the monitoring easier, but chronyd has different internal variables so it would have to be an emulation even if only the -p and -c rv commands were supported. From the security point of view, I'd prefer to not have any support for the private/control modes of NTP. The chrony protocol runs on a separate port and the access can be tightly controlled, independently from NTP access. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 03:12:27PM +0100, Terje Mathisen wrote: William Unruh wrote: I think, but am not sure, that the biggest problem with porting chrony to windows is that windows does not have a good way of having the kernel discipline the clock-- the equivalent of adjtimex on Linux. If this is the biggest problem, then it would already be running there! There is also the part with porting all the code to Win32/Cygwin :). GetSystemTimeAdjustment() SetSystemTimeAdjustment() The only hard part is that you have to manually convert the adjustment rate to an absolute value: Call Get* to retrieve the amount the system clock is incremented by on each timer tick/basic clock interval, then scale this value by the adjustment rate, i.e. to add 5.6ppm you would take the base value and multiply by 1.056. In what resolution can be the frequency controlled? I'm not sure if I remember correctly, I thought it was rather bad and would require dithering. Looking at nt_clockstuff.c in the ntp distribution, it certainly doesn't look easy. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 03:51:07PM +, David Lord wrote: Miroslav Lichvar wrote: As a workaround you can add acquisitionport 123 to chrony.conf to use just one socket for all (client, peer, server) communication, which will effectively disable the check in which the server's request is failing. Done and ready for next restart. Apparently, that workaround is not usable with 1.31, sorry for the noise. That was it, as restart after the client had been removed from chrony.conf the client picked up a reply from chrony. So that bug still needs fixing. I'm not sure what's wrong, it seems to be working for me with 2.0-pre1. Nothing wrong, it started working ok after I had removed that client from the config file. I meant with 2.0-pre1 the clients should be getting responses even if they are configured as servers in chrony.conf with otherwise standard configuration. It seems to work for me. If it doesn't for you, can you please post your chronyd -d -d output? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 12:56:27PM +, David Lord wrote: I've just fetched chrony-2.0-pre1. It seemed to compile and install ok on NetBSD-6/i386. The client IS one of the servers configured in chrony.conf and it behaved same as with 1.31. I didn't know this was such a common configuration. As a workaround you can add acquisitionport 123 to chrony.conf to use just one socket for all (client, peer, server) communication, which will effectively disable the check in which the server's request is failing. That was it, as restart after the client had been removed from chrony.conf the client picked up a reply from chrony. So that bug still needs fixing. I'm not sure what's wrong, it seems to be working for me with 2.0-pre1. ntp.conf (for ntp-4.2.6p5) on host 1: server 192.168.100.2 minpoll 3 maxpoll 3 driftfile /var/lib/ntp/drift chrony.conf on host 2: pool 2.pool.ntp.org iburst server 192.168.100.1 minpoll 3 maxpoll 3 driftfile /var/lib/chrony/drift allow 0/0 # /usr/sbin/chronyd -d -d ... 2015-02-16T14:16:27Z ntp_core.c:906:(transmit_timeout) Transmit timeout for [192.168.100.1:123 ] (this is chrony sending its client request) 2015-02-16T14:16:27Z ntp_io.c:679:(send_packet) Sent 48 bytes to 192.168.100.1:123 from [UNSPE C] fd 6 (receiving reply from ntpd) 2015-02-16T14:16:27Z ntp_io.c:562:(read_from_socket) Received 48 bytes from 192.168.100.1:123 to 192.168.100.2 fd 6 ... (discarding it for synchronization loop testD=0) 2015-02-16T14:16:27Z ntp_core.c:1287:(receive_packet) test123=111 test567=111 testABCD=1110 kod_rate=0 valid=1 good=0 (this is ntpd's request) 2015-02-16T14:16:33Z ntp_io.c:562:(read_from_socket) Received 48 bytes from 192.168.100.1:123 to 192.168.100.2 fd 5 (and chrony sending reply) 2015-02-16T14:16:33Z ntp_io.c:679:(send_packet) Sent 48 bytes to 192.168.100.1:123 from 192.168.100.2 fd 5 # ntpq -pn remote refid st t when poll reach delay offset jitter == *192.168.100.2 176.9.1.148 4 u68 3770.1430.044 0.055 If you compile chrony with --enable-debug, do you see similar Received and Sent message pairs in the chronyd -d -d output? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote: Is chronyc of 1.31 compatible with chronyd 2.0? Yes, old configuration should still work. But you can use acquisitionport 123 as a workaround if you prefer stable version. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: I have strace'd the daemon and I see that it does receive the datagram from the socket, but it does not send a reply. Hm, interesting. Can you post what follows that recvmsg() call? You could try running it with -d -d (after it's compiled with --enable-debug) and see if there are any debug messages indicating why it's dropping the client request. If there aren't any, you could try it with chrony-2.0-pre1 and see if it's different. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote: On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: I have strace'd the daemon and I see that it does receive the datagram from the socket, but it does not send a reply. Hm, interesting. Can you post what follows that recvmsg() call? You could try running it with -d -d (after it's compiled with --enable-debug) and see if there are any debug messages indicating why it's dropping the client request. If there aren't any, you could try it with chrony-2.0-pre1 and see if it's different. BTW, could it be that the client is one of the servers configured in chrony.conf? The client request from the configured server would be dropped as an invalid reply to chrony's own client request. This bug was in 1.30 and 1.31, it should be fixed in 2.0-pre1. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Sun, Feb 15, 2015 at 10:40:11PM +, Rob wrote: However, it does not reply to NTP requests from other systems with ntpd. (I can confirm that in a network trace) Is there a magic command that has to be in the config to make it work as a server? No, your configuration looks good. Any chance there is a forgotten firewall rule blocking NTP or that clients are actually using IPv6? Is chronyd listening on the port? # netstat -a -n -p | grep 123 udp0 0 0.0.0.0:123 0.0.0.0:* 29615/chronyd udp6 0 0 :::123 :::* 29615/chronyd Configuration: driftfile /var/lib/ntp/ntp.drift logdir /var/log/ntpstats log statistics measurements tracking tempcomp local stratum 10 makestep10 3 refclockPPS /dev/pps0 server 192.168.42.1 iburst server 192.168.42.60iburst server 192.168.42.61iburst allow 0/0 cmdallow192.168.42.0/24 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On Fri, Feb 13, 2015 at 05:42:54AM +, William Unruh wrote: On 2015-02-13, Paul tik-...@bodosom.net wrote: On Thu, Feb 12, 2015 at 7:27 PM, William Unruh un...@invalid.ca wrote: It was based on measurements I made with ntpd Are you assuming the numbers I provided are based on theory or were you looking over my shoulder when I perturbed system time by two milliseconds and watched it converge to O(10) microseconds in ~180 seconds. OK, so we seem to have two different sets of experiments with very different results. Note that I did not erase the drift file, or restart ntpd after my perturbation. The difference probably comes from different ntp versions. In some 4.2.7 version the code was reworked to correct the initial offset by adjtime() without touching the PLL. If the drift file contains an accurate value, the PLL should be now able to lock pretty quickly. There is an interesting problem with larger step threshold, however [1]. The code assumes the adjtime() correction can finish in 300 seconds. If the correction is so large that it can't finish before the next clock update, it results in worse behavior than without this feature. On systems that use the standard adjtime() slew rate of 500 ppm the maximum reliable correction is 150 ms, on systems with faster slew it's proprotionally larger. [1] https://bugs.ntp.org/show_bug.cgi?id=2021 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Authenticated TLS constraints in ntpd
On Wed, Feb 11, 2015 at 02:29:54PM +0100, Terje Mathisen wrote: Jan Ceuleers wrote: I'd like to draw this list's attention to an idea that Reyk Floeter floated, namely to use TLS to help sanity-check NTP timestamps: http://marc.info/?l=openbsd-techm=142356166731390w=2 Isn't public/private signed timestamps far better? It surely is, but NTP currently doesn't have a suitable authentication scheme for such use, does it? My understanding is this will change when the new Network Time Security (NTS) specification is implemented in NTP. Does anyone know how far it is? Is anyone working on it? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntpd -x and leap seconds
I was wondering what others think about handling leap seconds when ntpd is running in the slew only mode (-x option). The -x option disables the kernel discipline, so the kernel is not told about pending leap seconds and its up to ntpd to do whatever is needed. Older ntpd versions (before 4.2.6) didn't handle leap second in the daemon loop and -x could be used to avoid the backward step in the Unix time scale and possibly upset the applications running on the system. In 4.2.6 was added support for leap seconds in the daemon loop and ntpd now steps the clock by calling settimeofday() or clock_settime(), even if the step threshold (set by -x or tinker step) is larger than one second. Should be leap seconds threated as a normal offset and not corrected by step when the threshold is larger than 1.0? Should there be a separate option for them? http://bugs.ntp.org/show_bug.cgi?id=2745 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote: Miroslav Lichvar wrote: Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? Yes. How large is the adjustment to be smeared out? 1 seconds. It was a test to see how useful is smearing when bringing an isolated network back to UTC in a controlled manner. The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? The frequency is changing too quickly at start (2nd derivative is at the maximum) and the clients don't have a chance to shorten their polling interval to better track the server. The point is that there are better functions than cosine for this. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. They could have chosen a better function though. If its second derivative (wander) started at zero, the NTP clients could adjust their polling interval if necessary before the error gets large and the maximum error between the clients could be minimized. Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Default total number of servers NTP wants to have when using pool .....
On Wed, Dec 17, 2014 at 12:04:04PM +, Harlan Stenn wrote: I'd love to see discussion about what should the default number of servers queried be for the 'pool' directive? The How do I use pool.ntp.org? page [1] is pretty clear, quoting: Be friendly. Many servers are provided by volunteers, and almost all time servers are really file or mail or webservers which just happen to also run ntp. So don't use more than four time servers in your configuration, and don't play tricks with burst or minpoll - all you will gain is extra load on the volunteer time servers. There is clearly a tradeoff, and I'm inclined to say that between 5 and 9 is probably a good number. Ok, but examples of ntpd configuration using pool.ntp.org should follow their policy. Maybe you can convince them to change it. Do you think the servers are ready to handle twice as many clients? [1] http://www.pool.ntp.org/en/use.html -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] pool.ntp.org and authentication
On Tue, Dec 16, 2014 at 05:43:59AM +, Harlan Stenn wrote: d_anderson writes: Thanks! I quickly skimmed through the document, and I think I am asking the wrong questions.. I've been trying to think of good reasons to authenticate pool servers and I haven't come up with any good ones yet. Protection against MITM attacks? Of course, with a public pool like pool.ntp.org an attacker could join it with a number of his NTP servers, get their certificates signed and serve whatever he wants, no need for a MITM. Even if DNS was secure and all clients were configured to use four pool servers, the pool DNS server would not likely be able to prevent some clients getting three bad servers outvoting the fourth server. But I think it would still be a significant improvement in security. The NTS draft says the scheme is not applicable to pools. I'm wondering what would be needed to make it applicable. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] pool.ntp.org and authentication
On Tue, Dec 16, 2014 at 10:13:43AM +, Rob wrote: In the NTP pool the servers are only put in the DNS when the monitoring system considers the time returned from that server sufficiently reliable. But the server can easily separate the queries from the monitoring system from the queries by the clients they want to mislead, so it is trivial to keep the servers in the pool while returning wrong time to others. Agreed. The assumption is that most servers in the pool are not doing that and it's much less likely that a client gets three malicious servers from the pool than someone on the network path to the internet running a tool like this: https://github.com/PentesterES/Delorean/ -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Default total number of servers NTP wants to have when using pool .....
On Mon, Dec 08, 2014 at 01:47:33PM -0500, Paul wrote: On Mon, Dec 8, 2014 at 12:27 PM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: When using the pool directive, NTP tries to get a certain total number of servers. What is that number, please (I don't know where to find it in the source code). I'm seeing a total of 9 servers, with ten lines in the ntpq -pn output, one line being the pool directive itself. Is that correct and expected? maxclock *maxclock*Specify the maximum number of servers retained by the server discovery schemes. The default is 10. See the Automatic Server Discovery http://www.eecis.udel.edu/%7Emills/ntp/html/discover.html page for further details. Should be the example of simple client configuration on ntp wiki [1] updated to include tos maxclock 5 to not increase the NTP traffic as users and OS vendors will be switching to the pool directive? Or change the default value of maxclock? [1] http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.10. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD PPS
On Tue, Dec 09, 2014 at 03:29:45PM +0100, Sander Smeenk wrote: I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. The GPS provides a PPS signal via serial and i use gpsd to provide the NMEA sentences and pulse data in shared memory to NTP. This partly works. NTP syncs against the PPS signal but the NMEA signal is always marked as falseticker even though i managed to bring down the offset to -1.5ųsec average by fudging the time a bit. The NMEA signal offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec. 1) Can i get a 'true PPS sync' with this setup? Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? If it's a recent version of gpsd which uses kernel timestamps (check for KPPS messages in gpsd -D 4 output), you may already have a true PPS sync. The PPS and NMEA timestamps are paired in gpsd, so it's not necessary to add the NMEA source to ntpd. To avoid problems with the falseticker, you can remove the source from ntpd configuration or use the noselect option to never use it and only monitor it. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD PPS
On Wed, Dec 10, 2014 at 11:50:22AM +, David Taylor wrote: With -D 4 I get a list of devices ending with PPS, but presumably that is not the same as KPPS? In gpsd the PPS without K is the userspace timestamping. With kernel timestamping the log looks like this: gpsd:PROG: PPS edge: 1, cycle: 100 uSec, duration: 78 uSec @ 1418214654.07216 gpsd:INFO: PPS hooks called with accepted 1418214653.99223 offset 0.00777 gpsd:PROG: PPS edge accepted 1418214653.99223 offset 0.00777 gpsd:PROG: KPPS assert 1418214653.99223, sequence: 73 - clear 1418214654.20573, sequence: 73 gpsd:PROG: KPPS data: using clear gpsd:PROG: KPPS cycle: 99 uSec, duration: 21 uSec @ 1418214654.20573 I did try an apt-get first to update gpsd but it seems I have the most recent available. It seems I have 3.6. Do I need a development version or...? The kernel PPS support was added in 3.0 or so, but gpsd needs to be compiled with the timepps.h header, similarly to ntpd for the ATOM and other drivers. Also, some gpsd versions had bugs in the PPS/KPPS support and I'm not sure if 3.6 was a good or bad. The latest version - 3.11 is working well for me, 3.10 was not. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Mon, Dec 08, 2014 at 03:27:15AM +, William Unruh wrote: On 2014-12-07, Charles Swiger cswi...@mac.com wrote: Yes, so chrony recommends using maxpoll=4 to the LAN, and not only to local refclocks. No, read the chrony docs. the default is maxpoll 10 minpoll 5. The default minpoll is 6 and maxpoll 10, exactly the same as in ntpd. That the faq as an example uses 2 and 4 is I agree stupid. It is faq. I have no idea who wrote it. I wrote it. What exactly is wrong with poll 4 on a LAN? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
