Does the GC stop all threads, or just set a flag so nobody can allocate
anything?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
e...@thyrsus.com said:
> The main source of memory churn is going to be allocations for incoming
> packets, and deallocations when they're no longer referenced anf get GCed.
> Allocations are fast. GC is slow, but isn't performed very often.
Does the low level API for receiving network packets
Sanjeev Gupta said:
> PS: My official reason for not using newer hardware is "I am making sure
> NTPsec and gpsd do not drop support for i386". :-)
There are 2 parts to that.
The first is does it run on 32 bit systems. The second is what distros
support i386.
The latter may be the limiting
On 6/29/21 8:52 PM, Eric S. Raymond wrote:
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
Eric said:
> That's quite exceptionally good. It's normally hard to get to within an
> order of magnitude of that on a LAN, let alone a WAN.
Many years ago, we squeezed room for another digit in ntpq'a printout. That
was the 4th fractional digit of delay, offset, and jitter where the units a
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.
--
http://www.
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 sample
>> I was assuming each refclock would be a separate program. It
>> wouldn't need a config file, just some command line stuff.
> That's a big jump. Backward config compatibility would go out the window.
I'm not sure about that. ntpd could start the program using info from the
server and fud
This is output from my 17 year old server, i386, 32-bit, no TXCO, cheap
hardware, sitting in an airconditioned office where staff keep fiddling
with the thermostat (the large unit is 20 years old, so you are either cold
or very cold).
root@ntpmon:~# uptime
10:20:02 up 14 days, 9:33, 1 user, lo
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
> share
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 measured by the NTP pool
> monitor
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
__
I think you need a good story before we commit to using Go.
> 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.
> turning GC off
Is that l
> I'd like to hear more about this. It sounds like a separate issue from the
> damon split.
> Can't really respond to this as I don't understand the kernel PLL.
Mills wrote some kernel code that did a PLL off of a PPS signal. It, or its
descendents. is available in Linux, FreeBSD, and NetBS
I just fixed the receive timestamp code to use nanosecond resolution rather
than microsecond.
It's a tangle of ifdefs. There is a larger then normal chance that I've
broken something. Please watch a bit more carefully when you are watching
performance.
--
These are my opinions. I hate sp
[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
shared memory forces some build
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 measured by the NTP
pool monitoring system across the Internet.
--
Ri
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 than 1ms. The worst-case jitter
> that could add would be barely above the measurement-noise floor at worst,
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 1
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
>
21 matches
Mail list logo
