On 21-01-19 03:20, Hal Murray via devel wrote:
> So my guess is that the normal path isn't putting the right stuff into the
> kernel. We are missing a call to ntp_adjtime
A fresh build of latest git shows me, straight after ntpd restart:
# /usr/bin/ntpq -c kerninfo|/bin/awk -e '/pll offset:/ '
ntpq gets pll offset via ntp_control using CS_K_OFFSET which gets it from
ntx.offset
ntx comes from ntp_adjtime which is only updated if a big conditional which is
all local and looks good. But check for MODE6 errors in the log file.
There is nothing lockclock in that local area.
So my
Eric said:
> Therefore...would you please take a hard look at the change and see if you
> can repair it? I hate to slough off my mistakes on anybody, but the fix
> needs to be applied by somebody who can test it.
Alternatively, this is a good opportunity for you to learn more about how ntpd
Looks good on a modern browser. The diagram doesn't render on a very old
browser which can show the stand-alone diagram. Is there something tricky
about the include-it recipe?
I think we should keep the plain text version around for a while. How
complicated is the conversion process?
--
Richard Laager via devel writes:
>>> * Is NTPsec going to initiate NTS by default?
>
>> Probably not. That would break backward compatibility.
The draft RFC states that falling back to plain NTP from NTS is not
allowed without explicit user interaction. So choice of NTS vs. plain
NTP has to be
Eric S. Raymond via devel writes:
> Well, shit. Achim, have you IDed an actual bug, or is that a guess based
> on the timing of the report?
No, I've updated two boxes yesterday and they've reported a loop
frequency of essentially (but not exactly) zero since. Something is
still keeping the
James Browning via devel writes:
> I would appreciate it if people would look at it and provide constructive
> criticism about the content. The edits are sorted roughly into things I
> think are acceptable as is, acceptable with some revision and thing I
> think I need to seriously edit or drop.
Achim Gratz via devel :
> Udo van den Heuvel via devel writes:
> > I noticed that since Friday the output of
> >
> > /usr/bin/ntpq -c kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o
> > = -o; print o*100;}' -e '/estimated error/ {print $3*100;print
> > 1;print "ntpstat"}'
> >
> >
I have an HTML/SVG render of a modified devel/nts.adoc at:
http://www.jamesb192.com:8001/james/nts.html
The source in in MR !894 at:
https://gitlab.com/NTPsec/ntpsec/merge_requests/894
I would appreciate it if people would look at it and provide constructive
criticism about the content. The
Udo van den Heuvel via devel writes:
> I noticed that since Friday the output of
>
> /usr/bin/ntpq -c kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o
> = -o; print o*100;}' -e '/estimated error/ {print $3*100;print
> 1;print "ntpstat"}'
>
> gives different results than before.
I
Hello,
I noticed that since Friday the output of
/usr/bin/ntpq -c kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o
= -o; print o*100;}' -e '/estimated error/ {print $3*100;print
1;print "ntpstat"}'
gives different results than before.
On one box I used to see an mrtg graph with
I moved the comments about configuration away from the packet processing area
to a new block on configuration. There are probably rough edges.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
12 matches
Mail list logo
