Hal Murray via devel :
> Do you have any data on Go GC times?
Yes. They're pretty miniscule. Most Go GC is performed concurrently
with normal program execution, except for one stop-the-world phase
that typically runs on the close order of 1ms for real production
programs.
Hal Murray :
> Maybe it's time to switch to Go?
I've thought about it. It shouldn't be all that difficuly. I wrote a tol that
would help:
https://gitlab.com/esr/pytogo
> How long would it take us to rewrite, from scratch, everything in ntpclients?
Around three man-monts is my estimate.
> I
Gary E. Miller via devel :
> > Maybe it's time to switch to Go?
>
> Please, no. Go is a garbage collected language. Just what NTPsec does
> not need, random, unpredictable delays.
We're only takling client-side as yet.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Hal Murray via devel :
> Really really dead? Or maybe just hiding in some dark corner?
Python 2 was end-of-lifed on 1 Jan 2020. It looks pretty dead from where I'm
sitting,
but I'm aware that people who run RHEL have a different opynion.
> Should we drop support for python2 as part of the
Checking to make sure I've resubscribed.
--
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Hal Murray :
>
> > I'm pretty sure this is a problem with the ntpq code, not with Python -
> > Python in general has a reputation for being *easy* to read six months
> > later,
> > which I think is deserved. It's one of the first things I noticed when I
> > started coding in Python back in 1998
Hal Murray :
> More topics for this discussion:
>
> What platforms is the new environment supported on? See my reply to Sanjeev
> Gupta's message.
>
> As far as I can tell, we don't have a list of supported/tested platforms. Is
> there an official we page that describes what we support? (I'm
Hal Murray :
> Thanks for taking the time to explain things to me.
Why would I not? It's *good* to have someone on the projects who's sufficiently
smart and stubborn to question my premises - please never stop doing that! I
know
more about the problems around getting to a memory-safe language
Hal Murray :
> If you pass in a buffer, there is no reason to allocate anything in the case
> of a server processing a request so this whole discussion is a wild goose
> chase.
It's a little more complicated than that, because I was describing the
lowest-level recvfrom() in the socket library.
Hal Murray :
> That sounds like the right ballpark. Again, if I were working in this area I
> would be writing hack code to generate numbers. It's got to have a buffer
> for
> each item waiting in the channel. Does it do an alloc/free on each item or
> does it avoid that by saving the
Hal Murray :
>
> >> That doesn't make sense. Where does your "one second apart" come from?
> Why
> >> is "currently has 2 threads" interesting?
> > When do we poll at a less than one-secpmd interval? Most allocatopmns wo;l;
> > ber associated with making a packet fra,e for he send, thn dealing
Hal Murray :
> > You're thinking in C. This is a problem, because mutex-and-mailbox
> > architectures don't scale up well. Human brains get overwhelmed at about 4
> > mutexes; beyond that the proliferation of corner cases get to be more than
> > the meat can handle.
>
> I'm missing something.
Hal Murray :
>
> > I don't know all those numbers yet. But: given that NTPsec only currently
> > has 2 threads and our allocations are typically occuring one second apart or
> > less per upstream or downstream, I can't even plausibly *imagine* a Raft
> > implementation having lower memory churn
Richard Laager via devel :
> On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
> > > There is a close-to-RFC to handle this area. "Interleave" is the
> > > buzzword. I
> > > haven't studied it. The idea is to grab a transmit time stamp, then
> &g
Hal Murray :
>
> [timing of GC]
>
> > which shows their meassured STW pauses are bounded to about 95% by 600us and
> > typically less than 400us. This is consistent with other reports I've seen,
> > and that's why I took 600us as a worst case STW we're likely to see.
>
> I didn't see any
Hal Murray :
> You have a new toy. The only tool needed is a simple lock.
Oh? What about the concurrent DNS thread we already have?
At this point I have two years of heavy experience in Go, so the toy
is no longer new. If a better upgrade from C existed, I would know
about it - Rust comes
Hal Murray :
>
> > We don't have a multithreaded server yet. Worst case we have two threads,
> > and only one can ever reach the critical region in question. Don't borrow
> > trouble! :-)
>
> I'm interested in building a server that will keep a gigabit link running at
> full speed. We can do
Hal Murray :
> >> 1. packet tx happening right after tx timestamp for server response
>
> > A) Mitigate window 1 by turning off GC before it and back on after.
>
> Things get complicated. Consider a multi threaded server. If you have
> several busy server threads, can they keep the GC off
Dan Drown via devel :
> Let's talk a bit about what time critical sections are currently in the
> code. I think that will help drive the decision about the impact of garbage
> collection.
>
> I haven't looked at ntpsec's codebase lately, so some of this might be out
> of date. Please feel free
Hal Murray :
>
> Eric said:
> > Talk to me about what you think the effect of very occasional stop-the-world
> > pauses of 600 microseconds or less would be on sync accuracy. By "very
> > occasionally" let's say once every ten minutes or so, that being what I
> > think
> > is a *very*
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Talk to me about what you think the effect of very occasional
> > stop-the-world pauses of 600 microseconds or less would be on sync
> > accuracy. By "very occasionally" let's say once every ten minut
Achim Gratz via devel :
> Matthew Selsky via devel writes:
> > On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote:
> >
> >> Well, first, the historical target for accuracy of WAN time service is
> >> more than an order of magnitude higher
Richard Laager via devel :
> Not particularly. Presumably it's just because of GPS PPS + good network?
Having a good local clock can explaiin it, yes.
--
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
Hal Murray via devel :
> There is the 32bit time_t problem. We've got a few more years.
I've been thinking forward about that. One of my objectives in the
big cleanup was to make the time width easier to change, and now it
would be internally. The remaining blocker is that the NTP packet
Hal Murray :
> Maybe ntpd should turn into a mega program that parses the config file and
> runs a bunch of other programs and/or threads.
That's an extremely natural way to partition in Go. Much, *much* easier than
trying to pull off the equivalent in C would be.
--
Hal Murray :
> > Well, first, the historical target for accuracy of WAN time service is more
> > than an order of magnitude higher than 1ms.
>
> Time marches on. We need to do better today, much better.
>
> NTP is used on LANs.
Then we'll need to go to watching for GC pauses and skipping
Hal Murray :
> [context is ntpq via shared memory]
>
> > Any reason not to use Unix-domain sockets and just reuse the current protcol
> > handling, except it's not accessible netwide? That might be simpler.
>
> I hadn't figured it out when I was typing in my previous message, but using
>
Richard Laager via devel :
> On 6/29/21 3:41 PM, Eric S. Raymond via devel wrote:
> > Well, first, the historical target for accuracy of WAN time service is
> > more than an order of magnitude higher than 1ms.
>
> My two NTP servers are +- 0.1 ms and +- 0.2 ms as mea
Matthew Selsky :
> Our target is < 1 us, even for WAN time service. We would want to
> keep/improve this accuracy target.
One *microsecond*? Has any version of NTP achieved that kind of accuracy?
I don't think we're there.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Hal Murray via devel :
>
> Does anybody have any good ideas on a modern way to handle ntpq/mode 6?
>
> Background...
>
> We could split the server side out into a separate process. That leaves a
> very tiny attack surface from the network. I think I could do that now
> except
> for mode 6.
Sanjeev Gupta via devel :
> This is a follow on to Eric's email a few hours ago, I am keeping that
> thread clean.
>
> (The last 3GL I programmed in was Fortran, and not the 77 version. I can
> read bash scripts and C pseudo-code)
>
> The literature I can find speaks of Go GC being improved in
James Browning via devel :
> I do not consider myself an expert C developer.
You're good enough to contribute materially to *this* project, which
is by no means the easiest C gode to grok. That makes you expert in
my book.
> I think the proposed schedule is overly serial. ntpkeygen and keygone
Developers, please weigh in on this so we can finalize it.
The final version will become part of a grant proposal which may
get us money for a hardware test lab and code bounties.
= NTPsec work plan
This is a rough-draft work plan for the NTPsec project over the period
July 1st 2021 to July 1st
MLewis :
>Is it worthwhile improving the current C code to a 'hardened' programming
>standard?�
>
>Example
>- Joint Strike Fighter standards
>[1]https://www.stroustrup.com/JSF-AV-rules.pdf
>- NASA JPL standards
>
>
James Browning via devel :
> Are there any C to golang or rust transpilers that work
> reasonably well? The last time I checked the best rust
> transpiler generated rs files that were just shallow glosses
> and the golang transpiler was somewhat inadequate and
> verbose.
This is still the state
Hal Murray :
> What was the name for your attempt to get a GPSD style replay of old data?
> Did we ever figure out why that didn't work?
I did. There's a blog post about it:
https://blog.ntpsec.org/2017/02/22/testframe-the-epic-failure.html
--
http://www.catb.org/~esr/;>Eric
Hal Murray :
> > I'll start the ball rolling with this big one: It's time to move out of C.
>
> I want to threadify things, and taking advantage of that, I want to run at
> full wire speed on a gigabit link with a modest server class CPU.
>
> I have test code running. I'm pretty sure it will
Developers, please weigh in on what you think the NTPSec project's
goals for the next year ought to be. These goals can be coding
projects ("Move the Python code to Go") process goals ("Halve the size
of the issue list") or project infrastructure goals ("Build a hardware
lab so we can live-test
Hal Murray via devel :
> I'm still planning to threadify the server side. I'm stalled half on other
> things and half waiting for Eric to get free so we can cleanup the ntpq stuff.
Still on my to-do list. I'm still focused on my conversioon job,
though, making me actual money.
--
Hal Murray :
>
> e...@thyrsus.com said:
> > No, just boring history. I think those are old conditinal macros we no
> > longer use; likely they have been renamed to something else.
>
> The current code tests for SO_TIMESTAMPNS
>
> Should I just delete the old/unused stuff?
Yes.
--
Hal Murray via devel :
> >From ./devel/ifdex-ignores
> USE_SCM_BINTIME # to grab timestamp for recv packet
> USE_SCM_TIMESTAMP # "
> USE_SCM_TIMESTAMPNS # "
>
> None of those symbols are used by our code.
>
> Should I just delete them?
>
> What is the idea for USE_xxx? Is
James Browning via devel :
> I submitted a couple of patches to gpsd and one to microjson resolving
> issues. One where an empty string validated correctly as an object was
> already posted to microjson. The other allowed pretty much any string the
> same length or shorter to pass a t_check.
>
>
Hal Murray via devel :
>
> Gary said:
> > I think he is referring to reecent proposals to split ntpd up into multiple
> > daemons. Daemons for the core, NTS, clients, etc. Each doing a small job.
> > Rather than the one big daemon we have now.
>
> That sort of split looks good on paper, but
James Browning via devel :
> The ntpsec forks belonging to rlaager, selsky, and ianbreune are still
> detached. A quick check shows that there are no forks. The page I looked at
> claimed that such detached repositories cannot be reattached. TLDR there is
> only on MR that still might be
Sanjeev Gupta :
> As of 20 minutes ago, I can now pull from the repository unauthenticated.
Yes, and the visibility is now :Public" in the settings.
Looks like the problem is solved.
--
http://www.catb.org/~esr/;>Eric S. Raymond
___
Sanjeev Gupta via devel :
> Ah, so not my fault.
>
> I tried updating my fork about 11 hours ago, and was to authenticate to
> pull from the NTPsec git repo. I tried with another repo, it worked, so I
> assumed one of us was modifying the security settings of the repo.
Somwething either very
Hal Murray :
> Please do and/or please fix our local copy. I'm focused on the
> restrict/unrestrict tangle.
Bug fixed, but I cant finf any way to subnutt uissues on ther
bugracker. Yes, I have a validayed account ob the site.
Sill looking.
--
http://www.catb.org/~esr/;>Eric S.
Hal Murray via devel :
>
> I assume a fix for this should be pushed upstream.
>
> ../../tests/unity/unity.c: In function âUnityFailâ:
> ../../tests/unity/unity.c:1757:6: warning: function might be candidate for
> attribute ânoreturnâ [-Wsuggest-attribute=noreturn]
> 1757 | void
Hal Murray :
>
> > Looking at the changelog, the only one that jumps out at me is James's new
> > UI
> > options for ntpq.
>
> Should we have a policy of mentioning all UI changes?
I think so. I've been trying to do that whenever I write NEWS entries.
> How about config file changes?
Well,
Hal Murray :
> Is this an opportunity to clean up that area?
I don't think so. It's pretty clean now, functionally speaking - I put
a lot of work into rationalizing the configurator structures and the
way they talk to the protocol machine.
I suppose it might be if we were willing to make
Hal Murray :
>
> >> If you want to claim your Go program has no buffer overruns,
> >> you can't call out to big complicated libraries written in c. You
> >> would have to rewrite them in Go.
>
> > Fair point. That changes my to-do list.
>
> Could you please say more? What did you add or
Hal Murray via devel :
> Are any of the recent changes interesting enough to mention in NEWS?
Looking at the changelog, the only one that jumps out at me is James's new
UI options for ntpq.
Otherwise the recent stuff is bug triage and validator cleanups (LGTM
looks like a big win). I wouldn't
Gary E. Miller via devel :
> As previously mentioned here: RHEL 6.
Which is about to EOL.
> Supporting Python 2 is trivial. Why the hate?
Because it's not in fact trivial. It's *doable*; Peter Donis and I are
the expers on how to do it. But it's not trivial. It proliferates
code and test
Gary E. Miller via devel :
> Yo Eric!
>
> On Thu, 3 Sep 2020 14:13:05 -0400
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller via devel :
> > > Say what? This has zero to do with libraries.
> >
> > Sure it dies. Use different versions of Python, require different
> > library paths.
>
> No
Gary E. Miller via devel :
> Say what? This has zero to do with libraries.
Sure it dies. Use different versions of Python, require different
library paths.
--
http://www.catb.org/~esr/;>Eric S. Raymond
signature.asc
Description: PGP signature
Gary E. Miller via devel :
> > I don't want to go down this road. I have ugly memories associated
> > with a smiliar hack in gpsd, long ago.
>
> But what about how it works now? All the maintainers like it.
Oh dear Goddess. We are *still* mutating shebangs in GPSD? I must have
blotted that
Richard Laager via devel :
> > You realize that the POSIX doc says a pace after "#!", but so many do it
> > wrong they accept that variant.
> In NTPsec, there are 122 the wrong way and 81 the right way. As you say,
> either works. I don't particularly care about the space personally, but
> we can
Richard Laager via devel :
> RHEL 6 support (measured in terms of security updates) ends in November
> of this year. So by the time a version of NTPsec releases without Python
> 2 support, we'd be looking at RHEL 7.
On top of that, it has been Red Hat's official position for some time
that RHEL 6
Matthew Selsky :
> I also previously setup Codacy in order to see what other SAST systems could
> do. See https://app.codacy.com/gl/NTPsec/ntpsec/dashboard
>
> Let me know what you think. If either are useful, I'll integrate them more
> tightly in our workflows.
I'm already a fan of LGTM - it
Hal Murray :
>
> e...@thyrsus.com said:
> >> I think you have jumped to an unreasonable conclusion by assuming that Go
> >> makes seccomp unintestering. Are you going to rewrite OpenSSL in Go?
> > No. There's an opennsl binding: ...
>
> That's the whole point of my comment. OpenSSL is
Richard Laager via devel :
> Let me start over now that I've reviewed the specifics of the NTPsec
> scripts and build system again:
>
> We are currently using "#!/usr/bin/env python" in all the scripts, and
> waf uses the same. The minimum to do to drop Python 2 is:
>
> 1. Change waf's shebang:
Gary E. Miller via devel :
> Buffer overruns are just one way a program might make unexpected system
> calls. Even if you can guarantee that a Go program could never be
> maliciously corrupted externally, you can never guarantee that the
> Go program can not be trojaned.
Everything is cost
Hal Murray :
>
> e...@thyrsus.com said:
> > I think you misunderstand. I don't believe seccomp is objectively very
> > important in itself, and never have. My problem with dropping it is that if
> > we do that, we could be seen to have abandoned part of a security defense in
> > depth because
Gary E. Miller via devel :
> Lost me. seccomp applies to Go as much as it applies to C.
Why do you think so? My understanding is that the reason you want to
block unexpected system calls is becase C buffer overruns can be used
to make weird machines.
You can't do that in Go, because there's no
Sanjeev Gupta :
> They support *any* git repository.
Huh. Their docs are out of date, then.
> Please see: https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list
That's excellent. I'll chew through some of these today.
--
http://www.catb.org/~esr/;>Eric S. Raymond
folkert :
> > > > I've resolved all the Coverity warbings except a new one, "risky
> > > > function" related to random(3)/ The supression cookie for that one
> > > > is not suppressing; I've sent a requesr to Synopsis about tis.
> > >
> > > Is ntpsec also checked by 'lgtm.com'? They also do all
folkert :
> > I've resolved all the Coverity warbings except a new one, "risky
> > function" related to random(3)/ The supression cookie for that one
> > is not suppressing; I've sent a requesr to Synopsis about tis.
>
> Is ntpsec also checked by 'lgtm.com'? They also do all kinds of
>
Python 2 was end-of-lifed at the beginning of January this year.
All our primary target platforms fully support Python 3.
Retaining support for Python 2 proliferates test paths and
complicates the fix for at least one outstanding bug.
Philosophically, I'm a fan of dropping legacy support
when it
I've resolved all the Coverity warbings except a new one, "risky
function" related to random(3)/ The supression cookie for that one
is not suppressing; I've sent a requesr to Synopsis about tis.
I've close two stale issues. I think there are a few more that can
be retired. I'm continuing tio
Hal Murray :
> You keep saying seccomp is important. What does it buy us? ntpd is a big
> complicated program. It reads and writes files. It opens network
> connections. What else would a bad guy need to do?
I think you misunderstand. I don't believe seccomp is objectively
very important
Hal Murray :
> > I'll do a bug-triage pass.
>
> I've seen a couple of changes go by. Thanks.
>
> Please let me/us know when you are finished so I can test things.
Will do.
--
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel
Hal Murray via devel :
> > Has there been enough user visible improvement to warrent a release of
> > 1.1.10?
>
> I think so.
>
> 1.1.9 doesn't know about the new port number for NTS-KE.
>
> There is also a bug fix for a missing error message. Without that message,
> it's really tough to
Daniel Franke :
> clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC
> that nobody follows.
>
> On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel
> wrote:
>
> > Hal Murray via devel :
> > >
> > > When was clock_gettime and
Hal Murray via devel :
>
> When was clock_gettime and struct timespec introduced?
>
> We can cleanup some cruft if we assume it exists.
Assune it. These are in the Single Unix Standard.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Hal Murray :
>
> e...@thyrsus.com said:
> > Aaarrgghhh. It;s a huge pain in the ass and I wish it weren't interesting.
> > But given our mission statememnnt, it has to be.
>
> Just to make sure we are on the same wavelength...
>
> My question/proposal was not to drop seccomp if we didn't do
Hal Murray :
> The first quirk is that ntpd isn't on the #include search path.
> (My hack was to put a link from include to ntpd/seccomp)
> What's the right way to handle this? (Maybe I just fatfingered things.)
Generating the requred stuff into include, where all the headers live,
ought to
Hal Murray via devel :
>
> I've been experimenting with some code to allow custom scccomp lists.
>
> The idea is to replace the --enable-seccomp configure option with
> --enable-seccomp=foo
> and ntp_sandbox would include syscomp/foo.c which would be a list of syscalls
> used by this system.
Matthew Selsky via devel :
> Hi Hal and team,
>
> Much our of NTS code uses BSD-4-Clause-UC instead of BSD-2-Clause (our
> preferred license for new code).
>
> What this license selection intentional?
No. It's a historical accident.
> Is BSD-4-Clause-UC intended for code owned by the
Ian Bruene via devel :
> * What happens when a packet in the middle of the sequence is dropped? Who
> knows! If it is seen as a timeout then the client will adjust packet size
> and try again... forever. Or maybe it silently doesn't notice?
>
> * What happens when the final packet is dropped?
Hal Murray :
> We can do several things:
> 1) clean out the ifdefs that make things work with older versions of
> OpenSSL.
> That is drop support for systems that haven't upgraded their OpenSSL to a
> supported version.
> 2) leave things alone, ignore the RFC.
> Or maybe add some
Hal Murray :
> I don't think it's worth the effort to maintain 2 lists. We can revisit that
> if you think it's appropriate.
No, I agree with you.
> There are 46 syscalls in each list and 55 in the merged list.
Brings up a question. Is the list of all syscalls used by everybody
large relative
James Browning via devel :
> Is there anything preventing the possibility of an early looser
> seccomp setup and then tightening it later possibly with a knob
> to generate terse or verbose warnings instead of dying.
That is a very interesting idea that I think deserves further
examination.
Do
Hal Murray via devel :
>
> Fedora fixed their problem. seccomp now builds and works on both Fedora and
> Arch.
>
> But now it won't build on Alpine. It looks like the same problem that Fedora
> had. The problem is a bug in a header file. Copying the ppoll bits from a
> Fedora header file
Hal Murray via devel :
> Should we drop secomp? It's a pain to maintain.
We're a security-focused prodict. I don't think it would be good optics
to drop a layer of defense just because it's a pain to maintain.
> How many people use it? Richard: do you turn it on for the Debian builds?
I have
Hal Murray via devel :
>
> Context is the seccomp tangle. Issue #633
>
> Should I just add a helper that looks in /etc/os-release?
lsb_release -a might be useful here.
--
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel
Hal Murray via devel :
>
> NetBSD just released version 9.0. It now generates this warning:
>
> ../../ntpd/ntp_control.c:1476:34: warning: '%s' directive output may be
> truncated writing up to 255 bytes into a region of size between 0 and 255
> [-Wformat-truncation=]
>
> char
Hal Murray via devel :
> devel/hacking.adoc says:
> You *may* use clock_gettime(2) and clock_settime(2) calls, and
> the related getitimer(2)/setitimer(2), from POSIX-1.2008.
>
> My man pages say both are in POSIX.1-2001.
>
> Is there any reason we don't pick one and discard the crufty
Hal Murray via devel :
> A year or 2 ago, I put together a script to test as many build time options
> as
> I thought reasonable. It's in ./tests/option-tester.sh
>
> Does anybody other than me use it?
I've run it once or twice, but's not easty to see how to integraste
it into our regularr
Gary E. Miller via devel :
> > So there is nothing you recommend be merged at this time?
>
> I sorta wish NTPsec had a staging area like the Linux kernel does.
>
> There is value to a small and clean u-blox driver fully integrated
> into NTPsec. But without KPPS it is inferior at timekeeping.
>
Hal Murray :
>
> >From devel/hacking:
>
> Only POSIX-1.2001/SUSv3 library functions should be used (a few
> specific exceptions are noted below). If a library
> function not in that standard is required, then a wrapper function for
> backward
> compatibility must be provided. One notable case
Mark Atwood via devel :
> 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
Gary E. Miller via devel :
> Is there an existing patch to remove the fuzzing?
There is not. See my reply to Mark.
--
http://www.catb.org/~esr/;>Eric S. Raymond
signature.asc
Description: PGP signature
___
devel mailing list
Gary E. Miller via devel :
> I just took a quick look at refclock_ubx.c
>
> An interesting start, but followup messsages today on the list are
> assuming this driver does things that it does not do.
>
> 1) It does not, ever, config the u-blox. It does not, ever, write to
> the u-blox to query
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
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
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
Hal Murray :
> Part of the problem is that there is a lot of cruft in that area. For
> example, grep for CERR_
> There is a clump of signals defined as part of a ControlSession, none are
> ever
> raised, a few are caught. Looks like somebody decided to rename things to
> SERR and never got
Hal Murray via devel :
> I know what's going wrong, but I'm not enough of a python geek to see a clean
> fix.
>
> The basic idea is that the client sends a request and the server sends back a
> clump of packets. The client specifies the max clump size. What's happening
> is that at least one
Hal Murray via devel :
> We also need a QuickStart for setting up ntpd: download, build, install,
> test...
>
> There is a quickstart for NTS. It needs a lead-in paragraph that says it
> assumes you are already running ntpsec -- go to link-above if that's not
> correct.
File an issue about
1 - 100 of 805 matches
Mail list logo
