Yo Eric!
On Wed, 28 Sep 2016 23:58:39 -0400
"Eric S. Raymond" wrote:
> > I'm guessing this commit: d9024785b6c5a8b648b4f6a6982b6de1d2afa286
>
> Yeah, I got that warning and fixed it by giving the NANOSECONDS value
> an 'L' suffix so the expression is long-valued. Are you building on a
> 32-bi
Yo Eric!
On Wed, 28 Sep 2016 23:58:39 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Yo All!
> >
> > I'm getting a new warning on the build:
> >
> > [153/250] Compiling util/sht.c
> > ../../util/hist.c: In function ‘main’:
> > ../../util/hist.c:22:20: warning: integer overflow in expres
Yo Eric!
On Thu, 29 Sep 2016 00:07:25 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Yo Eric!
> >
> > On Wed, 28 Sep 2016 17:24:10 -0400
> > "Eric S. Raymond" wrote:
> >
> > > Remember, you can't even *build* the KERNEL_PLL version on a
> > > platform without adjtimex(2).
> >
>
Hal Murray :
>
> e...@thyrsus.com said:
> > The big deal is that a build *with* KERNEL_PLL will generate adjtimex(2)
> > events into the capture logs. A build without KERNEL_PLL won't. Neither
> > kind of log will be replayable on the other kind of build.
>
> I don't have time to help with this
Gary E. Miller :
> Yo Eric!
>
> On Wed, 28 Sep 2016 17:24:10 -0400
> "Eric S. Raymond" wrote:
>
> > Remember, you can't even *build* the KERNEL_PLL version on a platform
> > without adjtimex(2).
>
> The linux man page for adjtimex(2) says that ntp_adjtime() is preferred.
Which I find strange
Gary E. Miller :
> Yo All!
>
> I'm getting a new warning on the build:
>
> [153/250] Compiling util/sht.c
> ../../util/hist.c: In function ‘main’:
> ../../util/hist.c:22:20: warning: integer overflow in expression [-Woverflow]
> #define NCNT (600L * NANOSECONDS) /* sample interval (ns) */
>
Yo All!
I just ran a 6 hour test of --disable-kernel-pll. See attached.
The left side before 18:45 is yesterday's ntpd. After that
time is today's ntpd with --disable-kernel-pll. Nothing else
changed.
As the png shows, the frequency jitter declined, but the offset
jitter increased. Since ntp
Yo All!
I'm getting a new warning on the build:
[153/250] Compiling util/sht.c
../../util/hist.c: In function ‘main’:
../../util/hist.c:22:20: warning: integer overflow in expression [-Woverflow]
#define NCNT (600L * NANOSECONDS) /* sample interval (ns) */
^
../../util/hist.c
Yo All!
Something less than optimal happened in the lsat 24 hours. I recompiled
NTPsec on my RasPi2/Adaafruit HAT. No other changes to this system.
ntpd restart about 19:00. See attached for a 12 hour plot. Note the
increased jitter in the time offset and the frequency offset.
The only major
Hi!
I have added a draft of the release checklist to devel/hacking.txt
Please look it over, and give feedback.
My next rev of it will include the actually command line commands..
Thank you!
..m
> -Original Message-
> From: Eric S. Raymond [mailto:e...@thyrsus.com]
> Sent: Tuesday, Sep
Yo Hal!
On Wed, 28 Sep 2016 15:38:58 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> New samples arrive every second.
> > No. Twice a second. But now you are confusing the PPS with the
> > PLL.
>
> PPS is pulse per second. There is only 1 pulse each second. Where
> is the other d
g...@rellim.com said:
>> New samples arrive every second.
> No. Twice a second. But now you are confusing the PPS with the PLL.
PPS is pulse per second. There is only 1 pulse each second. Where is the
other data coming from?
Are you thinking of the other edge? ntpd disables collecting da
Yo Hal!
On Wed, 28 Sep 2016 15:19:38 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> There is a PLL kernel option to track a PPS. It's not compiled
> >> into most Linux kernels.
> > Thus a distraction to our discussion.
>
> I think it's key to why this discussion is causing so much c
Yo Hal!
On Wed, 28 Sep 2016 15:27:02 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> PLL option in the Linux kernel that gets included when you say:
> >> CONFIG_NTP_PPS=3Dy
> > We never use that PLL. No one should use that PLL with linux.
>
> [What do you mean "we", white man.]
>
>
g...@rellim.com said:
>> PLL option in the Linux kernel that gets included when you say:
>> CONFIG_NTP_PPS=3Dy
> We never use that PLL. No one should use that PLL with linux.
[What do you mean "we", white man.]
Why not? It works well on my systems.
*HPGPS(0).GPS.0 l 30
g...@rellim.com said:
>> There is a PLL kernel option to track a PPS. It's not compiled into
>> most Linux kernels.
> Thus a distraction to our discussion.
I think it's key to why this discussion is causing so much confusion.
When I say "kernel PLL", that's what I'm referring to. See my recen
Yo Hal!
On Wed, 28 Sep 2016 15:09:46 -0700
Hal Murray wrote:
> Part of the problem is that we have a word tangle between my use of
> "kernel PLL" and your use of "KERNEL_PLL". I was referring to the
> PLL option in the Linux kernel that gets included when you say:
> CONFIG_NTP_PPS=y
We never
e...@thyrsus.com said:
> The big deal is that a build *with* KERNEL_PLL will generate adjtimex(2)
> events into the capture logs. A build without KERNEL_PLL won't. Neither
> kind of log will be replayable on the other kind of build.
I don't have time to help with this now.
I think you should k
Yo Eric!
On Wed, 28 Sep 2016 17:24:10 -0400
"Eric S. Raymond" wrote:
> Remember, you can't even *build* the KERNEL_PLL version on a platform
> without adjtimex(2).
The linux man page for adjtimex(2) says that ntp_adjtime() is preferred.
What system has adjtimex(2) and not ntp_adjtime(2)?
RG
Gary E. Miller :
> Yo Eric!
>
> On Wed, 28 Sep 2016 16:32:33 -0400
> "Eric S. Raymond" wrote:
>
> > The slewing variations in clock speed are
> > so small that they're generally invisible even to soft-realtime
> > applications.
>
> Got a number on this? chronyd can slew the clock up to 8.5% fo
Try not to send mail in HTML; mutt can't read it.
John Bell :
>At the risk of sounding stupid (or at least uninformed), couldn't you
>capture TESTFRAME logs from the same hardware *booted on each kind of
>kernel* (with the kernels being otherwise identically configured),
>and just have the WITH an
Yo Eric!
On Wed, 28 Sep 2016 16:32:33 -0400
"Eric S. Raymond" wrote:
> The slewing variations in clock speed are
> so small that they're generally invisible even to soft-realtime
> applications.
Got a number on this? chronyd can slew the clock up to 8.5% for
extended periods of time.
> The KE
Gentlemen,On September 28, 2016 at 4:21 PM "Eric S. Raymond" wrote:The big deal is that a build *with* KERNEL_PLL will generate adjtimex(2)events into the capture logs. A build without KERNEL_PLL won't. Neitherkind of log will be replayable on the other kind of build.The original goal for TESTFRA
This is in devel/tour.txt. Please review, discuss, and patch to clarify
as needed.
== System call interface and the PLL ==
All of ntpd's clock management is done through four system calls:
clock_gettime(2), clock_settime(2), ntp_adjtime(2), and (on some
systems) adjtimex(). The settimeofday(2)
Mark: Heads up! TESTFRAME is probably almost pointless now, or at
least we can't count on it being fit for its original use until we
solve the slow-convergence problem well enough to dispense with the
KERNEL_PLL code.
Gary E. Miller :
> Hal Murray:
> > I don't see the problem. TESTRAME is testing
Yo Hal!
On Wed, 28 Sep 2016 02:06:18 -0700
Hal Murray wrote:
> I think two things are getting confused. One is the ability to slew
> the clock. The other is a PLL to automate tracking a PPS.
I am unaware of any PLL directly tracking PPS in ntpd or mainline Linux
kernel.. The PPS is averaged
Yo Hal!
On Wed, 28 Sep 2016 12:21:54 -0700
Hal Murray wrote:
> gemiller:
> Being the whole point of ntpd, to
> manage the kernel PLL, this should be
> obvious.
>
> No. The purpose of ntp is to maintain the correct system time.
Sort of. First, ntpd manages system time by mangaing the ke
gemiller:
Being the whole point of ntpd, to
manage the kernel PLL, this should be
obvious.
No. The purpose of ntp is to maintain the correct system time.
ntpd itself is a PLL.
The purpose of the Kernel PLL is to do the same things with
PPS pulses but do it better. It may have been import
Yo Hal!
On Wed, 28 Sep 2016 11:14:49 -0700
Hal Murray wrote:
> gemiller
> I have a hard time believing a PLL
> running at user timer interrupt time
> can be anywhere as good as a kerenl
> PLL running at TICK intervals.
>
> There are two parts to this discussion. There is the PPS time s
gemiller
I have a hard time believing a PLL
running at user timer interrupt time
can be anywhere as good as a kerenl
PLL running at TICK intervals.
There are two parts to this discussion. There is the PPS time stamp and the
PLL.
The PPS time stamp gives you the data to work with. The w
dfranke said:
esr1: userspace code can't be
substitute for the kernel PLL
regardless of accuracy. The benefit
of kernel PLL is that the clock never
has to move discontinuously, because
the kernel can apply the smoothing
while handling the clock_gettime
system call. If you adjust the clock
from use
31 matches
Mail list logo
