[chrony-users] chronyc tracking question

I'm trying to figure out what metric(s) from `chronyc tracking' I should be logging and graphing to answer the question of "how far off is my system from its reference". I believe the "Last offset" field is the most recent offset that chrony has received from the source that it has selected to

Re: [chrony-users] Root delay and Root dispersion values in `chronyc ntpdata'

On Mon, Jun 26, 2017 at 9:28 AM, Chris Perl <cp...@janestreet.com> wrote: >> The reason why they are always 15 microseconds is that the fields have >> a 32-bit fixed-point format with ~15 microsecond resolution and >> chronyd as a server rounds them up. So, if

Re: [chrony-users] Root delay and Root dispersion values in `chronyc ntpdata'

On Mon, Aug 14, 2017 at 4:09 AM, Miroslav Lichvar wrote: > I think the log should provide all necessary information to avoid > having to run chronyc in a loop. Fwiw, this is basically what I'm doing. -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with

Re: [chrony-users] chronyc tracking question

On Thu, Jul 27, 2017 at 4:57 AM, Miroslav Lichvar <mlich...@redhat.com> wrote: > On Wed, Jul 26, 2017 at 06:15:13PM -0400, Chris Perl wrote: >> I'm pretty sure the interleaving gets messed up and I don't wind up >> getting back the timestamp from the previous exchange (i

Re: [chrony-users] Hardware timestamping in CentOS 7.4 (was: Possible to get sub-millisecond accuracy?)

On Tue, Jun 27, 2017 at 10:24 AM, Miroslav Lichvar wrote: > > This is now in git. Adding "rxfilter none" to the hwtimestamp > directive should allow TX HW timestamping on NICs that support only > a PTP receive filter. > > The copr repo has a fresh build from git if anyone

Re: [chrony-users] Preferring local sources

On Wed, Apr 26, 2017 at 11:02 AM, Miroslav Lichvar wrote: > If the remote servers have root distance larger than combinelimit > times the local root distance, they shouldn't be combined with the > local servers. You would probably need a local stratum-1 server for > this to

Re: [chrony-users] chronyc tracking question

On Thu, Apr 20, 2017 at 5:32 AM, Miroslav Lichvar wrote: > Yes. That's a good description. If you would like to improve the > manual pages, I'll gladly accept patches :). I'll take another read through what is already there and see if I think I can add anything useful. >

Re: [chrony-users] Root delay and Root dispersion values in `chronyc ntpdata'

On Fri, Aug 4, 2017 at 4:30 AM, Miroslav Lichvar wrote: > Do you need this to show compliance with the new MiFID directive? > I think one possibility here might be to reduce root delay on clients > by minimum latency of switches along the path to the server. If a > switch is

[chrony-users] Enabling xleave on clients talking to servers that don't support it

I suspect the answer to this is, "its fine", but I wanted to double check. I'm migrating some time servers from the reference ntp implementation to chrony. The clients talking to these servers are already running chrony. Once the servers are running chrony, I'm going to want to enable the

Re: [chrony-users] Hardware timestamping in CentOS 7.4 (was: Possible to get sub-millisecond accuracy?)

On Fri, Jun 23, 2017 at 11:57 AM, Miroslav Lichvar wrote: > That's an interesting idea. Do you think people would prefer SW RX+HW > TX timestamping over SW RX+SW TX? "SW" in this context means kernel timestamps, right? When I sent that email I was thinking it would be nice.

[chrony-users] Root delay and Root dispersion values in `chronyc ntpdata'

I have a setup that looks like the following: GPS Receiver -- PTP --> machine_a -- NTP --> machine_b Where: These machines are all pretty close together (the switching latency between them should be something like 10us). machine_a is running linuxptp and chrony with a shared memory region via

Re: [chrony-users] Hardware timestamping in CentOS 7.4 (was: Possible to get sub-millisecond accuracy?)

On Fri, Jun 23, 2017 at 2:43 PM, Miroslav Lichvar wrote: > It's the patch included in the package from the copr repo. Does it not > work for you? Oh, sorry that wasn't clear to me and I haven't had a chance to test with it yet. Is there something included in the copr repo

Re: [chrony-users] Hardware timestamping in CentOS 7.4 (was: Possible to get sub-millisecond accuracy?)

On Fri, Jun 23, 2017 at 1:10 PM, Miroslav Lichvar wrote: > I think we can support it, at least with a new option that would > disable the filter. I actually have a patch in my queue to allow > disabling the new NTP-specific filter, which should be added in 4.13 > (although

Re: [chrony-users] Hardware timestamping in CentOS 7.4 (was: Possible to get sub-millisecond accuracy?)

On Fri, Jun 23, 2017 at 2:49 PM, Chris Perl <cp...@janestreet.com> wrote: > Is there something included in the copr repo that isn't in the git > repo? I'm not that familiar with copr, but based on what I have read, > I wouldn't think so. > > If not, I'd prefer to just buil

Re: [chrony-users] Root delay and Root dispersion values in `chronyc ntpdata'

On Mon, Jun 26, 2017 at 4:37 AM, Miroslav Lichvar wrote: > The root delay and dispersion fields printed by the ntpdata command > are the values from the received packet. They should be the same as > printed by tcpdump. Can you post tcpdump -v -x output? I guess I must have

Re: [chrony-users] Possible to get sub-millisecond accuracy?

On Thu, Jun 15, 2017 at 8:48 AM, Miroslav Lichvar wrote: > I doubt they will be added in 6, but 7.4 should have the OPT_CMSG > option. Some minor changes in the chrony code will still be necessary > in order to enable HW timestamping. Yea, I wasn't expecting 6 to ever

[chrony-users] Asking chronyd not to combine time from multiple sources

I would like a way to be able to ask chronyd not to combine time from multiple sources, but instead to just trim the local clock from the selected system peer. I believe the ways you could do that today are: 1. Only have 1 server defined in chrony.conf 2. Use the `trust' and `prefer' directives

Re: [chrony-users] Asking chronyd not to combine time from multiple sources

On Thu, Sep 21, 2017 at 8:42 AM, Holger Hoffstätte wrote: > > Are you looking for the "combinelimit " directive? > If I understand you correctly, "combinelimit 0" does exactly what you are > asking for and works fine here. Ah, very possibly! I will play with that

[chrony-users] leapsectz and phc refclock offset

I have chrony servers that are using phc refclocks. Those refclocks are kept in TAI, so I have to specify the current TAI-UTC offset in the `refclock' directive ("offset -37"). I cross check that the current value I have set there seems sane via some monitoring that uses the timezone files to

Re: [chrony-users] leapsectz and phc refclock offset

On Thu, Oct 5, 2017 at 3:53 AM, Miroslav Lichvar wrote: > > I think we might want to reserve a suspend/resume command for > suspending/resuming the chrony operation before/after system suspend. Good point. I'm going to think on it a while longer and will try to come up with

Re: [chrony-users] leapsectz and phc refclock offset

On Tue, Sep 26, 2017 at 11:26 AM, Miroslav Lichvar wrote: > You are the first one reporting this problem. If you have collected > the phc2sys output and chrony's refclock+tracking logs from that time, > I'd like to see that. I don't have the output or logs handy, but I do

Re: [chrony-users] leapsectz and phc refclock offset

On Fri, Sep 22, 2017 at 4:32 AM, Miroslav Lichvar wrote: > > An advantage of this approach is that chronyd will stop accumulating > new samples when the PHC is no longer synchronized as phc2sys is > continuously checking state of the PTP port. This works to some extent,

Re: [chrony-users] leapsectz and phc refclock offset

On Fri, Sep 22, 2017 at 4:32 AM, Miroslav Lichvar wrote: > Is the PHC synchronized by ptp4l? You could use phc2sys -E ntpshm to > get the reference time in UTC in a SHM segment and use that in chrony > with the SHM refclock instead. > > An advantage of this approach is that

Re: [chrony-users] leapsectz and phc refclock offset

On Mon, Oct 2, 2017 at 9:46 AM, Miroslav Lichvar wrote: > A new command that could be used to suspend and resume a reference > clock would make sense to me. I'm not sure what would be the best > syntax. I think it has to separate command from the online/offline > commands as