Where is the source?
There are lots and lots of typo level glitches I'd like to fix.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Yo Hal!
On Sun, 08 Jan 2017 21:13:49 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > We need to define our terms better. The PPS comes from the GPS! By
> > GPS I was actually referring to the NMEA time from the GPS that is
> > used to match the closest second to the PPS to form the SHM(0)
>
g...@rellim.com said:
> We need to define our terms better. The PPS comes from the GPS! By GPS I
> was actually referring to the NMEA time from the GPS that is used to match
> the closest second to the PPS to form the SHM(0) which is a combination
> of the NMEA and PPS from the GPS.
I was e
Gary E. Miller :
> > That's a separate issue.
>
> Not so separate. A good language makes threading easier, a bad language
> makes it hard or counterproductive. Eric spends more time in languages
> with poor threading, thus a distaste for threading.
Until recently this was quite true.
I will no
Hal Murray :
> > 2. On the next send, adjust the timerstamp by the average of all previous
> > ones.
>
> I can think of a couple of mechanisms that would generate outliers. So I'd
> modify that with something like "Try again if it's too far off". (Which
> assumes you are checking before actua
>> I don't think the I/O waits are important. We need to work
>> correctly when the server is overloaded.
> Serious question: how often does this actually happen? I want to get a feel
> for scale.
The NIST servers have a long tradition of being overloaded.
There was a graph recently on the poo
Yo Hal!
On Sun, 08 Jan 2017 18:40:42 -0800
Hal Murray wrote:
> > Yes, threads will help a lot. I remember when Apache and Mysql
> > started to use good threading. It really helps when you can use
> > all 16 cores on a CPU instead of just one.
>
> That depends on the nature of your problem.
Gary E. Miller :
> > Eric has occasionally said non-good things about threads.
>
> And I 100% agree, if we are talking about Python threads. With the
> GIL the performance is no improvement over single trheaded.
No, my objections were more general. But you are right about Python
threads and the
Hal Murray :
> Interleaved mode can be used only in NTP symmetric and broadcast modes.
> (symmetric == peer)
>
> Looks like we have removed all that.
Yes. Even if were keeping those modes, Daniel found a fatal bug in the
interleave timestamp handling. I'll let him tell the rest, as I only
half
> Yes, threads will help a lot. I remember when Apache and Mysql started to
> use good threading. It really helps when you can use all 16 cores on a CPU
> instead of just one.
That depends on the nature of your problem. In addition to threads, you also
need locks. If most of the work is unde
Hal Murray :
>
> How well do the languages/systems you are considering support threading?
Both Go and Rust have good concurrency support. This is a theme in
pretty much all recent language designs that is driven by the collapse
of Dennard scaling and the ubiquity of multiprocessor systems.
> I
Yes, on top of our having mostly dropped symmetric and peer modes,
interleaved mode was never implemented correctly to begin with. It behaved
as though the time at which send() returns was the time when the packet
left the network card, which is an absurd misunderstanding of how OS
kernels work.
I
e...@thyrsus.com said:
>> Didn't the support for that get removed? Or am
>> I confusing it with something else?
> I think you are, and no blame attaches. What Hal is suggesting sounds a bit
> like interleave mode and drivestamps.
Thanks. "interleave" is the keyword I was looking for.
Google f
Hal Murray :
> The current code wakes up every second. That's evil if you are trying to
> save battery power.
Damn straight it is.
> It should be reasonable to get rid of the timer interrupts. The general idea
> is to look ahead and find the task that will actually do something and adjust
>
Kurt Roeckx :
> On Sun, Jan 08, 2017 at 03:59:51PM -0500, Eric S. Raymond wrote:
> > Susan and I have decided to revive an old idea we were originally going
> > to do in Python and implement it in Rust instead - a better IRC
> > server. Susan has years of field experience with IRC servers written
Kurt Roeckx :
> On Sun, Jan 08, 2017 at 02:37:43PM -0800, Hal Murray wrote:
> >
> > >> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon
> > >> then the daemon can tolerate 'some' jitter.
> >
> > > In normal operation we can expect lots of pairs of small allocations at
> >
Hal Murray :
>
> [Transmit path]
> > No, I'd much rather put in a GC lockout on the critical region than
> > complicate the protocol.
>
> That works if the environment has a GC lockout. Is that a column on your
> features list?
Not explicitly, but there is no way I would *ever* try using a
la
Yo Mathew!
On Sun, 8 Jan 2017 20:04:25 -0500
Mathew Crane wrote:
> Hit send too early. It was my understanding that PPS was the
> canonical time source, and GPS was just a reference. Taken from here:
> http://www.catb.org/gpsd/gpsd-time-service-howto.html#_performance_tuning
We need to define o
k...@roeckx.be said:
>> We could fix that with another packet. The idea is that you
>> get a time stamp from the kernel on the transmit side. Then
>> you have to send another packet to get that time stamp to
>> the other end.
> Didn't the support for that get removed? Or am I confusing it with
Yo Hal!
On Sun, 08 Jan 2017 15:36:47 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > Ths plot is NTP drift vs. temp.
>
> No, that's a plot of temp vs time and another plot from a different
> file of drift vs time.
No, that is a plot of frequency versius time. Clearly stated in
the ntpv
On Sun, Jan 08, 2017 at 04:53:57PM -0800, Gary E. Miller wrote:
> Yo All!
>
> On Mon, 9 Jan 2017 01:30:30 +0100
> Kurt Roeckx wrote:
>
> > > That said, I continue to admire your cut right to the heart of the
> > > issue. ntpd spends enough time in I/O waits that I do not think
> > > latency spik
Yo All!
On Mon, 9 Jan 2017 01:30:30 +0100
Kurt Roeckx wrote:
> > That said, I continue to admire your cut right to the heart of the
> > issue. ntpd spends enough time in I/O waits that I do not think
> > latency spikes will otherwise induce any problems above measurement
> > noise.
>
> The ex
Yo Hal!
On Sun, 08 Jan 2017 16:32:48 -0800
Hal Murray wrote:
> What should our code look like in the long term? Will crypto chew up
> a lot of cycles? Could a busy server support more clients by running
> several threads in parallel on multiple CPUs?
Yes, threads will help a lot. I remember
On Sun, Jan 08, 2017 at 03:51:13PM -0800, Hal Murray wrote:
>
> We should measure the time from grabbing the time stamp to sending the
> packet. That might include some crypto. We might get better results by
> adjusting the time stamp to compensate for that.
Adjusting the timestamp to when yo
How well do the languages/systems you are considering support threading?
I think we should be careful not to over-focus on translating the current
single-threaded code.
What should our code look like in the long term? Will crypto chew up a lot
of cycles? Could a busy server support more cli
On Sun, Jan 08, 2017 at 06:02:36PM -0500, Eric S. Raymond wrote:
> Hal Murray :
> > We don't care about the timing in most of the code. The only critical
> > section is the chunk between grabbing the time and sending the packet.
> > That
> > chunk is likely to involve crypto.
> >
> > We could
The current code wakes up every second. That's evil if you are trying to
save battery power.
It should be reasonable to get rid of the timer interrupts. The general idea
is to look ahead and find the task that will actually do something and adjust
the timeout on the select to go off then. It
On Sun, Jan 08, 2017 at 02:37:43PM -0800, Hal Murray wrote:
>
> >> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon
> >> then the daemon can tolerate 'some' jitter.
>
> > In normal operation we can expect lots of pairs of small allocations at UDP
> > datagram sizes with dea
On Sun, Jan 08, 2017 at 03:59:51PM -0500, Eric S. Raymond wrote:
> Susan and I have decided to revive an old idea we were originally going
> to do in Python and implement it in Rust instead - a better IRC
> server. Susan has years of field experience with IRC servers written
> in C and says they'r
[Transmit path]
> No, I'd much rather put in a GC lockout on the critical region than
> complicate the protocol.
That works if the environment has a GC lockout. Is that a column on your
features list?
> ntpd spends enough time in I/O waits that I do not think latency spikes will
> otherwise
g...@rellim.com said:
> Ths plot is NTP drift vs. temp.
No, that's a plot of temp vs time and another plot from a different file of
drift vs time. If you can capture both at the same time then you can ignore
the time in the file and plot drift vs temp.
http://users.megapathdsl.net/~hmurray/
Hal Murray :
> We don't care about the timing in most of the code. The only critical
> section is the chunk between grabbing the time and sending the packet. That
> chunk is likely to involve crypto.
>
> We could fix that with another packet. The idea is that you get a time stamp
> from the
Yo Eric!
On Sun, 8 Jan 2017 17:48:24 -0500
"Eric S. Raymond" wrote:
> I chose a 100 microsecond target because that's short enough that it
> probably induces jitter of less than 1ms, which is in turn probably
> enough to keep us under the 10ms sustained accuracy I think people
> consider normal
Yo Hal!
On Sun, 08 Jan 2017 14:48:34 -0800
Hal Murray wrote:
> If you modify the code that records the temperature to also grab the
> NTP drift, then you can plot drift vs temperature.
Ths plot is NTP drift vs. temp. The data in /etc/driftfile
is just the Frequency offset written every hour or
Hal Murray :
>
> e...@thyrsus.com said:
> > On the other hand, I don't consider requiring a runtime to be an *intrinsic*
> > disqualifier. The real question is, in my view, the 95th-percentile length
> > of latency-inducing stop-the-world stalls. If it's below 100 microseconds
> > that is almost
> Rarely does a plot of two things look so pretty to me.
Nice. Thanks.
If you modify the code that records the temperature to also grab the NTP
drift, then you can plot drift vs temperature.
You should be able to do something similar by grabbing the CPU cycle counter.
I haven't figured out h
>> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon
>> then the daemon can tolerate 'some' jitter.
> In normal operation we can expect lots of pairs of small allocations at UDP
> datagram sizes with deallocation fairly rapidly thereafter. So the heap will
> have lots of chu
g...@rellim.com said:
> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon then
> the daemon can tolerate 'some' jitter.
That doesn't cover the transmit path.
We need to control the path between grabbing the time and sending the packet.
Delay is not a problem. Jitter woul
Yo All!
Rarely does a plot of two things look so pretty to me.
See attached for a 24 hour plot of NTP frequency offset and ZONE0 (CPU)
temperature. Some of the temp spikes before 07:00 UTC are my room
heater going on and off, and some are CPU load spikes. From 07:00 UTC
to 13:50 UTC the heat wa
Yo All!
For fun. I just ran a 24 scatter plot on an Uputronis V2 GPS HAT.
The Uputronics has a uBlox 8. See attached.
During that time, the Uputronics reported seeing 4 to 20 sats and a TDOP
from 0.42 to 32.6 and a mean of 0.786 and a SD of 0.668.
To bring this back to NTP, when the TDOP hi
Gary E. Miller :
> > * A network service daemon, whether YouTube or NTP in server mode or
> > NTP in client mode, has reqirements that aren't quite as stringent.
>
> My RasPi's, and other servers, have about 1 micro Second jitter
> between them. Anything that makes that even a bit worse is a show
e...@thyrsus.com said:
> On the other hand, I don't consider requiring a runtime to be an *intrinsic*
> disqualifier. The real question is, in my view, the 95th-percentile length
> of latency-inducing stop-the-world stalls. If it's below 100 microseconds
> that is almost certainly good enough.
Yo Eric!
On Sun, 8 Jan 2017 13:30:57 -0500
"Eric S. Raymond" wrote:
> * A network service daemon, whether YouTube or NTP in server mode or
> NTP in client mode, has reqirements that aren't quite as stringent.
My RasPi's, and other servers, have about 1 micro Second jitter
between them. Anythin
e...@thyrsus.com said:
> And by "old stuff" I think you mean specifically Autokey, don't you? To the
> extent I understand these length interactions from having coded the Python
> support, I don't believe either MD5 or SHA-1 MACs are implicated.
I think it's slightly more complicated than that.
Kurt Roeckx :
> On Sun, Jan 08, 2017 at 02:12:21PM -0500, Eric S. Raymond wrote:
> > Kurt Roeckx :
> > > I had a quick look at some of the stats of my peers over internet,
> > > and most actually seem to have an average jitter in the order of
> > > around 100 microseconds. Some are lower, some are
As previously noted, the C cleanup is nearly done. The sockaddr_u
elimination is within a couple of hours of complete; the removal
of interface scanning is a larger problem, but most efficiently tackled
when I can pick Danel's brain about it after the 15th.
This leaves me a gap of 6 or 7 days this
On Sun, Jan 08, 2017 at 02:12:21PM -0500, Eric S. Raymond wrote:
> Kurt Roeckx :
> > I had a quick look at some of the stats of my peers over internet,
> > and most actually seem to have an average jitter in the order of
> > around 100 microseconds. Some are lower, some are higher. So I'm
> > not s
Gary E. Miller :
> Eric S. Raymond writes:
> > 1. Performance and algorithm tuning - we need to take a serious
> > swing at Gary's slow-convergence problem, in particular.
>
> My thinking on this has changed a bit. I'm now more concerned about
> the wackiness that happens on startup. And if th
Frank Nicholas :
> If you haven’t seen [Grumpy], you might be interested. Not sure of the
> quality (experimental?)
>
> Google boosts Python by turning it into Go:
Yes, Gary turned me on to this earlier in the week. Grumpy is extremely
interesting, as a path forward for reposurgeon if not fo
Eric!
Eric S. Raymond writes:
> 1. Performance and algorithm tuning - we need to take a serious
> swing at Gary's slow-convergence problem, in particular.
My thinking on this has changed a bit. I'm now more concerned about
the wackiness that happens on startup. And if that is solved then
(re)
>
>>> 3. Move the codebase to Go or Rust?
>>
>> While I understand what kind of problem you're trying to solve, at the
>> moment I see neither of those two languages survive for long if their
>> current parent projects change course (again).
>
> I'm not worried about that for Go, because Google
Kurt Roeckx :
> I had a quick look at some of the stats of my peers over internet,
> and most actually seem to have an average jitter in the order of
> around 100 microseconds. Some are lower, some are higher. So I'm
> not sure how I feel about adding an other 100 to that.
OK, fair point.
The rul
Kurt Roeckx :
> On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote:
> > On the other hand, I don't consider requiring a runtime to be an
> > *intrinsic* disqualifier. The real question is, in my view, the
> > 95th-percentile length of latency-inducing stop-the-world stalls.
> > If it'
Achim Gratz :
> Eric S. Raymond writes:
> > But how to define that space is itself not entirely clear. One of the
> > more intelligent comments in the (generally high-quality) discussion of
> > the "Getting past C" blog post argued that because ntpd is more like a
> > network service daemon than a
On Sun, Jan 08, 2017 at 07:11:22PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote:
> > On the other hand, I don't consider requiring a runtime to be an
> > *intrinsic* disqualifier. The real question is, in my view, the
> > 95th-percentile length of lat
On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote:
> On the other hand, I don't consider requiring a runtime to be an
> *intrinsic* disqualifier. The real question is, in my view, the
> 95th-percentile length of latency-inducing stop-the-world stalls.
> If it's below 100 microseconds
Sanjeev Gupta :
> Would you consider Julia ?
Alas, a perfect example of a language excluded from present consideration
because the developer and userbase is below the threshold that says
long-term sustainability.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
On Sun, Jan 08, 2017 at 06:35:58AM -0800, Hal Murray wrote:
>
> >> Using the term PLL.
> > But that's how the code is organized. In the absence of a PLL it doesn't
> > slew. Or am I missing something here?
>
> (at least) One of us is confused.
>
> The text from the blog:
> > There are two kin
On Sun, Jan 08, 2017 at 12:40:45AM -0500, Eric S. Raymond wrote:
> Hal Murray :
> >
> > I don't understand your section about the PLL. I think it's tangled up in
> > some bogus terminology. If you say a bit more, I'll try to sort things out.
>
> Alas, "say more" is not really actionable advice
On Sun, Jan 8, 2017 at 9:32 PM, Eric S. Raymond wrote:
> ractically speaking, I don't have time to become fluent in half a dozen
> candidate languages. I can probably budget time for one more beyond Go
> and Rust; Erlang actually seems like a strong contender there.
>
Would you consider Julia ?
Eric S. Raymond writes:
> But how to define that space is itself not entirely clear. One of the
> more intelligent comments in the (generally high-quality) discussion of
> the "Getting past C" blog post argued that because ntpd is more like a
> network service daemon than an OS kernel, Go is a bet
Achim Gratz :
>The real question to
> ask, IMHO, is how many lines of code are implemented in the exact space
> that NTP occupies and how dependent the owners of that code are on
> keeping it working.
But how to define that space is itself not entire
>> Using the term PLL.
> But that's how the code is organized. In the absence of a PLL it doesn't
> slew. Or am I missing something here?
(at least) One of us is confused.
The text from the blog:
> There are two kinds of NTP hosts; one uses a kernel facility known as the
> "PLL" for doing fin
Hal Murray :
>
> > > That sounds uncomfortably plausible. I can think of a workaround: add a
> > > padding extension long enough that the packet can't have any of the magic
> > > lengths.
> > I've read that. I've even implemented it myself once, in the Python
> > protocol back end. Is there ad
Eric S. Raymond writes:
> I'm not worried about that for Go, because Google has sunk a lot of investment
> into million-line Go programs (like running YouTube and the Chrome download
> server). Because those are unlikely to go away, so is its funding case. This
> is actually one of the stronger ar
> > That sounds uncomfortably plausible. I can think of a workaround: add a
> > padding extension long enough that the packet can't have any of the magic
> > lengths.
> I've read that. I've even implemented it myself once, in the Python
> protocol back end. Is there advice in there that I miss
Hal Murray :
>
> > Alas, "say more" is not really actionable advice. Can you tell me what
> > seemed bogus to you?
>
> Using the term PLL.
But that's how the code is organized. In the absence of a PLL it
doesn't slew. Or am I missing something here?
> > MacOS, Windows, and ... damn, I don't
Mark: Heads up! Serious discussion of language migration follows.
Achim Gratz :
> Eric S. Raymond writes:
> > 1. Performance and algorithm tuning - we need to take a serious swing
> > at Gary's slow-convergence problem, in particular.
>
> This objective needs to be defined more properly.
Agreed.
Hal Murray :
>
> [extension fields]
> > That sounds uncomfortably plausible. I can think of a workaround: add a
> > padding extension long enough that the packet can't have any of the magic
> > lengths.
>
> Here is the RFC on that area.
>
> Network Time Protocol Version 4 (NTPv4) Extension Fie
Hal Murray writes:
> What do you mean by "feedforward"?
Project the changes from the expected drift and temperature onto the NTP
loop variables before the actual loop code tries to remove the residual
error. While the loop is closed, this should make the error variables
more white and hence impro
Eric S. Raymond writes:
> 1. Performance and algorithm tuning - we need to take a serious swing
> at Gary's slow-convergence problem, in particular.
This objective needs to be defined more properly. At the moment I'm not
all that convinced that this is a real defect considering the guarantees
tha
strom...@nexgo.de said:
> What I was getting at was that I've had quite good holdover performance
> (<1ms over 47 hours) that I wasn't really expecting to see from something as
> cheap as the rasPi and my improvised "ovenization" (which really is just a
> cardboard box and some bubble wrap plus ru
Eric S. Raymond writes:
> Please consider writing a PLL entry for the glossary that includes
> these pointers and also distills some of your field experience.
The NTP situation is "slightly" more complex since it really uses an
FLL/PLL combination, which makes it considerably harder to ascertain
s
Eric S. Raymond writes:
> However, what I *do* take away is that our drastic reduction surgery
> on the rest of the suite apparently has not accidentally damaged the
> PLL nor screwed up its convergence properties. I find that very
> reassuring.
While that was not in fact my point in my previous p
gha...@gmail.com said:
> The P part is you saying: slight turn, not sharp turn
If you think of a thermometer with a knob rather than on-off, the P adjusts
the knob to get the right temperature. But it doesn't quite get it right.
There has to be a difference between the actual temperature and
75 matches
Mail list logo
