Hal Murray via devel :
>
> I'm setup to test things and/or can be good at proofreading, but I don't know
> how to work with merge requests.
>
> I assume there is a simple way to pull them to my local setup. How do I undo
> that if I don't like it?
The MR should have "Check out branch" tha pop
I'm setup to test things and/or can be good at proofreading, but I don't know
how to work with merge requests.
I assume there is a simple way to pull them to my local setup. How do I undo
that if I don't like it?
This seems like it should be part of the main line work flow so I'm surprised
Gary said:
> Uh, oh. Can we please avoid boost? Boost is a PITA. It limits what this
> code can run on.
I have no interest or expectation of using Boost in our code.
I was trying to get some known-to-work code running so we could use it for
debugging/testing.
--
These are my opinions.
Hal Murray via devel :
> The draft has links to two chunks of software.
> https://gitlab.com/MLanger/nts/
> https://github.com/dfoxfranke/nts-hackathon
>
> I started with the second one. It's written in python, looks good. But it's
> client only.
>
> So I looked at the first one. It's c++
Yo Hal!
On Sat, 12 Jan 2019 17:00:24 -0800
Hal Murray via devel wrote:
> So I looked at the first one. It's c++. It needs boost 1.67.
> Fedora is distributing 1.66. I poked around a bit, but not much.
> Boost has a tar file for 1.67, but I didn't see an easy way to set it
> up.
Uh, oh. Can
The draft has links to two chunks of software.
https://gitlab.com/MLanger/nts/
https://github.com/dfoxfranke/nts-hackathon
I started with the second one. It's written in python, looks good. But it's
client only.
So I looked at the first one. It's c++. It needs boost 1.67. Fedora is
dis
This is good feedback. Exactly the sotrt of thing that should come up
in review.
Richard Laager via devel :
> On 1/12/19 8:10 AM, Eric S. Raymond via devel wrote:
> > Please review and test.
>
> Can you please post this as a merge request, so we can use GitLab
> comment/review/approval processes
Eric S. Raymond via devel writes:
> It's all coming back to me now. We couldn't reproduce this when you
> first reported it, either. I tried auditing the interval-change rules in the
> code, but couldn't find any bad smell to investigate further.
Well, please tell me if you found some code that
Eric S. Raymond via devel writes:
> Sure, I thought of that. But if I were to do that I would (as the old hacker
> joke about regexps goes) have *two* problems. That is, two layers of
> configuration interpretation, both attracting defects. See "complicated
> and ugly", above.
The configuration
Hal Murray via devel writes:
>> The easiest is probably to configure the GPS refclock into a private ntpd
>> instance running on a hidden port. Another exposed ntpd then runs in
>> lockclock mode and serves the system time controlled by the hidden instance.
>
> That's a good straw man. Thanks.
On 1/12/19 8:10 AM, Eric S. Raymond via devel wrote:
> Please review and test.
Can you please post this as a merge request, so we can use GitLab
comment/review/approval processes and automated testing?
If not...
+* NIST lockclock mode is now a tinker flag rather than a compile-time
+ option, he
Please review and test.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
>From d244049234e3ae7ed7fcde9f19ac0447cc231e9b
Hal Murray :
>
> >> If we are serious about supporting lockclock, we have to figure out a way
> to
> >> test it. We can probably make something that supports GPSDOs with PPS.
>
> > That, on the other hand, seems to me like a good idea. But I don't have the
> > domain expertise to do it.
>
> I
Hal Murray :
>
> e...@thyrsus.com said:
> > Not only is it possible, I wrote a patch to do it today. Complete with
> > documentation changes. I'll post it shortly - I want it carefully reviewed
> > and tested by others before we merge it, as it touched the loppfilter code.
>
> Are you planning
> The easiest is probably to configure the GPS refclock into a private ntpd
> instance running on a hidden port. Another exposed ntpd then runs in
> lockclock mode and serves the system time controlled by the hidden instance.
That's a good straw man. Thanks. If I understand things, the priva
> OK, then, say, 2.5K requests per second per server. That means to stay ahead
> of the processing load it has to handle the CPU-limited part in 0.4us.
typo: us => ms
--
All of your numbers seem reasonable.
I think you are on thin ice translating packets/second to users. The only
devel@ntpsec.org said:
> Recovery when one of the servers drops out (gets rebooted or disconnected
> from the net or something like that) usually works. What doesn't work is
> that, once in a while (but more often when I start up multiple servers in a
> short time) one of them decides it doesn't
17 matches
Mail list logo
