>> You have a new toy. The only tool needed is a simple lock.
> Oh? What about the concurrent DNS thread we already have?
The only reason we have a DNS thread is because the current code only has one
thread. If we had a thread per "server" in the config file, they could do DNS
directly.
My co
> 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 than we do.
That does
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
> > > tweak the
> > > protocol a bit so you can se
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 descri
Yo All!
As reported on time-nuts, the Earth is spinning faster, so the chances
of the next leap second being negative leap second continue to go up:
https://datacenter.iers.org/data/latestVersion/bulletinA.txt
DUT1= (UT1-UTC) transmitted with time signals
On Tue, Jul 6, 2021 at 1:40 PM Richard Laager via devel
wrote:
>
> 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 tweak
> >> the
On Tue, Jul 06, 2021 at 12:18:26PM -0500, Richard Laager via devel wrote:
> 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
> >
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 tweak the
protocol a bit so you can send that on the next packet.
Daniel discovered it was bro
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 closes
