Re: The end of the beginning is in sight

[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 Fields March 2016 https://tools.ie

Re: New blog draft on the TESTFRAME debacle

> Alas, "say more" is not really actionable advice. Can you tell me what > seemed bogus to you? Using the term PLL. > MacOS, Windows, and ... damn, I don't remember which BSD it was (not > FreeBSD). What the oddballs lack is ntp_adjtime(). They can only step, not > slew. Slewing the clock i

Re: NTPsec leap second experience

On Sun, Jan 8, 2017 at 12:42 PM, Hal Murray wrote: > > The PID page has a lot of non-math explanations. It might work better to > scan it first. The way I have explained is it to think of sit next to a learner driver, white-knuckled, and giving advice. The P part is you saying: slight turn, n

Re: New blog draft on the TESTFRAME debacle

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. Can you tell me what seemed bogus to you? > What OSes are the odd-balls?

Re: NTPsec leap second experience

e...@thyrsus.com said: > Thanks, I'll read those. Actually, re-read the first and read the second. The PID page has a lot of non-math explanations. It might work better to scan it first. As background technology in this area, there are also DLLs - delay locked loops. Some FPGAs use them i

Re: New blog draft on the TESTFRAME debacle

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. What OSes are the odd-balls? What makes them odd? Is this just a different API to the kernel that turns into significantly different paths th

Re: NTPsec leap second experience

Hal Murray : > > > I'm somewhat embarrassed to admit that I have understood very little of your > > exposition about this. I'm a software systems architect, not a metrologist, > > and the stuff going on down at the PLL level is still a bit beyond my ken. > > The field is complex. There are big

Re: Testing

Hal Murray : > We should start collecting a list of manual tests to run in preparation for a > release or after a major change. Agreed. Looks like you've made a good start on it. > One obvious one is to make sure that all of the refclocks work. Some of them > have several modes and options s

Testing

We should start collecting a list of manual tests to run in preparation for a release or after a major change. One obvious one is to make sure that all of the refclocks work. Some of them have several modes and options so this can get complicated. Another one from a recent discussion. We sho

Re: NTPsec leap second experience

> I'm somewhat embarrassed to admit that I have understood very little of your > exposition about this. I'm a software systems architect, not a metrologist, > and the stuff going on down at the PLL level is still a bit beyond my ken. The field is complex. There are big thick textbooks on it. W

New blog draft on the TESTFRAME debacle

There's a new draft on the TESTFRAME debacle in the blog repo: _drafts/testframe-the-epic-failure.ad And this runs me out of the ideas I had queued up for blog posts. Others should step up. -- http://www.catb.org/~esr/";>Eric S. Raymond Sometimes the law defends plunder

Re: NTPsec leap second experience

On Wed, Jan 4, 2017 at 2:52 PM, Achim Gratz wrote: > > I've kept to rasPi running through the leap second. > Here's the (very much less exciting than Achim's analysis) dump of the relevant lines from /var/log/syslog on my Ubuntu 16.04 box that was running NTPsec during the leap second. Dec 31 18

Re: NTPsec leap second experience

Achim Gratz : > So I guess the NTP loop actually was already nearly converged after the > GPS burp and before the arrival of the leap second. I'm somewhat embarrassed to admit that I have understood very little of your exposition about this. I'm a software systems architect, not a metrologist, an

Re: NTPsec leap second experience

Achim Gratz writes: > The second one was configured as a stratum1 (via GPS w/ PPS) and > monitoring the PTB servers for reference. Since apparently Jessie has > not been updated with the correct leap second file (it still doesn't > recognize the leap second as a valid datum), the GPS got marked as

Re: The end of the beginning is in sight

Kurt Roeckx : > So 1 question I have is if you care about Windows or not. We do, though not urgently. Some googling indicates that Windows supports wildcard sockets. Do you know how to do source- and destination-address extraction in that environment? -- http://www.catb.org/~esr

Re: The end of the beginning is in sight

Hal Murray : > > > The successful scalarization of both 64-bit timestamp types has now been > > achieved. There's a draft about how this was done in the blog repo: > > _drafts/ > > cant-we-all-just-get-a-long.ad > > How much testing has been done? If you're running any pull from the last thre

Re: The end of the beginning is in sight

On Fri, Jan 06, 2017 at 11:43:01PM -0500, Eric S. Raymond wrote: > (mutt hiccupped. You might see this twice.) > > Kurt Roeckx : > > On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote: > > > and the other is ripping out all > > > the interface-scanning stuff so we lose the dependency

Re: The end of the beginning is in sight

> The successful scalarization of both 64-bit timestamp types has now been > achieved. There's a draft about how this was done in the blog repo: _drafts/ > cant-we-all-just-get-a-long.ad How much testing has been done? TESTFRAME would have helped for this sort of change. I know about l_fp. W

Re: ntpkeygen patch

dfoxfra...@gmail.com said: > But that qualifier is important. I'm not thrilled that we're now relying on > Python's SystemRandom implementation in lieu of libsodium, as I suspect the > latter has a lot more expert eyeballs on it. ... Would it be worth switching to libsodium just so we don't have

NTPsec packages for OpenWRT

Hi, Thank you for your package of ntpd 4.2.8p9 for OpenWRT. I am running this on a TP-Link, with a USB GPS: http://www.pool.ntp.org/scores/58.146.176.233 Are you planning to package ntpsec ? I would be very happy to test this out. -- Sanjeev Gupta +65 98551208 http://

Re: The end of the beginning is in sight

>> Only if they correctly ignore extensions that they don't expect. > What would "not ignoring" look like? If length != 48: Goto Reject > That could be. If it is, we're in the "must design NTPv5" future. But I > don't think we'll know whether we're there unless we field a more > conservative d