On 11/24/19 3:41 AM, Hal Murray via devel wrote:
> rlaa...@wiktel.com said:
>> I can build from git or with whatever patches, if needed. If something is
>> wrong with this clock fuzzing code, I'd love to help get to the bottom of it,
>> but this doesn't seem like the sort of thing I can sort out
I just pushed a fix/change in seccomp. It broke recently in Fedora 31. ppoll
doesn't work anymore. The comment said Arch but my Arch box works without it.
I commented it out and haven't found any distro that uses it. Please test.
I also pushed some work on NTS logging. The normal
On Sun, Nov 24, 2019, at 19:32, Hal Murray via devel wrote:
>
> e...@thyrsus.com said:
> > If we don't see any evidence of beat-induced quantization, I'm willing to
> > say
> > we drop this code.
>
> How about adding a --disable-fuzz configure option so we can experiment
> without breaking
e...@thyrsus.com said:
> If we don't see any evidence of beat-induced quantization, I'm willing to say
> we drop this code.
How about adding a --disable-fuzz configure option so we can experiment
without breaking the default case.
Or maybe a runtime configure option.
Early
Yo Richard!
On Fri, 22 Nov 2019 23:09:17 -0600
Richard Laager via devel wrote:
> The NTPviz output says, "TDOP is a dimensionless error factor. TDOP
> ranges from 1 to greater than 20. 1 denotes the highest possible
> confidence level. 2 to 5 is good."
>
> I routinely have TDOP values below 1,
Yo Richard!
On Sat, 23 Nov 2019 23:08:06 -0600
Richard Laager via devel wrote:
> It looks like you're talking about clock_test.c.
> Below are ten runs from ntp1.
> min 39 ns, max 120 ns, mean 89 ns, median 96 ns, StdDev 18 ns
A min/max spread of almost 100 ns. Now you see why I say the
Yo ASSI!
On Sun, 24 Nov 2019 07:37:13 +0100
ASSI via devel wrote:
> Gary E. Miller via devel writes:
> > There is a gpsd program in the contrib/ directory. It tests your
> > CPU granularity. On a Raspberry Pi that is about 52 ns. Worse
> > on an Intel chip.
>
> The actual granularity on
Yo Udo!
On Sun, 24 Nov 2019 09:23:19 +0100
Udo van den Heuvel via devel wrote:
> I cam across this ublox ntpsec refclock:
> https://gitlab.com/trv-n/ntpsec-ublox
> Would it be usable for incorporation in the ntpsec tree?
> (AFAIK this is a 'straight' refclock; no extra lines needed besides
>
Yo Richard!
On Sun, 24 Nov 2019 03:44:57 -0600
Richard Laager via devel wrote:
> On 11/24/19 2:23 AM, Udo van den Heuvel via devel wrote:
> > I cam across this ublox ntpsec refclock:
> > https://gitlab.com/trv-n/ntpsec-ublox
>
> That's certainly interesting. I'd personally be interested,
Yo Eric!
On Sun, 24 Nov 2019 08:55:53 -0500
"Eric S. Raymond via devel" wrote:
> We have pretty good visualization tools these days. Gary, you know
> best what normal perfornance looks like under ntpviz. Would you be
> willing to patch-disable fuzzing and see if that induces any
>
Yo Udo!
On Sun, 24 Nov 2019 15:08:05 +0100
Udo van den Heuvel via devel wrote:
> On 24-11-2019 15:01, Eric S. Raymond wrote:
> > Udo van den Heuvel :
> >> I have an M8N on order, would that be compatible enough to this
> >> driver? If so: I could help test etc.
> >
> > That can't hurt -
Eric S. Raymond via devel writes:
> Not necessarily a fake; the 8N is the normal variant (without
> stationary mode) and less expensive. I suspect it's the same hardware
> with a different firmware load - they price-discriminate because
> they think the customers for stationary mode will pay
Udo van den Heuvel :
> On 24-11-2019 15:01, Eric S. Raymond wrote:
> > Udo van den Heuvel :
> >> I have an M8N on order, would that be compatible enough to this driver?
> >> If so: I could help test etc.
> >
> > That can't hurt - they speak the same protocol - but the big deal with
> > the T
On Sun, Nov 24, 2019, at 12:12 AM Hal Murray via devel
wrote:
>
> Mark Atwood said:
> > On the other other other hand, can we have a Python binding on the C
> crypto
> > routines that ntpd uses?
>
I'd probably prefer a generic FFI module with a ctypes wrapper
but yes probably.
> The ntpd code
Eric S. Raymond via devel writes:
> If we don't see any evidence of beat-induced quantization, I'm willing
> to say we drop this code.
Please don't invent gobbledeegok terminology. "Beat-induced
quantization" is completely devoid of meaning. Again, what we're
talking about is dithering and it
On 24-11-2019 15:11, James Browning via devel wrote:
> I do not suppose this would be anything like issue 499.
Different code. (?)
'straight' clock, no kernel issues identified (yet).
Udo
___
devel mailing list
devel@ntpsec.org
On Sun, Nov 24, 2019, 6:08 AM Udo van den Heuvel via devel
wrote:
> On 24-11-2019 15:01, Eric S. Raymond wrote:
> > Udo van den Heuvel :
> >> I have an M8N on order, would that be compatible enough to this driver?
> >> If so: I could help test etc.
> >
> > That can't hurt - they speak the same
On 24-11-2019 15:01, Eric S. Raymond wrote:
> Udo van den Heuvel :
>> I have an M8N on order, would that be compatible enough to this driver?
>> If so: I could help test etc.
>
> That can't hurt - they speak the same protocol - but the big deal with
> the T variant os a stationary mode you don't
Udo van den Heuvel :
> I have an M8N on order, would that be compatible enough to this driver?
> If so: I could help test etc.
That can't hurt - they speak the same protocol - but the big deal with
the T variant os a stationary mode you don't have.
--
Hal Murray via devel :
> I'm tempted to rip out that stuff. I haven't quite convinced myself that it
> isn't doing something important. Eric?
The clock fuzzing? It's an interesting question. I've thought about it.
I'm doubtful myself. The obvious motivation would be to avoid beat
effects
On 24-11-2019 14:18, Eric S. Raymond wrote:
> Udo van den Heuvel via devel :
>> I cam across this ublox ntpsec refclock:
>> https://gitlab.com/trv-n/ntpsec-ublox
>> Would it be usable for incorporation in the ntpsec tree?
(...)
>
> I have filed an issue on its tracker titled "Work should be
Udo van den Heuvel via devel :
> I cam across this ublox ntpsec refclock:
> https://gitlab.com/trv-n/ntpsec-ublox
> Would it be usable for incorporation in the ntpsec tree?
> (AFAIK this is a 'straight' refclock; no extra lines needed besides
> rx/tx and pps)
Thank you very much for bringing this
Richard Laager via devel writes:
> Okay, so upon further reflection, the timestamps seem to indicate that I
> need to use the clear/falling edge. This also explains the duplication,
> I think. This is despite the GPS being configured for rising edge. So as
> Hal (I think) said, something is
On 11/24/19 2:23 AM, Udo van den Heuvel via devel wrote:
> I cam across this ublox ntpsec refclock:
> https://gitlab.com/trv-n/ntpsec-ublox
That's certainly interesting. I'd personally be interested, from a
hobby/curiosity* perspective, in such a driver if it automated various
configuration steps
rlaa...@wiktel.com said:
> I can build from git or with whatever patches, if needed. If something is
> wrong with this clock fuzzing code, I'd love to help get to the bottom of it,
> but this doesn't seem like the sort of thing I can sort out by myself.
I don't have any good ideas.
Can you
On 11/23/19 1:53 AM, Richard Laager via devel wrote:
>
> On ntp2 (again, this is the u-blox 6 eval kit), I'm getting duplicated
> sequence numbers, which doesn't seem quite right:
>
> rlaager@ntp2:~$ sudo ppstest /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok,
Hello,
I cam across this ublox ntpsec refclock:
https://gitlab.com/trv-n/ntpsec-ublox
Would it be usable for incorporation in the ntpsec tree?
(AFAIK this is a 'straight' refclock; no extra lines needed besides
rx/tx and pps)
Kind regards,
Udo
___
Mark Atwood said:
> On the other other other hand, can we have a Python binding on the C crypto
> routines that ntpd uses?
The ntpd code gets crypto from OpenSSL's libcrypto.
We could write a wrapper for libcrypto. The API is reasonably clean. (or at
least the parts we use.) I'm a bit
28 matches
Mail list logo
