Eric S. Raymond via devel writes:
>>This is still happening with ntpsec-0.9.7+1104, albeit much less often
>>now (but I've removed iburst from the configuration files). I just had
>>it happen while I was updating the rasPis. Again, the symptom is that
>>there is a "rate_exceeded" event and the hp
Fred Wright via devel writes:
> But it can't "filter" the overall offset - it has no way to know what it
> is.
I never claimed that it does. I lack an absolute time reference anyway
and have yet to splurge for a good enough frequency normal, so at the
moment all I care about is getting the three
Yo Fred!
On Mon, 25 Sep 2017 19:26:02 -0700 (PDT)
Fred Wright via devel wrote:
> On Mon, 25 Sep 2017, Gary E. Miller via devel wrote:
> > On Mon, 25 Sep 2017 16:55:30 -0700 (PDT)
> > Fred Wright via devel wrote:
> >
> > > PPS(2) is the counter-capture PPS source, and is the primary
> > > timi
On Mon, 25 Sep 2017, Gary E. Miller via devel wrote:
> On Mon, 25 Sep 2017 16:55:30 -0700 (PDT)
> Fred Wright via devel wrote:
>
> > PPS(2) is the counter-capture PPS source, and is the primary timing
> > reference.
>
> Can you explain a bit more about this source? How does this differ
> from th
Yo Fred!
On Mon, 25 Sep 2017 16:55:30 -0700 (PDT)
Fred Wright via devel wrote:
> PPS(2) is the counter-capture PPS source, and is the primary timing
> reference.
Can you explain a bit more about this source? How does this differ
from the KPPS or PPS(TIOCMIWAIT) sources?
> SHM(1) is the comb
On Mon, 25 Sep 2017, Achim Gratz via devel wrote:
> Fred Wright via devel writes:
> > I get a kick out of you guys fussing over "thermal stability" when the
> > largest source of time error is the interrupt latency in timing the PPS
> > signal.
>
> The median interrupt latency shows up as an addit
Yo Fred!
On Mon, 25 Sep 2017 12:58:42 -0700 (PDT)
Fred Wright via devel wrote:
> I get a kick out of you guys fussing over "thermal stability" when the
> largest source of time error is the interrupt latency in timing the
> PPS signal.
Uh, that is not my experience. And I have more control ove
Fred Wright via devel writes:
> I get a kick out of you guys fussing over "thermal stability" when the
> largest source of time error is the interrupt latency in timing the PPS
> signal.
The median interrupt latency shows up as an additional offset on top of
other such offsets. The variability on
On Mon, 25 Sep 2017, Achim Gratz via devel wrote:
> Fred Wright via devel writes:
>
> > Can the failure rate be increased by changing the governor settings to
> > make the server slower? On the Pi that would significantly worsen the
> > time accuracy, but for the purposes of this experiment that
Fred Wright via devel writes:
> I presume "packages" was meant to be "packets".
Yes, but since I was packaging a few hundred Perl modules for Cygwin at
the time, my mind wandered off and that one slipped through.
>> I'll try to reproduce on my RPis.
>
> Is there some kind of stress-test program t
On Sun, 24 Sep 2017, Eric S. Raymond via devel wrote:
> Achim Gratz via devel :
> > Eric S. Raymond via devel writes:
> > > Now that iburst has been fixed - and Achim reports seeing this problem
> > > with iburst off - this pretty much has to be an issue deeper in the
> > > protocol machine. (I g
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Now that iburst has been fixed - and Achim reports seeing this problem
> > with iburst off - this pretty much has to be an issue deeper in the
> > protocol machine. (I guess we should count our blessings and
> > congratulate Daniel th
Eric S. Raymond via devel writes:
> Now that iburst has been fixed - and Achim reports seeing this problem
> with iburst off - this pretty much has to be an issue deeper in the
> protocol machine. (I guess we should count our blessings and
> congratulate Daniel that there haven't more of these sin
Eric S. Raymond via devel writes:
> Again, the ntp_peer.c hits are during newpeer initialization. That
> is, I can't find any way that minpoll recovers after a KOD in
> Classic, either.
As far as I can tell, in classic I never seem to get a KOD or at least
it doesn't move the poll interval up tha
I wrote:
>If this is happening with iburst *off*, it becomes more difficult to
>understand how the rate limit is being triggered. I think maybe we
>should start by focusing on something else: why is hpoll not
>recovering after a KOD?
>
>I'm thinking this sounds like some KOD-recovery logic got los
Heads up, Daniel!
Achim Gratz via devel writes:
>> I still think there must be some bug somewhere that either makes the
>> client send too many packets or the server sending that KOD too early.
>
>This is still happening with ntpsec-0.9.7+1104, albeit much less often
>now (but I've removed iburst
16 matches
Mail list logo
