[chrony-users] chrony-4.6 released
The final release of chrony-4.6 is now available. The source code is available here: https://chrony-project.org/releases/chrony-4.6.tar.gz SHA256 sum: 9adad4a5014420fc52b695896556fdfb49709dc7cd72d7f688d9eb85d5a274d5 Notable changes: * Allow disabling pidfile -- Miroslav Lichvar signature.asc Description: PGP signature
Re: Fwd: [chrony-users] ntp symmetric auth for internal clients
On Mon, Sep 02, 2024 at 02:31:03PM +0200, Ede Wolf wrote: > As for specifying the key on the client side, that is exactly what I have > done, still ntpd claims auth = bad > > The issue seemd to be sha1, as using a md5 key, something I have avoided so > far, makes everything work. It might be an issue with ntpd using different keys than what you expect. ntpd interprets shorter keys as ASCII and longer as HEX. With chrony you have to tell what it is. If unsure, try this conversion script: https://github.com/mlichvar/ntp2chrony -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] ntp symmetric auth for internal clients
On Mon, Sep 02, 2024 at 12:48:42PM +0200, Ede Wolf wrote: > I need to specify a key for the systems I am serving to, however, the local > directrive has no key option available. A server cannot force clients to use a key. The key needs to be specified on the client side. > And a global option, similar to "trustedkey 5" in ntpd.conf, for those who > are also familiar with ntpd, seems also not available. All keys in the chrony key file are trusted. Unlike with ntpd, there is no way to trust only a subset of them. chrony and ntpd should interoperate in both client-server directions. > > So if I want to require, let's say key 5 for internal clients, what would be > the proper way to archive this? Specify it in the server directive in the client's config. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] (SCAP-Finding) command port has to be closed
On Wed, Aug 21, 2024 at 01:53:13PM +0200, Nuß Bratling wrote: > Hi, > > There are these rules: > RHEL9: > https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2023-09-13/finding/V-257947 > RHEL8: > https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-06-14/finding/V-230486 > I don't know if you know about these rules, and if no, would bringt it to > your attention, that this rules perhaps should be changes, or, if you do > know about these rules, I would like to ask what the rationale behind those > are. I'm aware that this thing exists and I agree that some of the suggestions are questionable. It might depend on the use case. If nothing is expected to be talking to the UDP port, it makes sense to close it. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Recommendation for chrony with 1PPS setup
On Wed, Aug 21, 2024 at 03:13:56AM +0530, Abhijith Sethuraj wrote: > S Name/IP AddressAuth COpts EOpts Last Score Interval Leap > === > * 1PPS N -P--- -P---1 1.0-7ns +31ns N > D foobarN -P--- -P---3 1.0 -1550ns +2091ns N The sources output in your original post had the '?' symbol for the source, but for 'D' in selectdata it should be '-' in sources. Did it change, or does it still show '?' ? > Also, one thing that I noticed is that if I stop the 1PPS signals, it's not > falling back to "foobar"; 1PPS remains as the best source. Should I add > something in the configs to make this work? See https://chrony-project.org/faq.html#_an_unreachable_source_is_selected -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Recommendation for chrony with 1PPS setup
On Tue, Aug 20, 2024 at 03:23:03PM +0530, Abhijith Sethuraj wrote: > Hello, > > We have a 1PPS input to the NIC and we're planning to run chrony to use > 1PPS as an additional refclock, in addition to getting time of day via NTP. > When we tried this out, we're not entirely sure if things work fine as the > source that gives time of day shows up as "unusable" in `chronyc sources`. The "?" character in the sources means a different state than those previously listed. Run chronyc selectdata -v to get the actual selection state. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] confirm unsubscribe cd0932a36f0086f8f55ddd04731f3c20
Just a reminder, the confirmation email needs to be sent to the chrony-users-requ...@chrony.tuxfamily.org address, not the actual mailing list. Hitting "reply" should work. If anyone has troubles unsubscribing, send me an email (please don't reply to to the list) and I'll remove your address. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] How to read the RTC value?
On Fri, Aug 09, 2024 at 04:14:24PM +0200, Jan Claußen wrote: > RTC ref time (GMT) > This is the RTC reading the last time its error was measured. > > so this is not the current RTC value either. How to read it out then without > having to stop chronyd? cat /sys/class/rtc/rtc0/date cat /sys/class/rtc/rtc0/time -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Using cellular network clock as refclock in chrony
On Wed, Jul 31, 2024 at 09:47:05AM +, Amol Lad wrote: > Is there a way to dynamically adjust these parameters? For example, at > startup, the settings can be 'poll 1 filter 1' and my application sends > samples every second. After the source is selected, my application can slow > down to send samples once every 5 seconds, and the 'filter' can return to its > default value and 'poll' can be set to 3." > Alternatively, can I always use "poll 1 filter 1" irrespective of my > application sending samples every seconds or once every 5 seconds? It cannot be changed in runtime. If you provide samples at a longer interval than the SOCK polling interval, the reachability register as shown by chronyc sources will have zeroes, but synchronization should still work as expected. > What are the drawbacks of setting 'poll 1 filter 1'? Less filtering can cause less stable synchronization of the system clock. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Using cellular network clock as refclock in chrony
On Wed, Jul 31, 2024 at 08:42:52AM +, Amol Lad wrote: > refclock SOCK /var/run/chrony.cellular.sock precision 1 prefer poll 3 refid > MODM > > (I tried reducing the poll to 1 but this does not seem to make any difference) Try adding "filter 1" to reduce the number of samples required per poll. Unlike with SHM, chronyd doesn't know how many SOCK samples there will be per poll, so it doesn't adjust the filter length automatically. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-users] chrony-4.6-pre1 released
The first prerelease for chrony-4.6 is now available. The source code is available here: https://chrony-project.org/releases/chrony-4.6-pre1.tar.gz SHA256 sum: b155188b0fcf396cc48380e1793a851a2a93fafcfdf4e58ea13a4a761bed59ee Notable changes since 4.5: Enhancements * Add activate option to local directive to set activation threshold * Add ipv4 and ipv6 options to server/pool/peer directive * Add kod option to ratelimit directive for server KoD RATE support * Add leapseclist directive to read NIST/IERS leap-seconds.list file * Add ptpdomain directive to set PTP domain for NTP over PTP * Improve copy server option to accept unsynchronised status instantly * Log one selection failure on start * Add offset command to modify source offset correction * Add timestamp sources to ntpdata report Bug fixes - * Fix crash on sources reload during initstepslew or RTC initialisation * Fix source refreshment to not repeat failed name resolving attempts -- Miroslav Lichvar signature.asc Description: PGP signature
Re: [chrony-users] Using cellular network clock as refclock in chrony
On Tue, Jul 30, 2024 at 12:05:29PM +, Amol Lad wrote: > Currently, my system time is about 30 seconds ahead of the time received from > the cellular provider, and it appears that chronyd is not updating the system > time with the time received on the SOCK. I'm unsure what I'm doing wrong. Any > suggestions would be greatly appreciated. >From the debug log it looks like your program is feeding chronyd samples with zero offset. The sample time is supposed to be the system clock when the sample is made and the offset is supposed to be the difference between the reference clock and system clock. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Certain NTS servers not synching, how to best troubleshoot ?
On Mon, Jul 29, 2024 at 08:27:41PM +, Laura Smith wrote: > I have a weird situation where I cannot get NTS working to the netnod.se > series of servers (e.g. gbg1-ts.nts.netnod.se ) > > Other NTS server are working without issue (e.g. ntppool1.time.nl) so its not > 4460 being blocked on a firewall. What exactly is in your chrony config? Netnod has separated NTS-KE and NTS-NTP servers: - gbg1.nts.netnod.se is an NTS-KE server (listening on TCP port 4460) - gbg1-ts.nts.netnod.se is an NTS-NTP server (listening on UDP port 4123) The config needs to specify the NTS-KE server. The address and port of the NTS-NTP server is negotiated in NTS-KE. When it's working correctly, "chronyc sources" should print the reverse lookup of the NTS-NTP server and "chronyc -N sources" should print the configured hostname of the NTS-KE server. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Best strategy for calculating average synchronization time.
On Mon, Jul 22, 2024 at 01:56:36PM +, Whelan, Andy wrote: > My management wants to know how fast Machine B time is converging to its > time source Machine A. > > Question 1: You're answer included "You would need an independent process > measuring the error of the system clock. It could be a second chronyd > instance running with the -x option" > I'm not following how I would use this second chrony instance to determine an > average of how fast Machine B time is converging to its time source Machine > A. Could you provide some detail? > > Question 2 "Chrony -x" - So we are running 2 instances of chrony on the same > machine? Does chrony -x get passed its own chrony.conf? Yes, you would give its own config with the -f option. It needs to specify its own pidfile, driftfile, bindcmdaddress, cmdport. See this related FAQ entry: https://chrony-project.org/faq.html#_can_ntp_server_be_separated_from_ntp_client You would configure it to poll much more frequently than the tested instance to better see what it is doing and how long it takes for the error to reach your acceptable value. You would monitor the 'System time' offset printed by chronyc (using the -h option to connect to the right instance). You would repeat the experiment multiple times to get an average value. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: Re: [chrony-users] question about the values in critical_runs array
On Fri, Jul 19, 2024 at 05:27:41AM +, 邹林志08963 wrote: > > I'm not sure what exactly you are pointing out here, but in our case > > we care only about the lower bound to increase the number of runs when > > it's lower than expected for the number of samples. If the number of > > runs is too high, we don't care. > > well, when the formula is " runs = mu - sqrt(var) * Z ", > the critical_runs will be: > and when the formula is " runs = mu + sqrt(var) * Z ", > I just wonder which one is correct. The first one. We care about the lower end of the interval. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: 回复: [chrony-users] question about the values in critical_runs array
On Tue, Jul 09, 2024 at 11:34:04AM +, 邹林志08963 wrote:
> I found a formula on the web:
>
> Z = [ r - E(r) ] / sigma
>
> E(r) = ( 2 * n1 * n2 ) / ( n1 + n2 ) + 1,
>
> sigma = sqrt{ [ 2 * n1 * n2 * ( 2 * n1 * n2 - n1 - n2 ) ] / [ ( n1 +
> n2 ) * ( n1 + n2 ) * ( n1 + n2 -1 ) ] }
>
> if Z is z , r is runs , E(r) is mu , sigma is sqrt(var), then r = Z *
> sigma + E(r).
>
> should runs be "mu + sqrt(var)" or "mu -sqrt(var)" ?
I'm not sure what exactly you are pointing out here, but in our case
we care only about the lower bound to increase the number of runs when
it's lower than expected for the number of samples. If the number of
runs is too high, we don't care.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Best strategy for calculating average synchronization time.
On Wed, Jul 17, 2024 at 12:53:47PM +, Whelan, Andy wrote: > I want to try to try a bunch of experiments where we manually change the > times on machine B and monitor how fast the system time on machine B > synchronizes to, say within a second of Machine A. I want to calculate an > average synchronization time. You would need an independent process measuring the error of the system clock. It could be a second chronyd instance running with the -x option using a much shorter polling interval. Please note that if you step the system clock of machine B behind chrony's back, you will disrupt its loop and it might take longer to recover than if you stepped the server's clock, or stepped the B's clock by using the chronyc settime and makestep commands. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] chrony ignoring shm source
On Wed, Jul 17, 2024 at 02:02:42PM +0200, folkert wrote: > I verified that in the shared memory segment, the 'valid' flag gets > set by the time-source and reset by chrony. I also added a printf in > shm_poll just before the last return statement of that function, and > that printf gets triggered. So chrony *does* poll and processed. I also > added printfs to RCL_AddSample and none of the return 0's are run. Can you compile chrony with the --enable-debug option, run chronyd with -d -d and see what debug messages you get for the refclock? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony and systemd-timesyncd
On Wed, Jul 17, 2024 at 12:08:26PM +0200, Jan Claußen wrote: > > With rtcdrift you will need to add also > > rtcautotrim to the config or periodically call chronyc trimrtc. > Both of these don't work unfortunately. chronc reports me 513 RTC driver not > running, although I have everything set. > > I am btw missing an /etc/adjtime file, since our rootfs including /etc is > read-only. Could that be a problem? No, that could cause only a local/UTC mismatch. What RTC driver is your machine using? Maybe it doesn't support interrupts. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony and systemd-timesyncd
On Tue, Jul 16, 2024 at 03:42:05PM +0200, Jan Claußen wrote: > So I found online that an rtcfile directive is needed for the rtcdata command > to work. I am still getting the above error message now. Makes me wonder if > RTC syncing ever worked with the rtcsync directive present. There was never > really a log about chrony syncing to the RTC. I have now tried to manually > set the RTC to a wrong value and have waited more than 11 minutes. The RTC is > still not getting set. Are you trying that with rtcsync or rtcdrift? With rtcsync there are no log messages from chronyd. It's the kernel's job to sync the RTC. With rtcdrift you will need to add also rtcautotrim to the config or periodically call chronyc trimrtc. https://chrony-project.org/faq.html#_what_is_the_real_time_clock_rtc -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony and systemd-timesyncd
On Fri, Jul 12, 2024 at 01:32:21PM +0200, Jan Claußen wrote: > So to not make me suffer more than necessary figuring out how to make all > these other services happy, I would like to ise chrony only as an NTP server > for some other client devices, which are not directly connected to the > internet. This would require me to run timesyncd and chronyd at the same > time. So I would have some questions: > Is it problematic to run chrony alongside timesyncd, even when only used as a > server? Not a problem if chronyd is configured to not touch the system clock, only serve time from it. That would mean no sources specified in the config, or use the -x option. But I think you would need to remove the conflict between the two services from their systemd unit files and in that case you might just as well disable timesyncd and run chronyd as a client. Generally, it's better to avoid timesyncd: https://chrony-project.org/faq.html#_should_i_prefer_chrony_over_timesyncd_if_i_do_not_need_to_run_a_server -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Debugging PPS messages in chrony
On Mon, Jul 08, 2024 at 10:07:46AM +0200, Morten Nissov wrote: > But it seems like this is not seen by chrony at all, as far as I know it > wants the SHM update to actually synchronize, but when I added that it > wasn't working so I'm trying to peel back the layers. Can I see > confirmation anywhere that chrony registers the PPS by itself? My chrony > config is loosely based on the default: You could compile chrony with the --enable-debug option and run chronyd -dd to see refclock debug messages, or you can add the "local" directive to the config to force the PPS to lock to the system clock and see if you get any measurements in the sources report. > But the directory is forever empty: > > $ ls /var/log -al | grep chrony > drwxr-xr-x 2119 1294096 Aug 25 2020 chrony It could be a permission problem. Is 119 the user ID of the chrony user? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] question about the values in critical_runs array
On Tue, Jun 25, 2024 at 01:47:27AM +, 邹林志08963 wrote: > where are the values in array critical_runs come from ? > for example, when there are total 50 sample points, if the total runs > value is larger than 19, then the value of a and b is reliable. > > the comment is "Critical value for number of runs of residuals with same > sign. 5% critical region for now." > what is the formula or method to get the runs value of 19 for 50 samples? It's the Wald-Wolfowitz runs test with the assumption that n1==n2. The table is calculated like this: - for i < 8 it's 0 - for i >= 8 it's mu - sqrt(var) * z where: mu = 2.0 * (i / 2.0) * (i / 2.0) / i + 1.0 var = (mu - 1.0) * (mu - 2.0) / (i - 1) z = 1.65 -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Pool vs. server without config parsing
On Fri, Jun 21, 2024 at 10:05:27AM -0400, Josef 'Jeff' Sipek wrote: > That is, when we see 3 sources in `chronyc sources` we can't find a way to > tell if we are looking at 3 servers or a pool of 3. The closest thing we > came up with is to use `chronyc sourcename` for each source, and try to > collate the results, but this seems hacky/fragile. > > Is there a way to distinguish the two scenarios? No, that information is not exposed. When a pool reaches the maxsources number of servers, it behaves same as if a server was repeated maxsources times in the config. It's not very clear to me how would that help you. There could be an unexpected script adding or removing sources with the chronyc add/delete command, or the reload sources command (e.g. DHCP hook). -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] setserial low_latency - is it necessary?
On Thu, Jun 13, 2024 at 08:22:03PM +, Sviatoslav Feshchenko wrote: > - Is the 1PPS signal buffered if "low_latency" is NOT set? I don't think it is. It should trigger the interrupt immediately. > - Is it necessary to configure the serial port for "low_latency" if 1PPS > signal is available on the DCD pin, when the goal is to maximize the accuracy > of the 1PPS signal? > For PPS it shouldn't matter. Easy to verify. Plot the raw offset from the refclocks log, switch the low_latency flag, and see if there are any jumps or changes in stability. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine
On Thu, May 16, 2024 at 06:01:10PM +0530, Abhijith Sethuraj wrote: > > Is this server synchronized to the same NTP server as the computer > > running the client application? What root distance does it report? > The server is synchronized to another NTP server that we don't have control > over. So, I don't think it's possible for me to give you the root distance. > It's safe to assume that the server's time is good, as they have a lot of > other clients apart from us and no one else reported any issues. This sounds like a stock exchange. Can you make a graph of the difference between the server and client timestamps you see in your application? You could specify a small offset correction in your chrony.conf to minimize the chance it will fall outside of the allowed range. > Sorry, I have one more question here. So, I have three sources here and one > among those is preferred (this server is in the same site as my client, the > other two are elsewhere). Looking through my measurements log, I see that > we're seeing a lot of testC failures for the duration of the issue. We're > polling the local server rapidly (minpoll, maxpoll of -4 and filter 5). Is > it possible that since there are a lot of testC failures (almost 16 > failures within a second, when the polling frequency should also be ~16 > times) and since the other two sources are not preferred (also their > offsets would be bad compared to the local one), we try to use the freq > adjustment in driftfile till we get good packets from the preferred source > or till we choose one of the non-preferred sources as the best source? If NTP measurements of the selected source are failing some of the tests, the clock will not be updated (unless the fallbackdrift option is enabled) and it will drift on its own, mostly due to temperature changes. With such high polling rates you should consider enabling the maxdelayquant option. That should limit the length of the runs with failed test C. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine
On Tue, May 14, 2024 at 04:35:14PM +0530, Abhijith Sethuraj wrote: > > How did you measure that 50us error? Can you use that source of time > > for synchronization? > Unfortunately, we can't use that as a source. This difference is what an > application noticed when it was looking at a timestamp that's there inside > a data packet (think of it as tx timestamp from a server that we don't have > control over) and what's obtained from system clock via gettimeofday() > right when it received the data packet. Is this server synchronized to the same NTP server as the computer running the client application? What root distance does it report? > Is there anything else that you would recommend we > monitor on our end to catch these issues? Also, if root distance is ~1ms, > does that imply that the value of current time that I get from > gettimeofday() essentially has an error of ~1ms or is this just inferring > to the error in measurements from source (and that the user-space app need > not consider this)? Root distance is an estimate of the maximum error. The actual error is usually much smaller, but if you don't have something more accurate to measure it, you won't know. You need a better server for the application server and client to minimize the maximum error. It needs to be closer to get a smaller root delay and have a better reference clock or better implementation to get a smaller root dispersion. Ideally, it should run chrony with hardware timestamping. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Re: Linux time goes wrong after changing the time with 'date' cmd
On Mon, May 13, 2024 at 09:02:31AM +0800, Feng Tang wrote: > So my thought is, since user already chose to trust 'chrony', and > when chrony has more realiable NTP time source, 'chrony' can help to > correct the 'wrong date' set by user with the right time, practically > 'rejecting' the huge time jump set by users. chronyd is trying to correct the clock, but a typical default configuration provided with distro packages allows steps only on start, so the ~10% slew can take very long time. The user would need to allow steps at any time. See this answer in the FAQ: https://chrony-project.org/faq.html#_is_chronyd_allowed_to_step_the_system_clock -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Silent Failure -- Enhancement Request
On Mon, Apr 22, 2024 at 03:54:50PM +, Chris Knox wrote: > That sounds to me like a vast improvement. According to Syslog > documentation, Facility 12 is reserved for the NTP subsystem -- so Chrony has > its own Syslog facility to work with. A Warning (Severity 4) on startup to > Syslog about unreachable time sources would help, followed by an Error > (Severity 3) if no time sources can be reached after some reasonable > interval. If no time source is available for some extended time (Days? > Weeks?), then there is a case to be made for logging it as Critical (Severity > 2), which should be enough to attract attention. In some configurations it can be expected. With the local directive it can work as an NTP server even if it has no sources. Anyway, with the latest code in git there should be one info message logged soon after start (after first source has 8 polls) if the selection fails. This is not intended to replace a proper monitoring system. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: SV: [chrony-users] Update interval larger than maxpoll
On Wed, May 01, 2024 at 10:04:22AM +, Henning Svane wrote: > Sorry I was not clear in my question. > My first question was more to what extend do offset say anything about the > precision or how to understand it? Small offsets indicate stable clock and NTP measurements, which are impacted by network delays, timestamping, etc. But it doesn't say anything about accuracy. You could have a clock stable to microseconds but off by tens of milliseconds due to asymmetric routing. > I tried to run ntpdata and that made even more confused as the Ref time (UTC) > for tracking and ntpdata even that they have been executed with a second > between says 20 minutes. And the time for ntpdata is the correct one. Why do > tracking think that the time is 20 minutes behind? ntpdata shows data from the last response, even if it wasn't used to update the local reference, which is what tracking shows. > It now says: > From tracking>> Update interval : 7113.7 seconds > From ntpdata>> NTP tests : 111 111 1101 The test C didn't pass, so it didn't update the local reference. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Update interval larger than maxpoll
On Sun, Apr 28, 2024 at 09:40:27AM +, Henning Svane wrote: > 2 questions > The green line: Is it correct that the time is only 0,03ms off from the > reference time. We don't know that. The root delay and dispersion are in milliseconds. You would need a much more accurate time source (e.g. reference clock or close stratum 1 server) to be able to measure the error of the clock in microseconds. > The red line I cannot understand why I get and update period over 128s. That might be due to measurements failing some NTP tests. Check ntpdata or the measurements log. See also this answer to a similar question: https://chrony-project.org/faq.html#_does_selected_source_drop_new_measurements > From the config file. > server mmo1.nts.netnod.se nts iburst minpoll 6 maxpoll 7 > > odin@swntp01:/var/log/zabbix$ chronyc tracking > Reference ID: C23ACCC4 (mmo1-ts.nts.netnod.se) > Stratum : 2 > Ref time (UTC) : Sat Apr 27 09:46:46 2024 > System time : 0.13121 seconds slow of NTP time > Last offset : -0.07295 seconds > RMS offset : 0.03989 seconds > Frequency : 51.591 ppm fast > Residual freq : -0.000 ppm > Skew: 0.010 ppm > Root delay : 0.002788649 seconds > Root dispersion : 0.005857296 seconds > Update interval : 8004.5 seconds > Leap status : Normal > > Regards > Henning- -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine
On Fri, Apr 19, 2024 at 02:44:21AM +0530, Abhijith Sethuraj wrote: > Hello, > > I'm noticing issues with my system clock being inaccurate by almost 50us, > even though "System time" in `chronyc tracking` shows offsets in the order > of ns. This was noticed by an application that tried to get current time by > calling `gettimeofday()`. How did you measure that 50us error? Can you use that source of time for synchronization? > Root delay : 0.73557 seconds > > Root dispersion : 0.000997235 seconds Root distance (half of root delay + root dispersion) is over 1 millisecond here. That's an estimate of maximum clock error due to asymmetries and clock instability. > almost similar to "root dispersion"? Also, what recommendations do you have > for monitoring chrony, so that I can catch this before it affects my app? > Also, are there any config tweaks that I can try out here to help me? You need a better server, one that has a smaller root dispersion and hardware timestamping on both the server and client to get the maximum error below 50 microseconds. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Silent Failure -- Enhancement Request
On Thu, Apr 18, 2024 at 10:45:10PM +, Chris Knox wrote: > Is there a configuration in chrony.conf to complain when the time server is > not reachable? If there is, why isn't that the default behavior? chronyd logs "Can't synchronise: no selectable sources" when all sources become unreachable. It doesn't log that if they were never reachable. Maybe it should do that after 8 polls after start. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Temporarily stop syncing
On Wed, Apr 17, 2024 at 11:40:17AM -0400, Jeffrey Kane Johnson wrote: > Is there functionality for indicating to chrony that it should temporarily > stop syncing? As an example, if I wanted to ensure that the system clock is > not altered while another process is running, I could do something like > `touch /tmp/stop_chrony.lock` and then chrony will stop syncing until that > file is removed. NTP sources can be switch to offline with the chronyc offline command. With chrony >= 4.4 you can add the noselect option to each source (NTP server or refclock) with the chronyc selectopts command, which will stop updates of the system clock while still polling the sources. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Recommendation on chrony with 1pps
On Tue, Apr 09, 2024 at 07:23:25PM +0530, Abhijith Sethuraj wrote: > Hello, > > What's the recommended way to use 1pps signals with chrony? I have two > options here: > > 1. I have a specialized Solarflare card that has a 1pps receiver on the > card itself and comes with sfptpd (PTP daemon for Solarflare cards and that > has support for chrony). So, I could run sfptpd (for 1pps) side-by-side > with chrony (for time of day). I'm not sure what sfptpd does with chrony. If you don't need PTP, I'd leave sfptpd disabled. If you need PTP, consider switching to linuxptp and if you need to use both NTP and PTP as sources at the same time, there is timemaster in linuxptp to simplify the configuration. > 2. Specify /dev/ppsX as a 1pps source in chrony configs and mention a ref > clock for time of day. Additional question here: Is it possible to specify > another NTP server (strat 1) as a ref clock here? Asking since the examples > are all targeted towards GPS ref clocks. If that's possible, could you > provide a sample config as well? Just specify both. Nothing special needed, e.g. server a.b.c.d iburst refclock PPS /dev/pps0 > > Additionally, for #2 above, do I have to recompile chrony from source with > additional arguments? I remember reading somewhere that by default chrony > doesn't support PPS. Alternatively, if it's possible to identify this via > something like `chronyd --version`, please let me know as well. Try it and see if it fails to start due to missing driver. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Clarification of terminologies
On Tue, Apr 09, 2024 at 05:04:37PM +0530, Abhijith Sethuraj wrote: > When looking at offsets, is it better to rely on RMS offset from `chronyc > tracking` or the best source's estimated offset from `chronyc sources -v` > (provided this is only for the last sample)? Also, how would these differ > from running `adjtimex()` and taking a look at `timex`'s offset member? The tracking offset shows the last offset of the NTP clock estimating true time considering all combined sources. The "System time" offset is the current offset of the system clock to the NTP clock. The sources offset is the last measurement of the source relative to the NTP clock. The timex offset is the kernel's PLL offset. chrony doesn't use that, so it should always be zero. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] minstratum directive option
On Wed, Mar 20, 2024 at 01:49:38AM +, Sviatoslav Feshchenko wrote: > Their website states "For all practical purposes, the average time > disseminated by the stratum-2 server is the same as the stratum-1 > servers." It would therefore be reasonable in my opinion to be able > to adjust their NTP source from stratum 2 to stratum 1 in Chrony, > and currently, there is no such possibility. There is a possibility to ignore stratum in the source selection by setting stratumweight to 0. That's a global option. What you propose could be implemented (reducing stratum for selection but not for clients), but I'm not sure it's worth the extra complexity. I agree with what others said. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Perms on refclock socket
On Sun, Mar 17, 2024 at 04:06:48PM -0700, infection.many...@aceecat.org wrote: > is there any way to make the socket created for a SOCK instance > have a bit looser permissions? Currently it is always root:root > mode 0755 which means a non-root process can't connect to it :-( > > Or maybe it is just the ambient umask in action? Can that be changed > in the systemd bit for chrony? > > I have written a driver process for a device and I'd much prefer > not to have running it as root, at least for some time until I'm sure > it's bugfree. Normally you wouldn't want non-root users to be able to send chronyd bogus refclock data in order to modify the system clock. You could drop root privileges in your program after connecting to the socket. That's what gpsd and ntp-refclock do for example. If you really want to change the permissions or ownership of the socket, you can do it in the chronyd systemd service file like this ExecStartPost=/usr/bin/chown user:root /var/run/chrony.refclock.sock -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: Re: [chrony-users] Repeated 'refresh'es may cause excessive DNS queries
On Wed, Mar 13, 2024 at 02:05:06PM +0100, Miroslav Lichvar wrote: > I think I see what is happening now. The config specifies a pool which > means 4 servers by default. You override the real DNS record with a > single IPv4 server. IPv6 is disabled or unreachable. chronyd resolves > the name and gets only one working IP address. It doesn't remove the > name from the resolving queue in order to get the 3 missing addresses. > When you make the refresh command, the name of the unresolved sources > is added to the queue again, but that doesn't provide a new address, > so they stay there and the queue accumulates duplicated resolving > requests. > > I'll fix that. It should be now fixed in git. Thanks for the report. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: Re: [chrony-users] Repeated 'refresh'es may cause excessive DNS queries
On Tue, Mar 12, 2024 at 05:35:06PM +0100, t.barnew...@avm.de wrote: > > That seems to be working for me as expected. I see one request per > > refresh. Can you please build chronyd with --enable-debug and post the > > chronyd -dd output for first few refresh commands? > > I have attached the debug log after 4 refresh commands. > chrony made about 320 DNS requests after those. Ok, thanks. I think I see what is happening now. The config specifies a pool which means 4 servers by default. You override the real DNS record with a single IPv4 server. IPv6 is disabled or unreachable. chronyd resolves the name and gets only one working IP address. It doesn't remove the name from the resolving queue in order to get the 3 missing addresses. When you make the refresh command, the name of the unresolved sources is added to the queue again, but that doesn't provide a new address, so they stay there and the queue accumulates duplicated resolving requests. I'll fix that. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Repeated 'refresh'es may cause excessive DNS queries
On Tue, Mar 12, 2024 at 04:35:59PM +0100, t.barnew...@avm.de wrote: > STEPS TO REPRODUCE: > 1) Install a DNS server on machine A (can also be a VM) and configure it to > always reply with a TTL of 0 for certain domains. This can be accomplished > with > dnsmasq and a hardcoded entry in /etc/hosts for, say, 2.europe.pool.ntp.org: > > > cat /etc/hosts > # HACK for testing: use ptbtime1.ptb.de as source > 192.53.103.108 2.europe.pool.ntp.org > [snip] > > 2) On machine B, point the local DNS resolver to machine A. > Install chrony and configure it to use only the source from step 1. > > > cat /etc/chrony/chrony.conf > pool 2.europe.pool.ntp.org minpoll 10 iburst > [snip] > > 3) Repeatedly issue "chronyc refresh" commands on machine B and watch the > sparks > (and the DNS queries) fly. That seems to be working for me as expected. I see one request per refresh. Can you please build chronyd with --enable-debug and post the chronyd -dd output for first few refresh commands? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Normal? "delay xxx is too high, ignoring" Fix?
On Sun, Feb 18, 2024 at 04:21:50PM +, Tovli Toda wrote: > My Create3 robot querying Chrony running on a Raspberry Pi 5, is reporting: > > > * Feb 18 15:18:46 Create3-WaLi user.notice ntpd: ntpd: reply from > 192.168.186.3: delay 0.003797 is too high, ignoring > > > every 3 to 15 minutes. I'm not sure what NTP implementation is that. If it's polling once per minute and ignoring only every 3rd to 15th measuement, I think that's just normal occasional congestion in the network and it's working fine. > $ chronyc tracking That looks ok to me. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony refclock socket 'disappears'
On Mon, Feb 12, 2024 at 07:14:24AM -0500, Kevin P. Fleming wrote: > However, randomly, the GPS source just stops, and Chrony starts tracking one > of the servers from us.pool.ntp.org. With the current configuration files > there is nothing output in any logs (either for Chrony or gpsd) when this > happens, but if I restart gpsd then I see this: > > Feb 12 06:16:56 core23-a systemd[1]: Starting gpsd.service - GPS (Global > Positioning System) Daemon... > Feb 12 06:16:56 core23-a gpsd[2349564]: gpsd:ERROR: SHM: shmget(0x47505344, > 29416, 0666) SHM export failed: Invalid argument(22) I'd suspect another gpsd instance started for some reason and interfering with this one. Maybe a USB device is plugged in and some script starts a new instance instead of adding the device to the existing one? > What can I do to figure what may be causing this? Is it safe/wise to run > chronyd in 'production' mode with "-L 2"? This situation only occurs about > once per week across the two machines, so I'll have to run with logging > enabled for quite some time to catch it. -L 2 will reduce logging. -L 0 is default. -L -1 would log debug messages if they are compiled in. You can try attaching to the chronyd process with strace to confirm it's not receiving anything on the socket when it happens. It would be just waiting in the select() call. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Per-source address family preference
On Wed, Nov 29, 2023 at 10:32:02AM +0100, Miroslav Lichvar wrote: > On Tue, Nov 28, 2023 at 08:12:29PM -0500, Rob Foehl wrote: > > I'm looking for a way to limit the address family used for a given > > source specified by name, e.g. something like > > > > pool 2.pool.ntp.org maxsources 2 [inet6/ipv6_only_please] > > > > That's not currently possible. In my todo list I have an item to > add the -4/-6 option to the pool/server/peer directive similarly to > ntpd. In latest development code there are new options "ipv4" and "ipv6" to restrict the used IP version for individual sources. I didn't use the -4/-6 option after all to avoid breaking existing scripts which expect hostname as the first argument of the directives. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] python configuration builder
On Mon, Feb 05, 2024 at 10:40:08AM -0800, Jerry Scharf (he/him) wrote: > Hi, > We have some appliances that we need to transition from ntpd to chrony. > Most of our management sw uses python. Before I go off and write > something from scratch to deal with abstract time sync -> configs in > chrony/ntpd, I wanted to see if anyone knows of similar software out there. > I found nothing in my searches.. A python module for writing chrony configuration? I think each management application includes their own. There is also ansible and thousands of various roles used for time sync configurations. Maybe this python script could help you if you wanted to specifically cover the ntpd features: https://github.com/mlichvar/ntp2chrony -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Fail to sync after eventual internet connection
On Fri, Feb 02, 2024 at 03:06:12PM +, Alan Young wrote: > # Step any offset > 2 ms (of the first 40) > makestep 0.002 40 > local orphan > server 169.254.8.1 minpoll 2 maxpoll 6 burst iburst xleave > > >Log messages from this device: > > Jan 1 15:58:25 (none) daemon.info chronyd[510]: Can't synchronise: no > selectable sources > Jan 1 15:58:28 (none) daemon.info chronyd[510]: Selected source > 192.168.64.139 > Jan 1 16:56:20 (none) daemon.info chronyd[510]: Selected source > 5.161.184.148 (2.ntp.service.net) > Jan 1 16:56:20 (none) daemon.warn chronyd[510]: System clock wrong by > 1706820647.650953 seconds It looks like it ran for an hour before the large offset was measured? At the configured polling interval that would likely be more than the 40 clock updates allowed in the makestep directive, so it wouldn't step. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: SV: SV: [chrony-users] Output from chronyc sources -v
On Thu, Jan 25, 2024 at 01:19:41PM +, Henning Svane wrote: > In the configuration they communicate as servers but I have thought I would > prefer to use Peer, but when I read the documentation, I am unsure if this is > the best way. Client/server is better. > I can see the current version is 4.5 but the version coming with Ubuntu 22.04 > is 4.2.2, will you suggest to upgrade to version 4.5. Depends on your requirements. See the entries in NEWS between 4.2 and 4.5 to decide if it's worth the trouble to compile from source. > You mention that it is not a good praxis to mixing authenticated and > unauthenticated NTP sources, will it be sufficient to use a key file or do I > need to upgrade to NTS. Is it possible to setup chrony to respond both to NTS > and til NTP? Plain NTP, NTP protected by symmetric keys, and NTP protected by NTS can all be mixed in one configuration. Symmetric keys are simple to configure: - chronyc keygen 100 > /etc/chrony/chrony.keys - copy the key file to the other machines - add "key 100" to the server's specification in chrony.conf on all machines - restart chronyd - done -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: SV: [chrony-users] Output from chronyc sources -v
On Wed, Jan 24, 2024 at 12:25:27PM +, Henning Svane wrote: > sudo chronyc selectdata > S Name/IP AddressAuth COpts EOpts Last Score Interval Leap > === > * time.dfm.dk Y - --TR-0 1.0 -1620us +2207us N > + gbg1-ts.nts.netnod.se Y - --TR- 56 1.0 -3979us +3541us N > + gbg2-ts.nts.netnod.se Y - --TR- 57 1.0 -3895us +3548us N This output shows some sources combined. > D lul1-ts.nts.netnod.se Y - --TR- 52 1.0 -11ms +13ms N > D lul2-ts.nts.netnod.se Y - --TR- 72 1.0 -11ms +13ms N These two are not combined because their root distance (11+13ms) is too large when compared to the best source (1.6+2.2ms). > T ns.tele.dkN - -1 1.0 -4366us +6048us N > T swntp02.energy.dk N - - 72 1.0 -1685us +2349us N > T swntp03.energy.dk N - - 96 1.0 -1842us +2450us N > T swntp04.energy.dk N - - 76 1.0 -1627us +2387us N > T swntp02.energy.dk N - - 18 1.0 -1751us +2379us N > T swntp03.energy.dk N - -3 1.0 -1773us +2443us N > T NTP04.energy.dk N - - 89 1.0 -1557us +2405us N These sources are ignored because they are not authenticated and not more accurate than the best authenticated source. It's better to avoid mixing authenticated and unauthenticated NTP sources. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Output from chronyc sources -v
On Wed, Jan 24, 2024 at 12:37:03AM +, Henning Svane wrote: > Hi > > how come all the other server is "not combined". > And also all the other local NTP servers NTP0X are unusable That's not clear from the provided output. What chrony version is it and how is it configured? What do "chronyc selectdata" and "chronyc ntpdata" print? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] No packets transmitted when using Yocto 4.3.1
On Tue, Jan 16, 2024 at 03:09:23PM +0100, Thomas Lange wrote: > On 2024-01-02 12:36, Miroslav Lichvar wrote: > > The cmsg use in chronyd is limited to kernel versions >= 4.8. Maybe we > > should extend that up to the current version for the case when 64-bit > > time_t is used on a 32-bit arch. > > The cmsg problem should now be solved in the following kernel releases: > 6.7, 6.6.11, 6.1.72, 5.15.147, 5.10.208 and 5.4.267. > > It may take some time for the fix to trickle down to all embedded trees > but IMHO, Chrony should not need to add this workaround. Ok, thanks for the information. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Nanosecond precision with refclock SOCK
On Mon, Jan 15, 2024 at 08:56:41PM +0700, James Clark wrote: > There are three successive cases around a positive leap second: > > - the true time is before the start of the leap: in this case the > difference in the POSIX system times will be 3 > - the true time is after the leap has finished but system time is before > the leap: in this case the difference in the POSIX times will be 2 (because > 1 second of the difference is a leap second and so ignored) > - the system time is after the leap is finished: in this case the > difference will again be 3 > > Are you saying that chrony expects the offset to jump around like this > (even though there is no change in the amount by which the clock needs to > be corrected)? It will ignore the 2-second offset because it's in that 10-second interval around the leap. If the offset was larger than 10/11 seconds and the clock couldn't be corrected by step, it would get the one-second error in measurements accepted before getting close to the leap. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Nanosecond precision with refclock SOCK
On Mon, Jan 15, 2024 at 06:57:48PM +0700, James Clark wrote: > In computing the initial step, how does chrony handle leap seconds? > > There are two ways of computing offsets: > - subtracting the TAI times (so that it is really the number of seconds > that elapse between the system time and the true time) > - subtracting the POSIX times (so leap seconds are ignored) chronyd corrects the system clock, which ignores leap seconds, so it expects the second approach. It doesn't do any corrections of the offset. > > The leap should be set until the leap happens, starting up to 24 hours > > before. > > > > What does "until the leap happens" mean exactly? Does that mean that adding > the offset to the system time gives a time that is < 24:00:00 on the day of > the leap second (i.e. the leap second is over)? Or is it until the leap > second starts? Until the leap is finished from the point of the reference clock, i.e. the leap bit should be cleared after when the day changes in the reference time (UTC). In practice, it doesn't have to be so exact. chronyd ignores any measurements made in or pointing to a 10-second interval around the leap. At 23:59:55 it stops updating the clock and coasts through. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Nanosecond precision with refclock SOCK
On Mon, Jan 15, 2024 at 06:09:53PM +0700, James Clark wrote: > Oh, I see. So chrony is using the offset directly? I had misunderstood: I > assumed it was computing the true time by adding the offset to the system > time, and then using the true time. It all makes sense now. Yes, chrony for the most part doesn't care what time it is, but rather how much it is ahead or behind. > the actual system time). But the offset will be wrong by a small number of > seconds if the system clock is so far in the past that leap seconds other > than the latest one intervened: I don't think that matters. That will cause an error in the initial step of the clock and it will take longer to stabilize. The sample time in the SOCK needs to be in the system time (UTC), otherwise it will be rejected as invalid. > I compute the leap flags based on the true time: if the true time occurs on > a day that ends with a leap second, then I set the leap flags. Or should I > be setting them if the true time is some number of hours before the end of > the day that ends with a leap second? The leap should be set until the leap happens, starting up to 24 hours before. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Nanosecond precision with refclock SOCK
On Mon, Jan 15, 2024 at 01:05:32PM +0700, James Clark wrote: > I have implemented refclock SOCK for a project I'm working on. In my case, > I am getting samples from a PHC, so I have a system time with nanosecond > precision (from PTP_SYS_OFFSET*). But refclock SOCK uses struct timeval, > which is in microseconds. I looked at the refclock_sock servo in linuxptp > 4.x, and that just discards away the fraction of the microsecond. But > that's not very satisfying and makes chronyc give misleading information > about the accuracy of the offset. The resolution of the timestamp is not very important. Milliseconds would be still fine. It is not used for calculating the offset. The offset is provided directly as a floating-point value in the SOCK message. This is different from the SHM refclock, where the offset needs to be calculated by the receiver as a difference between two timestamps and where an extension was required to improve the resolution to nanoseconds. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: 答复: [chrony-users] ntptime returned error 5
On Wed, Jan 03, 2024 at 07:51:13AM +, chengyechun wrote: > Thank you for your reply. > After the chrony functions as the client, the ntptime still fails in some > environments. The possible causes are as follows: > Client configuration: > server 192.168.2.159 key 1 iburst > driftfile /var/lib/chrony/drift > logdir /var/log/chrony > allow all > log measurements statistics tracking rtc refclocks tempcomp > keyfile /etc/chrony.keys > commandkey 1 > bindaddress 192.168.2.206 > bindaddress ::1 You need the rtcsync directive for chronyd to mark the system clock as synchronized (which enables the kernel RTC 11-minute mode). -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] ntptime returned error 5
On Wed, Jan 03, 2024 at 02:09:31AM +, chengyechun wrote: > Hi all > If chronyd is used as the local clock source, ntptime does not seem to work > properly, because of chrony's design or what configuration can control? That's expected. chronyd doesn't mark the system clock as synchronized when in the local reference mode. No option to do that currently. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] No packets transmitted when using Yocto 4.3.1
On Tue, Jan 02, 2024 at 11:54:32AM +0100, Thomas Lange wrote: > The root cause is a kernel bug. I have reported it to netdev: > > > https://lore.kernel.org/netdev/a9090be2-ca7c-494c-89cb-49b1db243...@corelatus.se/T/#u > > A proper patch has not been committed yet though, but it seems that my > one-line fix should do it according to comments so far. Interesting. Thanks for looking into it. > AFAICT this bug breaks timestamping via cmsg (i.e. Chrony) for all 32bit > platforms using 64bit time. Yes, it seems so. I can reproduce it on OpenWrt, now that I know what to look for. It doesn't impact all NTP packets. chronyd should not use the cmsg in server basic mode and both client modes unless the acquisitionport directive is used. The cmsg use in chronyd is limited to kernel versions >= 4.8. Maybe we should extend that up to the current version for the case when 64-bit time_t is used on a 32-bit arch. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] No packets transmitted when using Yocto 4.3.1
On Fri, Dec 15, 2023 at 11:46:57AM +0100, Thomas Lange wrote: > Hi, > when I cross compile Chrony for a 32bit ARM system using Yocto 4.3.1, no NTP > packets are transmitted. > > cmsg_type is set to SO_TIMESTAMPING_NEW. > This is rejected by __sock_cmsg_send() in net/core/sock.c and no packet > is transmitted: > Before I dig deeper, I want to check if this is a known issue already? To me that sounds like a mismatch between installed kernel headers and the kernel that actually runs the executable. I don't have much experience with embedded systems. On 32-bit OpenWrt I didn't see any issues. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] DNS/DKIM issue with tuxfamily.org?
On Tue, Dec 12, 2023 at 01:50:17PM +, Joe Smith wrote: > Emails that I receive from tuxfamily.org for this group are being blocked by > my organization, reportedly for security because of a failed DKIM lookup. My > sysadmin indicated that the DKIM in DNS would need to be fixed. I tried > sending an email to the tuxfamily.org admin a while back but got no response. > I probably won't receive the responses to this if you respond to the group. > Perhaps you can reply to me directly. I do apologize for this being off > topic. I'd like to continue receiving these emails but can't if this DKIM > issue isn't addressed. If any of you are able to look into this, it would be > greatly appreciated. Thanks. Happy Holidays! I think this was discussed before here. If tuxfamily is not willing to fix it, there is not much we can do. The mailing lists are unreliable. Some users get only some mails. It's a general problem with mail. Spam broke it. If there was a better provider for mailing lists for open source projects, we could move. I'm not aware of any. I'm not interested in running our own mail server. We can also give up and switch all communication to web on gitlab. I suspect many users wouldn't like that and the small community we have here would be lost. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] How to Delay Chrony Start Until After PPS Device Attached
On Sat, Dec 09, 2023 at 06:16:11AM -0500, Kevin P. Fleming wrote: > Can you define what you mean by 'ready'? If you mean the relevant /dev/pps* > path doesn't yet exist, then you can use 'systemctl edit chrony.service' to > add an 'After' dependency on your `pps_setup@.service`, and systemd will > wait to start Chrony until after the other service has been started (and if > it's a one-shot service as it probably should be, systemd will actually wait > until that service has been *completed*). It's also possible to add a direct dependency on a device created by udev, see: https://procomputers.discourse.group/t/chronyd-service-randomly-fails-to-start-during-boot/22 -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-users] chrony-4.5 released
The final release of chrony-4.5 is now available. The source code is available here: https://chrony-project.org/releases/chrony-4.5.tar.gz SHA256 sum: 19fe1d9f4664d445a69a96c71e8fdb60bcd8df24c73d1386e02287f7366ad422 Since 4.5-pre1, it has only minor improvements in logging of selection loss and documentation. -- Miroslav Lichvar signature.asc Description: PGP signature
Re: [chrony-users] Trouble running chronyd on old hardware
On Mon, Dec 04, 2023 at 08:47:21PM +0800, Ahmed Habub wrote: > 2023-11-29T10:01:22Z D:socket.c:794:(log_message) Sent message fd=6 len=48 > 2023-11-29T10:01:22Z D:socket.c:733:(handle_recv_error) Could not receive > message fd=6 : Function not implemented The kernel might be missing recvmmsg(). Try removing HAVE_RECVMMSG from config.h and rebuild. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Does chrony have an IPC API to supply pps time for non standard GPS time source?
On Sun, Dec 03, 2023 at 07:19:43PM +, Whelan, Andy wrote: > We would like to know if there are available IPC APIs (whether socket, > message queue, or shared memory) to feed a chrony server time information. There is the SOCK refclock for that. Here are some examples: https://gitlab.com/gpsd/gpsd/-/blob/master/gpsd/timehint.c?ref_type=heads#L324 https://github.com/mlichvar/ntp-refclock/blob/master/sock.c -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Per-source address family preference
On Tue, Nov 28, 2023 at 08:12:29PM -0500, Rob Foehl wrote: > I'm looking for a way to limit the address family used for a given > source specified by name, e.g. something like > > pool 2.pool.ntp.org maxsources 2 [inet6/ipv6_only_please] > That's not currently possible. In my todo list I have an item to add the -4/-6 option to the pool/server/peer directive similarly to ntpd. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Need help to understand chrony results
On Tue, Nov 28, 2023 at 03:10:24PM +0100, eric.le_co...@ensta-bretagne.fr wrote: > Ok, so i understand in my bad english it is normal 😊 > > Juste a second question : so i have two NTP server with chrony in my network. > What is the best practize do you think : > Set for the two servers the same prefer external server ? > OR > Have two different prefer server ? I guess that depends on your requirements. In a typical configuration you wouldn't use "prefer" at all. If you needed the two servers to stay close to each other, you would configure them with the same set of NTP servers. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Need help to understand chrony results
On Tue, Nov 28, 2023 at 01:36:54PM +0100, eric.le_co...@ensta-bretagne.fr wrote: > I don't understand because when i pass the command chronyc tracking, i have > different results between the 2 servers in 'ref time (UTC)'. If i launch the > command in the same time on the two servers : > > > > Server one : Ref time (UTC) : Tue Nov 28 12:32:43 2023 > > Server two : Ref time (UTC) : Tue Nov 28 12:33:00 2023 > > > > Sometimes the differents is more than 10 minutes. How to understand this ? It's not the current time. It's the last update of the clock, which is made when a new measurement is accepted from the source having '*' in "chronyc sources". Even if you start the servers at the same time, they will not be sending requests at the same time as the polling intervals have small random adjustments, so the times cannot be expected to be the same. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Problem when removing all sources
On Thu, Nov 23, 2023 at 06:16:32PM +0100, Thomas Lange wrote: > TL> Thanks, I like consistency. I reran my tests using 4.5-pre1 and my test > case > TL> seems to work now. > I may have jumped the gun a bit. When retesting the original test case > (where all sources are dropped) using 4.5-pre1 once again, I don't get the > "Can't synchronise: no selectable sources" message. > I've retried many times. There are some transient states in the selection which don't have a log message. I reworked the logging the cover those. Please try it again with the latest code in git. > AFAIK nothing has changed in my setup, so I can't explain why it worked > this morning but not now. Maybe one of the sources was unreachable and synchronized to a more distant source, which changed the selection sequence during the removal and took a different path in the logging. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-users] chrony-4.5-pre1 released
The first prerelease for chrony-4.5 is now available. The source code is available here: https://chrony-project.org/releases/chrony-4.5-pre1.tar.gz SHA256 sum: 4bc29f51ee0b4d781c9fcdaa7843fd9465bb8e682d90b5ea20c2f515bdc55c23 Notable changes since 4.4: Enhancements * Add support for AES-GCM-SIV in GnuTLS * Add support for corrections from PTP transparent clocks * Add support for systemd socket activation Bug fixes - * Fix presend in interleaved mode * Fix reloading of modified sources from sourcedir * Request nanosecond kernel RX timestamping on FreeBSD * Fix selectopts +noselect command -- Miroslav Lichvar signature.asc Description: PGP signature
Re: [chrony-users] Problem when removing all sources
On Mon, Nov 20, 2023 at 04:17:47PM +0100, Miroslav Lichvar wrote: > On Mon, Nov 20, 2023 at 11:14:00AM +0100, Thomas Lange wrote: > > > > > > 2023-11-19T17:43:20Z Removed source 103.242.68.69 > > 2023-11-19T17:43:20Z Removed source 162.159.200.123 > > 2023-11-19T17:43:20Z Removed source 194.58.202.148 > > 2023-11-19T17:43:20Z Selected source 194.58.206.20 > > 2023-11-19T17:43:20Z Removed source 194.58.206.20 > > 2023-11-19T17:43:20Z Removed source 217.75.106.216 > > 2023-11-19T17:43:20Z Removed source 91.209.0.17 > > > > > > It depends on the order of removed sources and the reselection that > can happen. > > The message is logged only when a source is already selected and > newly executed source selection doesn't find a selectable source. > In your example the last selected source is 194.58.206.20. It is > removed, i.e. nothing is selected, and with the two remaining sources > there is no successful selection. The issue actually was in the removal of the source. If it was reselected due to becoming offline, the log message was logged. If it was kept selected even as offline (due to other sources not being better), it would not be logged. The latest development code now has a fix to make it consistent. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Problem when removing all sources
On Mon, Nov 20, 2023 at 11:14:00AM +0100, Thomas Lange wrote: > > > 2023-11-19T17:43:20Z Removed source 103.242.68.69 > 2023-11-19T17:43:20Z Removed source 162.159.200.123 > 2023-11-19T17:43:20Z Removed source 194.58.202.148 > 2023-11-19T17:43:20Z Selected source 194.58.206.20 > 2023-11-19T17:43:20Z Removed source 194.58.206.20 > 2023-11-19T17:43:20Z Removed source 217.75.106.216 > 2023-11-19T17:43:20Z Removed source 91.209.0.17 > > It depends on the order of removed sources and the reselection that can happen. The message is logged only when a source is already selected and newly executed source selection doesn't find a selectable source. In your example the last selected source is 194.58.206.20. It is removed, i.e. nothing is selected, and with the two remaining sources there is no successful selection. When chronyd is shutting down, the selected source is removed as last to avoid unnecessary reselections. Maybe the same thing could be done with sourcedir. I'll see how much complexity that would be. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] NTP to Chrony migration issue with NTP authentication with symmetric keys
On Mon, Nov 06, 2023 at 10:55:12AM -0600, Michael Krell wrote: > I've modified the value in the chrony.keys file to include "HEX:"; > retesting "chronyd -dd", now the output does not show the > "(NCR_ProcessRxUnknown)" log message. There is still a "Receive timeout" An occasional receive timeout could be due to the rate limiting enabled on the server (restrict kod limited). Do you see any valid packets received in ntpdata? Which NTP tests are failing? If not, please capture an exchange with tcpdump and post the output here. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] NTP to Chrony migration issue with NTP authentication with symmetric keys
On Mon, Nov 06, 2023 at 09:00:18AM -0600, Michael Krell wrote: > Our implementation currently uses ASCII keys, and follows the 'optional' > usage for ASCII (Per the man page for chrony.conf : " The key can be > specified as a string of ASCII characters not containing white space with > an optional *ASCII:* prefix, or...". > /etc/chrony.keys : > > 20 SHA1421b67770525bde2e926354a88ae2f81c7c76108 > /etc/ntp.keys: > > 20 SHA1 421b67770525bde2e926354a88ae2f81c7c76108 #RSA-SHA1-compliant This is not an ASCII key. ntpd interprets keys longer than 20 characters as hexadecimal values, so you need to add HEX: to the key in chrony.keys. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] NTP to Chrony migration issue with NTP authentication with symmetric keys
On Fri, Nov 03, 2023 at 02:35:21PM -0500, Michael Krell wrote: > I'm raising this issue because, with that same Chrony configuration on > our product, we actually have another test passing - we have stood up a > separate Chrony server with the same key and Chrony configuration and it > can sync time via the symmetric key authentication just fine. The problem > we're having is with backwards compatibility to NTP itself. Since we are > mandated to be backwards compatible with NTP, we would like to see if this > is something new. The issue likely is in the key specification (ASCII vs HEX) or truncated vs untruncated digest with length over 160 bits, which requires "version 4" in the chrony config as explained in the man page. Please post sample configs and key files for both ntpd and chrony. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Support for PTP transparent clocks
On Tue, Sep 26, 2023 at 04:43:28PM +0200, Miroslav Lichvar wrote: > Here is a list of switches with the required PTP support I received > from FS.COM. If you can test some of these switches or any other > switches claiming one-step E2E unicast TC support from other vendors, > please let us know. > > IES3100-8TF IES3100-8TF-P > IES3110-24TF IES3110-8M12 > IES3110-8TF IES3110-8TF-P IES3110-8TF-R IES3110-8TFM-P IES3110-8TFP-R > IES5100-24TS-P > S5800-48F4SR S5800-48F4SR-DC S5800-48F4SR-PE > S5850-24S2C S5850-24S2C-DC S5850-24S2C-PE > S5850-48B8C S5850-48B8C-DC S5850-48B8C-PE > S5850-48S8C S5850-48S8C-DC S5850-48S8C-PE > S8550-32C S8550-32C-DC S8550-32C-PE > S5850-48S6Q-R S5850-48S6Q-R-DC S5850-48S6Q-R-PE (MA license required) Some additions to the list. I was able to test the feature on a Juniper QFX5200 switch and it worked well. I asked Arista and Juniper for a list of switches and routers with the required support. This is what they sent me: Arista: 7010TX 7020R 7050X 7050X2 7050X3 7060X 7060X2 7060X4 7150 720XP 722XPM 720DP-24S 720DT-24S 720DP-48S 720DT-48S 7280R 7250X 7280R2 7260X3 7280R3 7280E 7280R3A 7300X 7300X3 7320X 7368 7500R2 7500R 7500E 7500R3 750XP 7800R3 Juniper: ACX710 ACX5448-D ACX5448-M ACX5448 QFX5110 QFX5120-48T QFX5120-48YM QFX5200 PTX10001-36MR (IPv6 only) -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] NTP signd socket status logging enhancement
On Thu, Oct 05, 2023 at 11:01:45AM -0400, Jeremy Jackson wrote: > Perhaps gentler wording would be appropriate? If not, I guess sysadmin could > infer the same thing from the lack of a connection success message. I guess > I could also filter out the case of an existing unix socket, with proper > permissions, that just isn't accepting connections, from all the other error > conditions, that aren't dependent on state of Samba running or not. I'd suggest to only log errors, not successes, and only once between successful connections. > I suppose if Samba failing and recovering quickly being the cause of log > flooding is a concern, a rate limit could be set? But it seems like there > are bigger problems if that is the case. Fair enough. > The general principle I'm aiming for, is that problems due to samba not > running, permission errors, config file errors, should be made obvious, and > shouldn't require tcpdump, debug logs, reading source code, and other low > level approaches. Yes, that makes sense to me. > Stil, it's pretty nice to have a working NTP that requires zero config for > Windows clients. I hope they will start using NTS and this signd hack can be dropped eventually. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Clarification on certain fields in chronyc subcommands
On Thu, Oct 12, 2023 at 02:58:52AM +0530, Abhijith Sethuraj wrote: > Hello, > > I'm trying to understand what "estimated error" means in the context of > `chronyc sources -v`. For example, we see `-308ns[ -582ns] +/- 17us` for > one of our sources. Does that mean that even though our recent offsets have > been in the order of ns, the actual error is close to microseconds? It's the NTP root distance. It estimates maximum error assuming the extreme asymmetry in network delay where one direction has no delay and the opposite direction has the whole of measured network delay. > Secondly, `chronyc sourcestats` says that our offset for a particular > source is always in the order of ns. Is that based on the offset between > the system clock and stratum-1 clock (thereby, including root dispersion > and root delay), or, between the system clock and the last sample that we > got back from our NTP server? More of the latter. It's the offset of the system clock to the local estimate of the remote source. If it's the only selected source (no combining), it should be close to zero. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] NTP signd socket status logging enhancement
On Wed, Oct 04, 2023 at 08:42:10AM -0400, Jeremy Jackson wrote: > https://gitlab.com/chrony/chrony/-/merge_requests/3 > > I spent longer than I should have troubleshooting a typo in a config file, so > I thought I'd contribute a logging enhancement that could save others > (including my future self, heh) some time. > > Transitions in status of running Samba AD process are also reflected in log > messages. I think that reported error in the initial connection could be confusing to users as chronyd is normally not ordered in the boot after samba and would likely be failing. Requests from clients shouldn't be able to trigger an informational log message to avoid flooding the syslog. There already is an error reported for failed connect as a debug message. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Best/proper use of orphan mode
On Fri, Sep 29, 2023 at 09:00:58AM +, Carsten Finis wrote: > > It's supposed to end up in a stable state using only one source, but > > it might take a long time. You can speed it up by increasing > > maxclockerror and reducing the orphan distance. > > > > If that doesn't work for you, please post output from chronyc sources > > and selectdata. > > Here's the situation 24 hours after losing the connection to the external NTP > server. Host 1 doesn't want to let loose of that server. > Indeed, that is a stable configuration (if it stays like this), but the > actual orphan feature hasn't kicked in - no orphan stratum anywhere. If you don't decrease the orphan distance and/or increase the clock error rate, and the estimated skew (as reported in sourcestats) is small enough, it would take up to 1 million seconds ~ 11 days (default distance divided by maxclockerror) to activate the orphan mode. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Best/proper use of orphan mode
On Wed, Sep 27, 2023 at 10:25:43AM +, Carsten Finis wrote:
> The first host on which the external server becomes stale then switches to
> one of the other internal hosts, and so do the others. It takes half a day
> before the first host appears as orphan ("O" in the output of "chronyc
> selectdata"), and I have not managed to have all three hosts appear as
> orphans and agree on one of them as server. Usually, I end up with a cyclic
> constellation.
It's supposed to end up in a stable state using only one source, but
it might take a long time. You can speed it up by increasing
maxclockerror and reducing the orphan distance.
If that doesn't work for you, please post output from chronyc sources
and selectdata.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] confirm unsubscribe f435f42b8a8d6dc4100a056f09213260
On Tue, Sep 26, 2023 at 01:52:56PM -0400, Craig Smith wrote: > -- Forwarded message - > From: > Date: Mon, Sep 25, 2023 at 2:48 PM > Subject: [chrony-users] confirm unsubscribe f435f42b8a8d6dc4100a056f09213260 > To: The confirmation email needs to be sent to the same address as the original request (chrony-users-requ...@chrony.tuxfamily.org), not the mailing list. The email has a Reply-To header. If you hit reply in your client it will go to the right address. I will remove you from the list shortly. No need to send another request. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-users] Support for PTP transparent clocks
The latest code in git now supports PTP corrections provided by one-step end-to-end unicast transparent clocks. It should allow chronyd to reach the same or possibly even better performance as a typical PTP client with full on-path PTP support. The server needs to have HW timestamping and NTP-over-PTP enabled: hwtimestamp * ptpport 319 and the client also needs to enable the new extension field F324: hwtimestamp * ptpport 319 server a.b.c.d port 319 xleave minpoll 0 maxpoll 0 extfield F323 extfield F324 If you compile chronyd with the --enable-debug option and start it with "-d -d", you can check for these messages: ntp_io.c:536:(NIO_UnwrapMessage) Unwrapped PTP->NTP len=104 corr=0.03016 ntp_core.c:1708:(apply_net_correction) Applied correction rx=0.04600 tx=0.04848 dur=0.01584 If the reported correction in the first message is nonzero, there are working PTP transparent clocks between the client and server. In my tests it works well with the IES3110-8TF-R switch. Thanks to James for recommending it. Here is a list of switches with the required PTP support I received from FS.COM. If you can test some of these switches or any other switches claiming one-step E2E unicast TC support from other vendors, please let us know. IES3100-8TF IES3100-8TF-P IES3110-24TF IES3110-8M12 IES3110-8TF IES3110-8TF-P IES3110-8TF-R IES3110-8TFM-P IES3110-8TFP-R IES5100-24TS-P S5800-48F4SR S5800-48F4SR-DC S5800-48F4SR-PE S5850-24S2C S5850-24S2C-DC S5850-24S2C-PE S5850-48B8C S5850-48B8C-DC S5850-48B8C-PE S5850-48S8C S5850-48S8C-DC S5850-48S8C-PE S8550-32C S8550-32C-DC S8550-32C-PE S5850-48S6Q-R S5850-48S6Q-R-DC S5850-48S6Q-R-PE (MA license required) -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Question about Chrony's metrics
On Mon, Sep 25, 2023 at 04:27:13PM +0900, Semyon Galichenko wrote: > Hi all, > > I have Chrony configured with 2 sources like so: > ``` > server 192.168.10.1 prefer iburst > server 192.168.10.2 noselect > ``` > The server should be synchronized only with the first source and just > monitor the second one (hence `noselect` option). > I want to be sure that the time set on the server has no more than 1 > second difference with the time obtained from both sources. > > What would be the right way to do it with Chrony? What metric can be > used to check such a time drift? You would need to monitor the offset of the second source reported in the statistics log (enabled by logdir + log statistics in chrony.conf) or periodically check the output of the "chronyc sources" command. If you remove the noselect option and let chronyd use both sources, chronyd will do that for you. It will log a "no majority" error message when the sources don't agree with each other. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Specifying refclock accuracy
On Thu, Sep 21, 2023 at 10:07:00AM +0700, James Clark wrote: > I'm seeing occasional kernel messages (in version 6.1.52): > > igc :05:00.0 enp5s0: Timeout reading IGC_PTM_STAT register > > Is that something I should report upstream somewhere? Searching for that meassage gives me only links to the source code, no other report of getting that message, so I'd say yes, please report it on the intel-wired-lan list. Thanks, -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Specifying refclock accuracy
On Wed, Sep 20, 2023 at 01:53:54PM +0700, James Clark wrote: > I'm a bit unclear about how a refclock is supposed to specify how > accurate it is. There are the delay and precision options. I think I > understand what the docs say about delay. But I'm less clear about > precision. What are the semantics of that, how does it impact what > chrony does and how is it related to delay? Precision sets the expected consistency in reading of the reference clock, e.g. due to resolution. It's mainly used in PHC tracking (refclock and HW timestamping) as the expected noise floor. The default and minimum accepted value is the estimated system clock precision (how much it takes to read) or the value set by the clockprecision directive. > The other thing I'm not > clear about is how the precision and delay relate to the figure shown > for the margin of error (after +/- in the last column of the chrony > sources output). The +/- value is the NTP root distance, which contains half of the root delay and whole root dispersion, which includes the precision. > As a concrete example, for a PHC extpps source (with no link to > anything) connected to the PPS output of a GPS whose datasheet > specifies a 30ns RMS accuracy, what should I specify for delay and > precision and how do I get a sensible figure for margin of error? I've > tried various figures in the range 10ns-100ns for delay and precision, > but the margin of error remains in the 700ns-800ns range. The margin > of error figure is similar to the dispersion figure in the refclocks > log, so I'm guessing that's the main cause. Why is the dispersion so > large and is there anything that can be done to fix it? It contains half of the delay in reading of the PHC, mostly coming from the PCIe delay. The only way to avoid that is cross timestamping (e.g. PTM). The refclock precision should be set to the expected stability of PHC readings. With the I210 and CPU running at a constant frequency that might be around 20ns. The delay can be set to 60ns corresponding to the 30ns accuracy of the GPS receiver. > At the other end of the scale, for a SOCK refclock for GPS messages > where there's say 0.1s variation in the time the message is received, > what is the right thing to put in refclock so that chrony won't treat > it as a false ticker? Would it be delay 0.2? Is precision relevant > here? Yes, 0.2 assuming the offset is set to the middle of that interval. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] 'reload sources' fails when maxpoll is decreased
On Mon, Sep 11, 2023 at 11:39:08AM +0200, Thomas Lange wrote: > Hi, > 'reload sources' fails if the maxpoll value is decreased for an existing > source. > Running 'reload sources' a second time seems to readd the source. Thanks for the report. I can reproduce the bug. It can happen for sources specified by IP address. If the parameters change so that they are ordered before the original source, chronyd will try to add the new source before removing the old one, which doesn't work as there can be only one source with the same IP address. I think it will need to be split into two phases, first removing sources and second adding sources. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Leveraging PTM
On Thu, Sep 07, 2023 at 10:49:50AM +0700, James Clark wrote: > I'm curious about how well this works when there are multiple switches > between server/client. I've got two slightly different variants of this > switch, so I could potentially test this. Not exactly the same thing, but I simulated 4 switches by splitting the single switch into 4 VLANs and daisy chaining the 4 pairs of ports. The jitter observed by chrony doubled when not using the PTP correction, but there was no change at all when using the correction. It still seems symmetric and jitter of only about 10 ns, which I think mostly comes from the I210 resolution (125MHz clock). Here are some plots: https://i.imgur.com/O9FngmX.png I'd be curious to see some tests with PTM. I also tested the switch with PTP in the other supported modes. There are some issues: - 2-step E2E and both 1-step and 2-step P2P transparent clocks insert a VLAN tag to the sync/follow up messages if using UDP transport, which completely breaks synchronization. L2 transport works ok. - Boundary clock doesn't lock. It's constantly switching between FREQ_LOCKING and PHASE_LOCKING states. I tried changing the PID constants to few different values, but that didn't seem to help. - Boundary clock doesn't adopt grandmaster identity from its master. Maybe that happens only when it locks. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Rising/falling edge detection
On Thu, Sep 07, 2023 at 05:15:10PM +0700, James Clark wrote: > Note that it reduces the maximum allowed error of the time source which > > completes the PPS > > samples. If the duty cycle is configurable, 50% should be preferred in > > order to maximise the allowed error. > > > I don't understand this. I would have thought 50% was the worst possible > configuration because it prevents the use of the time between pulses being > used to identify which is the rising edge. The explanation is that the code doesn't care about the interval between edges. In only checks how well each pulse aligns with the last sample from the locked refclock. An advantage of this approach is that it works even when only one edge is reported, so existing configuration won't break if the hw/driver suddently starts filtering the unexpected edges, and I think it's also more resilienty to spurious pulses. Maybe an alternative filtering could be implemented for the extreme widths. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Leveraging PTM
On Mon, Sep 04, 2023 at 10:29:28AM +0200, Miroslav Lichvar wrote:
> On Mon, Sep 04, 2023 at 01:34:48PM +0700, James Clark wrote:
> > The IES3110-8TF-R web UI has some configuration options that suggest it
> > supports unicast. See attached screenshot. I haven't experimented with it.
> > It also has option to select one-step vs two-step, but I haven't
> > experimented with that either.
>
> That sounds promising. I'll order one and test it. It would be amazing
> if this switch could do what 100x more expensive switches cannot.
Ok, I got the switch and I can confirm it modifies the correction
field in NTP-over-PTP messages as a one-step transparent clock.
I did a quick test with two I210 NICs in a single machine connected to
the switch. I tried few different pairs of ports. With the worst one
and unmodified chronyd I see an asymmetry of about 25 ns and jitter of
about 140 ns. When I apply the PTP correction the asymmetry disappears
and jitter drops to 10 ns.
Here is a plot of the raw offset from the measurements log:
https://i.imgur.com/S6iywgH.png
I'm attaching the patch if you want to test it. It's a quick hack.
I think there will need to be a new extension field to provide the
correction of the request to the client to allow it to perform some
sanity checks and also some way to correct for asymmetric link speeds.
If anyone knows about other switches which can do this, please let me
know. I'll mention them in the NTP-over-PTP draft. I think this will
be a very nice improvement.
--
Miroslav Lichvar
commit 583ff7655615a3394871c61aae4351b633ec5906
Author: Miroslav Lichvar
Date: Wed Sep 6 16:31:56 2023 +0200
POC: ntp: apply PTP correction from delay requests
diff --git a/ntp_io.c b/ntp_io.c
index fce7b177..1cc7532d 100644
--- a/ntp_io.c
+++ b/ntp_io.c
@@ -428,6 +428,7 @@ process_message(SCK_Message *message, int sock_fd, int
event)
NTP_Local_Address local_addr;
NTP_Local_Timestamp local_ts;
struct timespec sched_ts;
+ double correction;
SCH_GetLastEventTime(&local_ts.ts, &local_ts.err, NULL);
local_ts.source = NTP_TS_DAEMON;
@@ -456,9 +457,14 @@ process_message(SCK_Message *message, int sock_fd, int
event)
DEBUG_LOG("Updated RX timestamp delay=%.9f tss=%u",
UTI_DiffTimespecsToDouble(&sched_ts, &local_ts.ts),
local_ts.source);
- if (!NIO_UnwrapMessage(message, sock_fd))
+ if (!NIO_UnwrapMessage(message, sock_fd, &correction))
return;
+ if (correction > 0.0 && correction < 1e-3) {
+UTI_AddDoubleToTimespec(&local_ts.ts, -correction, &local_ts.ts);
+DEBUG_LOG("Applied PTP correction %.9f", correction);
+ }
+
/* Just ignore the packet if it's not of a recognized length */
if (message->length < NTP_HEADER_LENGTH || message->length > sizeof
(NTP_Packet)) {
DEBUG_LOG("Unexpected length");
@@ -495,10 +501,12 @@ read_from_socket(int sock_fd, int event, void *anything)
/* == */
int
-NIO_UnwrapMessage(SCK_Message *message, int sock_fd)
+NIO_UnwrapMessage(SCK_Message *message, int sock_fd, double *correction)
{
PTP_NtpMessage *msg;
+ *correction = 0.0;
+
if (!is_ptp_socket(sock_fd))
return 1;
@@ -522,6 +530,8 @@ NIO_UnwrapMessage(SCK_Message *message, int sock_fd)
message->data = (char *)message->data + PTP_NTP_PREFIX_LENGTH;
message->length -= PTP_NTP_PREFIX_LENGTH;
+ *correction = (UTI_Integer64NetworkToHost(*(Integer64
*)msg->header.correction) >> 16) / 1e9;
+
DEBUG_LOG("Unwrapped PTP->NTP len=%d", message->length);
return 1;
diff --git a/ntp_io.h b/ntp_io.h
index 427bd966..dafcde06 100644
--- a/ntp_io.h
+++ b/ntp_io.h
@@ -64,7 +64,7 @@ extern int NIO_IsServerSocketOpen(void);
extern int NIO_IsServerConnectable(NTP_Remote_Address *remote_addr);
/* Function to unwrap an NTP message from non-native transport (e.g. PTP) */
-extern int NIO_UnwrapMessage(SCK_Message *message, int sock_fd);
+extern int NIO_UnwrapMessage(SCK_Message *message, int sock_fd, double
*correction);
/* Function to transmit a packet */
extern int NIO_SendPacket(NTP_Packet *packet, NTP_Remote_Address *remote_addr,
diff --git a/ntp_io_linux.c b/ntp_io_linux.c
index 8f93f599..2a8cc46e 100644
--- a/ntp_io_linux.c
+++ b/ntp_io_linux.c
@@ -783,7 +783,8 @@ NIO_Linux_ProcessMessage(SCK_Message *message,
NTP_Local_Address *local_addr,
return 1;
}
- if (!NIO_UnwrapMessage(message, local_addr->sock_fd))
+ double c;
+ if (!NIO_UnwrapMessage(message, local_addr->sock_fd, &c))
return 1;
if (message->length < NTP_HEADER_LENGTH || message->length > sizeof
(NTP_Packet))
Re: [chrony-users] Chrony on CM4
On Tue, Sep 05, 2023 at 08:00:56AM +0700, James Clark wrote: > I get a similar mixture of HW/Kernel timestamping: 2382 K H, 33 H H, 5 > K K, 0 H K. Ok, I think that rules out the conflict between RX and TX timestamping. I'm not sure what else it could be. It would be great if someone with better understanding of the HW and driver could have a look at it. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony on CM4
On Mon, Sep 04, 2023 at 09:27:22PM +0700, James Clark wrote: > On Mon, Sep 4, 2023 at 9:12 PM Miroslav Lichvar wrote: > > > > > To confirm that, you could configure the client to use a distant public > > NTP server to give the client more time to get its TX timestamp and > > see if the success rate of HW timestamping improves. > > > > I think I'm misunderstanding something. Wouldn't this need a distant public > server that supported NTP-over-PTP? Do such things exist? Oh, right. You can try it with one of my servers - 51.68.44.27 in France. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony on CM4
On Mon, Sep 04, 2023 at 04:11:47PM +0200, Miroslav Lichvar wrote: > > Hardware Receive Filter Modes: > > none > > ptpv2-l4-event > > ptpv2-l2-event > > ptpv2-event > > That looks ok. I'm not sure why it doesn't work. Maybe it's limited to multicast. I've seen a Broadcom NIC doing that. Does ptp4l work in unicast mode on this NIC? Looking at the driver, it seems the timestamping filters are configured in software. I'm wondering if it could support an NTP filter. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony on CM4
On Mon, Sep 04, 2023 at 08:03:45PM +0700, James Clark wrote: > On Mon, Sep 4, 2023 at 6:51 PM Miroslav Lichvar wrote: > > Is the server running on CM4? > > Yes. > > Can you please enable the measurements log and see if all TX > > timestamps are kernel or there is a mix of kernel and hardware? > > It's a mixture: 848 "K H"; 22 "K K"; 13 "H H". I think there might be a problem with TX timestamping being interrupted by RX timestamping. Server receives first, transmits later. Client transmits first and might receive the server's response before the HW/driver is done with the TX timestamp. To confirm that, you could configure the client to use a distant public NTP server to give the client more time to get its TX timestamp and see if the success rate of HW timestamping improves. > Time stamping parameters for enp1s0: > Capabilities: > hardware-transmit > software-transmit > hardware-receive > software-receive > software-system-clock > hardware-raw-clock > PTP Hardware Clock: 3 > Hardware Transmit Timestamp Modes: > off > on > Hardware Receive Filter Modes: > none > ptpv2-l4-event > ptpv2-l2-event > ptpv2-event That looks ok. I'm not sure why it doesn't work. On Mon, Sep 04, 2023 at 08:12:12PM +0700, James Clark wrote: > I think it's going to be easier to figure out the problem if we have one > side that is known to work. Is NTP-over-PTP known to work on Intel NICs > like i210/i225/i226? If so, then tomorrow I'll try with one side as Intel > NIC and one as CM4. Those NICs timestamp all received packets and don't care about NTP-over-PTP. I don't think it will make a difference for the other side on CM4. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony on CM4
On Mon, Sep 04, 2023 at 08:23:13PM +0700, James Clark wrote: > On Mon, Sep 4, 2023 at 3:46 PM Miroslav Lichvar wrote: > > > The latest gpsd version supports SOCK for message-based timing data, > > which can replace SHM 0. > > I was using gpsd 3.25 (as included in Fedora 38), which appears to be > the latest version, and SOCK didn't work for me. The latest gpsd should try to connect to two different sockets: /run/chrony.XXX.sock /run/chrony.clk.XXX.sock where XXX is the device name. The first one is for PPS, the second one for message-based timing. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony on CM4
On Mon, Sep 04, 2023 at 06:30:06PM +0700, James Clark wrote: > "chronyc serverstats" looks good: I'm seeing increasing "NTP hardware RX > timestamps" and > "NTP hardware TX timestamps". Is the server running on CM4? > I'm now trying two clients, and I see different results with chronyc > ntpdata: > > - another CM4: here I see RX timestamping : Hardware but TX timestamping : > Kernel Can you please enable the measurements log and see if all TX timestamps are kernel or there is a mix of kernel and hardware? The HW timestamping might be unreliable. You could try increasing hwtstimeout to 1 to wait even longer for the TX timestamp. You could also try adding "minpoll 2" to the hwtimestamp directive to read the clock less frequently to avoid some collisions with the timestamping access. IIRC the HW or driver might have an issue with that. > - an x86 box with the AQC107: here I see TX timestamping : Hardware and RX > timestamping : Hardware > but on the client "chronyc ntpdata" shows Kernel for TX timestamping and RX > timestamping. I have no experience with this NIC. What does ethtool -T show? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chrony on CM4
On Sun, Sep 03, 2023 at 11:52:40AM +0700, James Clark wrote: > On Mon, Aug 21, 2023 at 3:28 PM Miroslav Lichvar wrote: > > > As for the PTP-specific timestamping of the CM4 NIC, I'm interested in > > tests using the NTP-over-PTP transport with the latest chrony version > > (you might need to set hwtstimeout to 0.1 or even longer for the CM4). > > I've written a guide to how to set Fedora and chrony on the CM4 so as > to take advantage of both NTP-over-PTP and PHC extpps: > > https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/fedora.md > https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/chrony.md Thanks for writing that. I don't have a CM4 to verify it. (They still don't seem to be in stock in any of the shops I normally buy from.) There seems to be a copr repo with rpiboot for Fedora, so you could avoid compiling it yourself: https://copr.fedorainfracloud.org/coprs/lsevcik/usbboot/ The latest gpsd version supports SOCK for message-based timing data, which can replace SHM 0. I'd suggest to add "extfield F323" to the client configuration for best performance. > It seems to be working properly: I get no errors and much better > results than with another local chrony server that is not using > hardware timestamping. But how do I tell if the hardware timestamping > is working properly in both directions? On the client, "chronyc ntpdata" should consistently show Hardware for both "TX timestamping" and "RX timestamping". On the server, "chronyc serverstats" should show increasing "NTP hardware RX timestamps" and "NTP hardware TX timestamps". The number of daemon and kernel timestamps should be incrementing only with new/restarted clients and clients not using interleaved mode. > I haven't tried to optimize it yet. The RMS offset on the client seems > to jump around more than I would expect: sometimes around 1us; > sometimes down to a few hundred nanoseconds. Not sure if that is the > switches or the CM4 flakiness or less than optimal configuration. That would indicate software timestamping. With hardware timestamping the offset should be stable to few tens of nanoseconds. > > What would be good tests/measurements to do? Plotting the offset and delay from the measurements log can nicely show how well it performs. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Leveraging PTM
On Mon, Sep 04, 2023 at 01:34:48PM +0700, James Clark wrote: > On Tue, Aug 22, 2023 at 5:58 PM Miroslav Lichvar > wrote: > Currently it doesn't take advantage of PTP support in switches (i.e. > > the correction field). It would have to be a unicast one-step E2E > > transparent clock. Do you know any switches that can do that? > > > > The IES3110-8TF-R web UI has some configuration options that suggest it > supports unicast. See attached screenshot. I haven't experimented with it. > It also has option to select one-step vs two-step, but I haven't > experimented with that either. That sounds promising. I'll order one and test it. It would be amazing if this switch could do what 100x more expensive switches cannot. > The main point of NTP-over-PTP is to enable HW timestamping of NTP > > messages on PTP-only NICs. NTP doesn't need HW support in switches to > > perform well when the network is (moderately) loaded. You can still > > get sub-microsecond accuracy with good (non-PTP) switches if there > > are not too many of them between the server and client. > > > AS you say, it seems to perform well as is. But if it supported transparent > switches, could the accuracy with NTP-over-PTP be as good as PTP? Yes. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] PTP refclock
On Thu, Aug 31, 2023 at 05:29:09PM -0400, Craig Smith wrote: > Can someone explain why Chrony never gets more in sync with the PTP > source no matter how often I poll? How is the PTP clock synchronized? It seems either the PHC or the system clock is unstable. Is there anything else controlling the clock? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Chroy is taking long time detect PPS signal loss
On Thu, Aug 31, 2023 at 08:15:04AM -0700, Jatinder wrote: > Questions: > Why is Chrony taking a long time to detect PPS signal loss? > Is there any way to make that signal loss detection faster? Both questions should be answered here: https://chrony-project.org/faq.html#_an_unreachable_source_is_selected -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Pseudo-pools
On Fri, Aug 25, 2023 at 08:00:21AM -0400, Josef 'Jeff' Sipek wrote: > On Mon, Aug 21, 2023 at 10:34:47 +0200, Miroslav Lichvar wrote: > > I'd suggest to specify it in /etc/hosts. > > I didn't make it clear enough, but A-E above are DNS A records for each of > the servers. So, using /etc/hosts means hardcoding ignoring the individual > server's DNS entries and hardcoding the IPs. Granted these are very > unlikely to ever change. > > Currently I just specify servers A-C in my chrony.conf which is good enough, > but I'll mull over how much I like/dislike hardcoding IPs in /etc/hosts. If there are only 5 servers in total, why not specify them all in the config? If network/server load was a concern, you could increase minpoll and maxpoll by 1 to compensate for it. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Force immediate verification of NTP server status
On Wed, Aug 23, 2023 at 04:32:04PM -0700, Thangalin wrote: > It seems chrony takes non-deterministic time of approximately 1 second to > determine that the NTP server is offline. > > Can we force chronyd to refresh its state immediately, such that upon > returning from the request (or command) the State is guaranteed Selectable > for a valid connection and Nonselectable when severed? Selectable and Nonselectable are only loosly related to reachability. chronyc commands cannot be blocking due to the server side of the protocol being stateless. If you expect responses to all requests (e.g. in local network), I think the best thing can do is to poll ntpdata and wait for "Transmitted messages" to increase by 2 while "Received valid messages" stays the same. Increase by 1 is not sufficient as you could be polling in the middle of the NTP exchange. > Do we need to call something similar to the following: > > chronyc -m 'burst 3/3' 'makestep 0.1 3' makestep shouldn't make a difference for you. burst still has an initial delay of at least 0.2 seconds and it doesn't block, but it should shorten the time needed send two requests. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
