Re: sockaddr_storage
Yo Hal! On Fri, 27 Jan 2017 01:14:25 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > fallenpega...@gmail.com said: > > I prefer :: tagged IPv6 addresses for IPv4 addresses. No need > > for a redundant flag. > > I don't think that actually works. We need to know if it really is > an IPv4 address or is an IPv4 address reached via IPv6. There is no difference between those two. Just a different way to encode the same thing. > Somebody has > to switch the packet between IPv6 and IPv4. Yes, but NTP does not have to. NTP can just open an IPv6 socket and shove all IPv6 and IPv4 in through that socket. Apache does this, sendmail does this, nginx does this, postfix does this. Very standard and very easy. > We need to know if that > is us or some router/gateway out on the internet. Which is the job of the local OS routing table. Daemons do not need to know routing. Unless, of coure, they are routing daemons. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp8_QNb2vhfp.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
Yo Hal! On Wed, 25 Jan 2017 23:47:01 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > [From gitlab] > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. > > There should be no problem with using the ISC version > > unconditionally. > > I though I saw something about getting rid of --enable-crypto Yes, it is gone. > We currently require libsodium. Do we require libssl? Yes, and yes. > If so, we can > drop the ISC crypto code. Dunno. Been asked before, not answered. > Does libsodium include SHA1 and friends? No. > Do we still need libssl? I think it is for SHA1. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp3mKh97GWn7.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘sys_fuzz * ntp_random()
Yo Achim! On Thu, 26 Jan 2017 19:30:12 +0100 Achim Gratz <strom...@nexgo.de> wrote: > If you had a non-quantized signal to start with you wouldn't need to > add noise in the first place. In the digital world all measurements are quantized. All you can do is make the quant really small. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpptQF72XPKG.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the story on buildbot?
Yo Hal! On Thu, 26 Jan 2017 01:44:22 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > With configure --enable-leap-smear > it gets several warnings, then crashes with: > [104/105] Linking build/main/ntpd/ntpd > ntpd/ntp_timer.c.3.o: In function `check_leapsec': > ntp_timer.c:(.text+0x989): undefined reference to `DTOLFP' > collect2: error: ld returned 1 exit status > > With configure --enable-mssntp > [ 92/105] Compiling ntpd/ntp_timer.c > ../../ntpd/ntp_signd.c: In function ‘send_via_ntp_signd’: > ../../ntpd/ntp_signd.c:212:49: error: ‘xpkt0’ undeclared (first > use in this function) > sendpkt(>recv_srcadr, rbufp->dstadr, xpkt0, sendlen); > ^ > ../../ntpd/ntp_signd.c:212:49: note: each undeclared identifier is > reported only once for each function it appears in Can I get a few more clues? I assume you do not mean the buildbot master. Which buildbot slave? Can you duplicate manually? And you are still using an ASCII email program that is munging UTF8... RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgphAIxv41FUq.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
Yo Mark! On Fri, 27 Jan 2017 18:14:15 + Mark Atwood <fallenpega...@gmail.com> wrote: > If we are going to have an SSL dependency, I have a pretty strong > preference towards WolfSSL It may be the best, but it is not in Gentoo. I suspect few distros have it. As we see from the libsodium mess, using non standard libs is a massive increase in difficulty. > if we are going to have an OpenSSL dependency, it needs to be to the > latest stable OpenSSL release. We gotta support what crap users have. > What would be using an SSL library for, that libsodium does not > already provide? That really needs an audit. waf seems to check for a lot of openssl stuff that is never used. My quick check shows md5 and sha1. And even though --enable-crypto is gone, there are still a lot of #ifdef HAVE_OPENSSL around. > What all are we using libsodium right now for? We use libsodium to read /dev/random, or whatever equivalanet the OS has. libsodium does not support md5 or sha1. OTOH, openssl does have RAND_bytes(). Why do we not use that, and get rid of libsodium? Most projects consider it good enough. And, don't forget, libisc is still in the tree with its own copies of md5 and sha1. Nuke it! RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpXwxYa1nUWv.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
Yo Eric! On Fri, 27 Jan 2017 14:42:16 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Gary E. Miller <g...@rellim.com>: > > And, don't forget, libisc is still in the tree with its own copies > > of md5 and sha1. Nuke it! > > Er, we can't do tha id we wabt the OpenSSL deoendency to be optional. So why does openssl need to be optional? Which of our target OS does not have openssl? Maybe some do for religious reasons, but then they must have libressl or similar. I see no reason to support any OS that does not have some library support for crypto. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpJ2XuUnVRzz.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sockaddr_storage
Yo Eric! On Fri, 27 Jan 2017 15:01:19 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Gary E. Miller <g...@rellim.com>: > > Yes, but NTP does not have to. NTP can just open an IPv6 socket and > > shove all IPv6 and IPv4 in through that socket. Apache does this, > > sendmail does this, nginx does this, postfix does this. Very > > standard and very easy. > > That's interesting. Does this mean we could throw out all > IPV4-specific code and use IPV6 logic everywhere? Yes. > I didn't think an IPv6 accept() would take incoming IPv4 connections Yes. > - is there a way to make it take both? It does by default, if you only open an IPv6 socket. Look at 'man 7 ipv6' Or here: http://man7.org/linux/man-pages/man7/ipv6.7.html "IPv4 connections can be handled with the v6 API by using the v4-mapped-on-v6 address type; thus a program needs to support only this API type to support both protocols. This is handled transparently by the address handling functions in the C library." RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpXXbVTIZkPh.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Copyright dates
Yo Mark! On Mon, 30 Jan 2017 18:58:55 + Mark Atwood <fallenpega...@gmail.com> wrote: > When you create a new file, mark it as follows (updating the year) as > required: [...] Can you add this advice to some doc that is in tree? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpNDRVJQbnXo.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Timings for random
Yo Hal! On Sun, 29 Jan 2017 17:15:05 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > > You can't run out of randomness with RAND_bytes(). > > Would you please say more. The man page says: > >RAND_bytes() puts num cryptographically strong pseudo-random > bytes into buf. An error occurs if the PRNG has not been seeded with > enough randomness to ensure an unpredictable byte sequence. Doesn't that say it? Once seeded it does not run out. > How can I be sure that it has "been seeded with enough"? Use RAND_status() or RAND_event() On Linux you can do: cat /proc/sys/kernel/random/entropy_avail Most sources say entropy past 128 is good enough. As a general rule, don't do important crypto things just after system boot. And be especially careful running in a VM. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp8FlyktU20p.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
Yo Matthew! On Fri, 27 Jan 2017 20:05:14 -0500 Matthew Selsky <matthew.sel...@twosigma.com> wrote: > LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the > build on OpenBSD 6.0 I can only find SHA1 in ntpsec. what am I missing? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpj8q6w6rwiG.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Timings for random
Yo Hal! On Sat, 28 Jan 2017 12:39:02 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz > Stdlib: 100 calls to rand() took 0.021 microseconds each > Sodium: 100 calls to randombytes_buf() took 0.367 microseconds > each > OpenSSL: 100 calls to RAND_pseudo_bytes() took 0.630 > microseconds each rand() and RAND_pseudo_rand() are not random, just psuedo random, thus not for NTP. What about the OpenSSL RAND_bytes()? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpNziWjr7gPE.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Timings for random
Yo Kurt! On Sat, 28 Jan 2017 23:18:01 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > > rand() and RAND_pseudo_rand() are not random, just psuedo random, > > thus not for NTP. > > I have no idea what you're using random numbers for, but if > unpredicable is what you want rand() is probably not what you > want. NTP uses random numbers for three reasons: 1. To generate crypto keys: ntpkeygen 2. To add to the LSB's of time stamps as a nonce 3. To use as fuzz around very small time measurements. The dirst is Python, the later two are C code that will be using only OpenSSL soon. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp0EhwX8wgCO.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Stratum-1 HOWTO tickless confusion
Yo Achim! On Sun, 29 Jan 2017 21:55:31 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > I find that running at the hightest speed, and using ther > > performance governor leads to the best results. > > However, if the system is crashing due to it getting too hot or > pulling too much current from a slightly underspeced PSU, then that > slight performance improvement is moot. I can measure it, so it exists. Big improvments are usually made from lots of little ones. > > I'd be happy to run and publish some tests if you doubt. > > No need, but I know that the jitter from switching the clock up and > down goes away on either setting. Yes, switching clocks worse. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpnwnoE6lOy5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Copyright dates
Yo Mark! On Sun, 29 Jan 2017 07:58:24 + Mark Atwood <fallenpega...@gmail.com> wrote: > > Do they need to be updated? I just noticed one that was 2015. > they don't require updating US Copyright is now generally 70 years after the death of the author. You plan to live that long? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgph48LgQNkLT.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Timings for random
Yo Hal! On Sat, 28 Jan 2017 23:19:32 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > > rand() and RAND_pseudo_rand() are not random, just psuedo random, > > thus not for NTP. > > Do you think fuzzing needs cryptographically strong randomness? You are asking the wrong guy. I'm not sure we need any fuzzing. > I timed RAND_pseudo_bytes() rather than RAND_bytes() because I didn't > want to get mixed up with not enough randomness and it seemed good > enough for what we needed. You can't run out of randomness with RAND_bytes(). And as your later tests showed, they had different performance. > > What about the OpenSSL RAND_bytes()? > > It's slightly faster than RAND_pseudo_bytes() :) ?? Dunno, the point is that it is actually random. > The man page says both will return 1 if the bytes generated are > cryptographically strong. I wasn't able to use up the system > entropy. Seems suspicious. Modern Linux will no run out of entropy, except on startup. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpc8vxzs0yPY.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘sys_fuzz * ntp_random()
Yo Kurt! On Wed, 25 Jan 2017 00:01:43 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > On Tue, Jan 24, 2017 at 10:38:50PM +0100, Achim Gratz wrote: > > sys_fuzz (which whitens the quantization noise on the clock reading) > > doesn't make a difference or you might not. But presumably Dave > > Mills didn't put it in there just because he was trying to add > > useless code. > > So it seems to me that this is the wrong order, you first add the > noise and then do the quantization, not the other way around. The quantization noise is already in the time read from the system.. clock_gettime() has a resolution of one nano Second, but depending on the host, it increments in steps that are a lot bigger. ntpd tries to determine that minimum increment and store it in sys_tick. Annoying there was no way to read that variable that I could find. Now there is a way, just pushed to git head, new option: ntpq -c 'rv 0 tick' Results are in milli Seconds. Here is what I get on a Xeon: spidey ntpsec # ntpq -c 'rv 0 tick fuzz' fuzz=0.000202, tick=0.000202 Tick seems to equal fuzz. About 202 nano Seconds. Table time: Xeon: fuzz=0.000202, tick=0.000202 skylake:fuzz=0.000109, tick=0.000109 RasPi: fuzz=0.003,tick=0.003 RasPi2: fuzz=0.001823, tick=0.001823 RasPi3: fuzz=0.000937, tick=0.000937 mac mini: fuzz=0.0005, tick=0.001 Pretty much sys_fuzz == sys_tick. Except that mac! Looks like ntpd is built to handle a lot of complexity that no longer exists in my test platforms. Except that mac... looks like sys_tick can be less than sys_fuzz. Anyone got the reverse case? RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp1aJMOFVhqQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzzMime-Version: 1.0
Yo Kurt! On Wed, 25 Jan 2017 18:25:09 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > All my real amd64 boxes show: > [0.540511] Switched to clocksource hpet > [3.327348] Switched to clocksource tsc Ditto for mine, My RasPI Ar [0.689988] clocksource: Switched to clocksource timer My RasPi 2 and 3: [0.207033] clocksource: Switched to clocksource arch_sys_counter RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpfgmXfqIxNB.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘sys_fuzz * ntp_random()
Yo All! To follow up on my own mistake... On Wed, 25 Jan 2017 16:52:58 -0800 "Gary E. Miller" <g...@rellim.com> wrote: > Xeon: fuzz=0.000202, tick=0.000202 > skylake: fuzz=0.000109, tick=0.000109 > RasPi:fuzz=0.003,tick=0.003 > RasPi2: fuzz=0.001823, tick=0.001823 > RasPi3: fuzz=0.000937, tick=0.000937 > mac mini: fuzz=0.0005, tick=0.001 My eye slipped. sys_tick is greater than sys_fuzz. > Anyone got the reverse case? Does anyone ever see sys_fuzz > sys_tick? Hmm, measure_tick_fuzz() in ntpd/ntp_proto.c ensures sys_fuzz <= sys_tick. So that is answered. Can't happen. systime.c has this odd code: if (sys_tick > sys_fuzz) quant = sys_tick; else quant = 1e-6; Not sure why that last line is not quant = sys_fuzz. I distrust magic constants. Not sure it even matters. Prolly for legacy adjtime() that only support micro Seconds? Not gonna worry about it if it is just old Macs. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp501VIeGTJJ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Kurt! On Fri, 20 Jan 2017 19:53:00 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > > Nope. ntpd clearly tells me that my jitter is 100 micro Seconds. > > I get the same results using chronyd. > > Yes, but i think you're saying your resolution is 1 ms. No, my resolution is 1 nano Second. That is the LSB on the system clock. Note I do not claim accuracy near that. > > No, there is jitter on that of 1 mS to 0.1 mS. > > I have no idea why you always write S or Seconds. The correct SI > unit is s, not S, and it's also just second. Is this some German > capitalization thing? Being a native born USA citizen, with USA citizenship going way back, it is unlikelly to be a German thing. I am well aware of SI units. You will note that we in the USA join with the great countries Libya and Myanmar it not using SI units. Unlike the rest of the world. I choose to converse with people, of many languages and cultures, in ways that cause the least confusion. I find I get the least requests for clarification when I spell out my units, as in: nano Seconds. That said, you know what I meant, you just have a hard time groking it. > > > First, even though the PPS signal is only once per second, you're > > > really measuring the pulse, and you could say you're measuring > > > that with a resolution of 1 ms. > > > > No, the resolutin of my measurement is the resolution of the system > > clock. > > But you only check about every 1 to 2 ms as I understand it. I was > under the impression that you talked about that as your > resolution. Normally you would call that the sample period, but > we're measuring time here which always confuses things somewhat. Certinaly not a sample period. To me a sample period implies and average over time, that is NOT the case here. > In this case jitter and precision really are the same thing. But > if what you're measuring isn't time they're different things. Sadly we keep running into word definition conflicts. 'NTP precision' is not at all related to 'measurement precision' and we keep flipping back and forth conflating those terms. In the NTP context, 'NTP precision' is just 'NTP jitter' smoothed and bounded on a longer time scale. I wish I could explain it better, you'll just have to look at the code. > But I have no good other term other than the sample period / > frequency. It will clearly limit your accuracy, but it's not the > accuracy itself. NTP seems to be calling this precision. Just forget 'sampler period', it has zero relevance here. > > > You would instead need to modify the output of the PPS > > > signal to add random jitter to it, so that it doesn't always > > > happen every 1024 polls. > > > > That would be many mS of jitter. Also not good. > > This might be counter intuitive, but adding noise can improve your > results, but it needs to be white noise. But there are usually > other ways to improve things to, like having a higher sample rate > in this case. It can sometimes, and it will not other times. My direct observation validates that statement. Depends on many things. > > The precision can be 10e6 worse than that sys_fuzz. > > > > Once again, we really need an NTP specific dictionary because NTP > > defines things in unusual ways. > > Oh, I do agree that NTP is confusing the terms, and I hope we can > at least agree on how they are used now. Well, first we have to figure it out ourselves. So much of the detail is mushes into long forgotten code, patched by many people that did not understand. > ntp returns for me: precision=-23 Which precision? NTP has a sysclock precision and a precision for each peer, erver and refclock. In almost all those case it is calculated from that clock's jitter which is likely around 0.1 micro Second. > That means it can read my system clock at a rate of 2^23 times per > second, Uh, no. Totally unrelated. The rate NTP can read the system clock is sys_fuzz. Calculated from totally different underlying data using totally unrelated algorithms. For where/how sys_fuzzz is calculated see other email o nthis list in the last day. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpUvkgTT2j9o.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Precision and accuracy
Yo Kurt! Note I have changed the Subject of this thread as it no longer had any relationship to libsodium. And before we can continue, for clarity, I'm going to try to define a few terms. Given the terminology swamp that is NTP, do not try too hard to apply this to the same words defined and used differently by NTP. Even worse NTP is not self consistent. Context is everything. Many will disagree with my terms, for those that do, just think of the names I use as random variable names and try to follow the concept. I worked for, and later with, John Fluke, Mfg. Co., Inc. For those that are too young, John Fluke was David Packard's roommate and also founded his own metrology equipment company. I continue to use the terminology and framework they drilled into their people and users. To make this a little easier to visualize, I'll walk you through a metrology demo I saw, and gave, many times over many years. I spare you the full 30+ minute canned presentation and go directly to some interated result values. Imagine in front of you are two handheld voltmeters, and a super precision voltage source. Both of the voltmeters are what are called "three and a half digit" voltmeters. They can read from 0.000 Volts to 2.999 Volts. To make it simple, assume no autoranging, or even any ranging at all. What is the 'precision' of these two voltmeters? To me, the precision is the LSB on the display, in this case: 1 milli Volt. So the No-Name $5 meter is the same precision as the $250 Fluke meter, right? I certainly think so. Precision is just the smallest unambiguous unit that I can measure. So why do people pay so much more for the Fluke? Time to hook up the 12 digit, 1ppm, NIST traceable calibrated voltage reference to both meters, one at a time. I set the voltage standard to 0.95000 Volts. Feed that 0.9500 Volts into the cheap meter. The cheap meter reads exactly 1.000 Volts. Or maybe I had to feed in 1.05000 Volts to get 1.000 Volts on the cheap meter. Now, what is the 'precision' of the cheap meter? I say it is still 1 milli Volt. What is the 'accuracy'? I say it is 5% off. The cheap meter has a 5% accuracy. Now plug in the Fluke meter. I feed in the same 1.0 Volts and I read on the meter 1.000 Volts. How accurate, NIST traceable, would you say the Fluke meter is? You guess 0.1%? Maybe, maybe not. Now I set the calibrator to 1.00049 and the meter still reads 1.000. I set the meter to 1.0005 and the meter changes to read 1.001. How accurate is the meter? I say the meter is accurate to 0.001% The Fluke meter can in fact reliably, repeatably, NIST traceably, differentiate between two inputs that are only 0.001% apart! When that Fluke meter said a voltage was 1.000, you know it was between 0.99951 Volts and 1.00049 Volts. You could in fact use it to accurately, repeatedly, NIST traceably tune a voltage divider to 1.000 Volts +/-0.001% Compare that to the cheap meter that is only 5%. And yet they both have a precision of 0.1%. The canned demo in fact went into much more depth, and covered more topics, but I think this illustrates the way I frame measurements. To summarize, in my lexicon, precision is just how many digits I can resolve. Accuracy is how close a measured value is to a traceable standard. Accuracy can be much larger or smaller than precision. None of this to be confused with how NTP defines precision. And NTP never uses the word accuracy. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpdcabbu_xer.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Problem with GPSD refclock
Yo Hal! On Thu, 26 Jan 2017 11:29:17 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > > Check out the M.2 standard. PCIe + USB on one connector: > > Is that PCIe + USB or PCIe or USB? It is PCIe and USB, at the same time, on the same connector. M.2 is weird, it has a ton of key options, supporting different buses. There is PCIe and USB 2.0 on the A, B, and E key options. Check this out: https://en.wikipedia.org/wiki/M.2#Form_factors_and_keying Open up most any laptop, you will find an M.2 Wifi/BT card in there. The wifi is on the PCIe bus and the BT is on the USB bus. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgphp8S_AeQih.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the story on buildbot?
Yo Hal! On Thu, 26 Jan 2017 12:28:44 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > > Right now, except for known problem children (Solaris, ARM cross > > compile, etc.) buildbot is all green. > > But it didn't catch a batch of problems. Yup, nor can it be expected to. > > buildbot only builds two configurations. One default with no > > refclocks. One default with all refclocks. > > > No overhead left to do generic options. > > I'd suggest adding --enable-leap-smear and --enable-mssntp to the > all-refclock run and no-debug to the no-refclock run. IMHO, leap-smear is an obimination, and debug should never be left out. AFAIK mssntp is broken. And no need to test thos things every build. Maybe you could write a script that can be run to build in a bunch of ways. That could be run occasioalnly. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpFweREWRxY3.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the story on buildbot?
Yo Hal! On Thu, 26 Jan 2017 22:24:48 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > > And no need to test thos things every build. > > Can you test them on a few of the less busy bots? buildbot is not very smart. I have no idea how to do that. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp03Dtr3rqGI.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzz
Yo Hal! On Tue, 24 Jan 2017 14:40:13 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > > You gotta squint real hard to see that as stiction, but not worth=20 > > debating the proper word. So it may have mattered back then, but > > do we need to carry this legacy code. > > Stiction is when something that should go smoothly goes in jumps. > That seems like a reasonable description of a clock that gets updated > by timer ticks with no interpolation. Fair enough. We need our own dictionary. > > The has nothing to do with clock steps, this has to do with how > > fast the clock can be read. > > That may be what a comment, but I'm pretty sure the idea is to help > with the case of a clock that takes big steps. According to my reading of the bug, the sys_fuzz is just for a nonce in the LSB of network timestamps. The rest of the code around it is to ensure monotonically increasing. Also some hint it may help loop stability. Sadly the Bug comments do not match up with the actual code very well. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp06PndQBuiF.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘sys_fuzz * ntp_random()
Yo Eric! On Tue, 24 Jan 2017 16:42:42 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Achim Gratz <strom...@nexgo.de>: > > You might have enough other noise in any particular system so the > > sys_fuzz (which whitens the quantization noise on the clock reading) > > doesn't make a difference or you might not. But presumably Dave > > Mills didn't put it in there just because he was trying to add > > useless code. > > That's what bothers me, that I don't know what we was thinking. Grr, you motivated me to actually research this. Dr. Mills was in the discussion, but it is not exactly primordial. sys_fuzz was added in 2011: commit b24b87c768265963557e1abb9a859490f929c057 Author: Dave Hart <daveh...@gmail.com> Date: Sat Dec 17 02:30:42 2011 -0500 [Bug 2037] Fuzzed non-interpolated clock may decrease. Bug 2037: http://bugs.ntp.org/show_bug.cgi?id=2037 It seems most of the bug is about making the clock monotonic and increasing, not about anything else. The main point of the fuzz seems to be: "This strategy preserves the nonce value of the low-order bits of timestamps on the wire," To my mind, as long as the random fuzzing is below sys_fuzz, and it is, then for my purposes it is too small to worry about. OTOH, if it gets in the way of something in the future I'd toss it out. Just preserving the nonce aspect. > Mark, is it time to try to open contact with Mills yet? I'm not sure this is the issue, but why wait? He should know about the current lives of his spawn. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpgBoJdxjDdw.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘sys_fuzz * ntp_random()
Yo Achim! On Wed, 25 Jan 2017 18:36:13 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > Dr. Mills did not put it there. This was added in 2011 by Dave > > hart. See my previous email that probably crossed by yours in > > flight. > > The way I read things, Dave Hart's patches were to ascertain > monotonicity on top of the already existing fuzzing. Yes. I was saying that sys_fuzz was new then, and the algorithm had a serious complexity upgrade then. So what happened before 2011 not very relevant anymore. > > It proves that sys_fuzz does nothing on a RasPi. At least > > undetectable over 4 days. I give you it proves nothing about other > > systems. > > The fuzz we are talking about is added to outgoing timestamps, so when > it did something it wouldn't be discernible on the server, but on the > client receiving that timestamp. In other words, you are looking at > the wrong end of the data (I think). No, the fuzz we are talking about is added to everything. One place the fuzz is added is in libntp/systime.c in normalize_time() which is called from get_systime(). Everyplace ntpd gets a time it now uses get_systime(). Except two oddball drivers: jjy and oncore. > > I'll once again raise the challenge to someone else to prove it > > actually does something, somewhere. No point involving deities or > > more bike shedding, give me data! > > You can make such requests ad inifinitum, but it won't help. Unless > you know what exactly the problem was that fuzzing solves, you won't > be able to pick out that set of data that shows you whether it is or > is not still needed. And by your own argument, you are not adding anything either, until you find a real problem space. > > Now knowing more about bug 2037 I'm also confident that the > > characteristics of the RasPi clock where not those being fixed in > > bug 2037. > > That bug was about monotonicity of the timestamps, not the fuzzig > itself, IIRC. Yes, but it caused the creation of sys_fuzz and the current fuzzing scheme. > Again, you need to know what problem this code was solving (before the > patches from Dave Hart, which were solving a different and probably > more specific problem most likely) in order to know if the > assumptions that made it necessary or useful still hold. I thought bug 2037 , and the bug 2037 fixed, explained that nicely. Do you know something else not there? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpc79gDUysaL.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzzMime-Version: 1.0
quot;coarse" clock (without breaking "fine" clocks) by > > > reading the clock in a loop until the value changes. This > > > approach is completely neutered by a uniqueness kludge. > > > > I do not see how that helps NTP, just adds latency. > > Of course. But in *some contexts* it's useful, and it's broken if > the OS insists on corrupting the time in the name of uniqueness. Since NTP does not use CLOCK_MONOTONIC this a supposition on a fact that does not apply to NTP. Off topic. > > > The clock_getres() function is supposed to report the actual clock > > > resolution, which is what should determine the amount of dither, > > > but in practice it's rarely correctly implemented. E.g., in the > > > Linux cases I've tested, it ignores the hardware properties and > > > just retuns 1ns. > > > > And it probably can not even determine the hardware properties. > > It knows perfectly well what the actual (or at least nominal) > oscillator frequency is, since otherwise it wouldn't be able to > convert the counter values to standard time units. It just can't be > bothered to use it for clock_getres(). Way more unknowns than clock frequency. But not relevant, clock_getres() says not to trust it, so why do we even talk about it? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpnDu4AcpDII.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzz
Yo Eric! On Tue, 24 Jan 2017 21:54:13 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > > Thus the need to not trust the clock and the need for > > normalize_time() > > Sure. But if my new understanding is correct, all *this* problem > requires is stepback protection, not fuzzing. Please check me on > that. Worst case, lots of migration could make the TSC look a bit > like a random variable with a very low frequency of collisions > (proportional to (2^64)^-2 by birthday effect); filtered through the > stepback check this would look a lot like fuzzing. Worth a shot. Handle the birthday effect by using Lambert Rule #3. Just increment. My gut feeling is you are right, but I'd like to get some good edge cases. NTP runs on so many hosts with so many different sys clock implementations that guessing all the failure modes would be problematic. > > I'm not expecting it to be renmoved, but I feel better that it will > > not mutate badly. Might even get better comments now. The > > timestamp nonce has value for all hosts and maybe other lurking > > benefits. As long as any fuzz added is less than sys_fuzz then no > > host I see will be negatively impacted by it. > > It's a judgment call I'm not going to make yet. I'd like to collect > the code simplification, and I think this analysis shows it's a safe > thing, but I want to hear what Hal has to say and meditate on all > this some more. Yeah, way down the priority list. Something to noodle on for a long while. Knowledge to keep under your hat for when a bug pops up in this area. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpfCjHWR38wW.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Big endian success
Yo Sanjeev! On Wed, 25 Jan 2017 07:28:52 +0800 Sanjeev Gupta <gha...@gmail.com> wrote: > > > > I have been asking OSUOSL for more horsepower. > > > > > > I can provide a more "hefty" box. 4GB RAM, 4-core VM? Or more? > > > > I would need ssh access, install buildbot and run a web server on > > it. > > > On its way to you. Cool. I guess I'd better prepare a bit. I can make it a secondary buildbot master, then switch over when it looks good. > Debian or Ubuntu server or Centos? If it is up to me, I'd go Gentoo. Debian would be my 2nd choice. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpWSBZkuDVwn.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzzMime-Version: 1.0
Yo Fred! On Tue, 24 Jan 2017 15:22:20 -0800 (PST) Fred Wright <f...@fwright.net> wrote: > On Tue, 24 Jan 2017, Gary E. Miller wrote: > > > Last week we had a discussion on sys_fuzz and the value of adding > > random noise to some measurements. The code defi2nes sys_fuzz asL > > > > "* The sys_fuzz variable measures the minimum time to read the > > system > > * clock, regardless of its precision." > > > > Rondomness of half the sys_fuzz is then added to some values, like > > this: > > > > fuzz = ntp_random() * 2. / FRAC * sys_fuzz > > > > Makes no sense to me. Adding randomness helps when you have > > hysteresis, stiction, friction, lash and some other things, but > > none of those apply to NTP. > > Basing it on the time to *read* the clock definitely makes no sense, > although I suspect one would have to dig back fairly far in the > history to determine the source of that confusion. Just look at that commit, and compare to the bug report. The confusion is obvious there... > If one is dithering, the amount of dither should be based on the > clock's actual resolution, *not* the time required to read it. In a > sampled system, one would add dither equal to the quantization > interval, in order to produce results statistically similar to > sampling with infinite resolution. For time values, one would add > dither equal to the clock's counting period, to produce results > statistically similar to a clock running at infinite frequency. Possibly, but that is not how it works now. And would it be an improvement? Bring on the experiments! > > There is an additional worm in this can. Some OSes with crappy > > clocks bumped the clock by a tiny bit each time you read it so that > > all clock-reads returned different results and you could use it for > > making unique IDs. > > That's not uncommon, but it's a really bad idea. Demanding that a > clock always return unique values is an unwarranted extension of the > job description of a clock. Well then, you just said the current NTP implementation is a bad idea. In practice, with nano Second resolution clocks doing CLOCK_MONOTOMIC is not hard. > The proper way to derive unique values > from a clock is to wrap it with something that fudges *its* values as > needed, without inflicting lies on the clock itself. Sorta circular since NTP reads the system clock, applies fudge, then adjusts the sysclock t match. > Also note that in some contexts it's reasonable to extend the > resolution of a "coarse" clock (without breaking "fine" clocks) by > reading the clock in a loop until the value changes. This approach > is completely neutered by a uniqueness kludge. I do not see how that helps NTP, just adds latency. > 1) If it's a "coarse" clock, then dithering destroys monotonicity. Did you read the bug report? That is exactly what was happening, and worse, Thus the fix. > 2) Determining the proper amount of dither isn't necessarily easy. Yup. > The clock_getres() function is supposed to report the actual clock > resolution, which is what should determine the amount of dither, but > in practice it's rarely correctly implemented. E.g., in the Linux > cases I've tested, it ignores the hardware properties and just retuns > 1ns. And it probably can not even determine the hardware properties. > I'm not convinced that sub-microsecond dithering is worthwhile, > anyway. If the dithering code is retained at all, it might make sense > to have a configure test that reads clock_getres(), and only enables > dithering support if the result is more than a microsecond. That > test would be unaffected by the aforementioned lies in > clock_getres(). Though there'd need to be a way to force dithering > on for testing, since it's unlikely that any test platforms would use > it naturally. And those sorts of configure tests are problematic for > cross-building. Even the clock_getres() man page warns the return values may return "bogus results". Next... > BTW, if the only use for randomness is for computational dithering, > and not for security, then there's no need for crypto-quality > randomness. So far that looks like the case, plus adding a nonce in the LSB's of timestamps. But that will not last, the autokey replacement should be here 'soon'. This year or next. > In that case, why not just read /dev/urandom directly > and dispense with the whole libsodium mess? All ntpd uses libsodium for is to read /dev/urandom, and for the many cases that /dev/urandom does not exist, or better exists, then some other way. I'd rather see it go too, but I see no easy path to get there. RGDS GARY --
✘ntpclient names
Yo All! Eric wants all ntp programs to start with 'ntp' and not have hypens. So, how about: gps-log -> ntpgpslog temp-log -> ntptemplog makeheat -> ntpmakeheat Suggestions? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpH_NE_cbQlq.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [Bug] 1361811cb botches unused macro
Yo Achim! On Mon, 20 Feb 2017 19:38:52 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > I am unclear which macro you are referring to? I thought were you > > talking about REFIDLEN, that is used a lot. > > The patch inadvertently removed the continuation line from > LEN_CRYPTO_TO_ZERO, which makes the macro define an incomplete > expression. I'm not sure how that could have been unclear if you've > actually looked at the offending commit or the patch section I've > copied into my post. Clearly you understand this better than I. Patch please? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpVIoy9CsDvh.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: clockvar reporting from generic (DCF77)
Yo Achim! On Mon, 20 Feb 2017 19:43:39 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > Can you provide a few more details? Like how your refclock is > > setup in your ntp.conf and where the output you showed comes from? > > The refclock is configured in the usual way Pardon my ignorance, since I've never used that refclock, what it 'the usual way' you are using? > and I'm talking about the > output of 'ntpq -c "cv &1"'. Unable to replicate, not surprising as I do not have that refclock. Can you verify the same thing happens with ntpmon? Can you verify your ntpq version? (ntpq --version) I suspect the problem is back in ntpd, which is sending bad mode 6. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpGzYV7XJxKM.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: DCF77 driver seems to be broken
Yo Achim! On Mon, 20 Feb 2017 21:23:48 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Subject: [PATCH] Fix parse and DCF77 refclock > > include/timespecops: Remove misleading definitions of the result > coding of the ternary comparison macros (the comments in that file are > still wrong). [...] Nice. Thanks you. Pushed. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpsvAjHVS9mx.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: DCF77 driver seems to be broken
Yo Achim! On Sat, 18 Feb 2017 22:15:56 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > There is nothing in C++, as defined by Stroustrup, that you can not > > do in C. > > You know, I've actually used Cfront and read all of Stroustrups books, > so please spare me that lecture. OK. > There also is nothing in higher programming languages that you cannot > do in assembler. All higher-level languages are there to express the > concepts and algorithms more clearly and succinctly than that. If you > subscribe to the hypothesis of a constant density of bugs in newly > written software, then less LOC mean less bugs. It's quite a bit more > complicated than that, but reducing LOC has never hurt in my > experience (mostly with numerical code, YMMV). There is such a thing > as code that gets too cryptic for it's own good, but that seems to > come mainly from using the wrong abstraction level or getting too > enamored with some language feature. And your point, relavant to the task at hand, is? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpmExEDAbnth.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Achim! On Wed, 22 Feb 2017 18:21:01 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > Mark was thinking of a separate ntp-tools package or option. Many > > distros has a X package and a matching X-tools package. We could > > make that easy with a build option. > > > > I see the vast majority of users only using ntpd. > > > > But seriously, do you really need to save USD$0.001 of disk space? > > I'm pretty sure that Hal was more concerned about not putting stuff > on a public-facing server that wasn't absolutely necessary. Then 90% of your distro is probably also not absolutely necessary. If your attacker can run things on your CLI then it is long past game over. > You'd > want that for an audited system, like the "sec" part in NTPsec > implies should be possible. I've never had that come up in an audit. Every open port gets thorughly looked at, but not miscellaneous programs in /usr/bin. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpQIKgYr7h96.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: INSTALL and buildprep
Yo Hal! > Hal Murray <hmur...@megapathdsl.net>: > Does buildbot have a crossbuild case? Say building for a Raspberry > Pi on an Intel platform. Yes, but not one that is working. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpNovukh3rnk.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Royce! On Wed, 22 Feb 2017 12:50:39 -0900 Royce Williams <ro...@tycho.org> wrote: > > Nothing we do says an admin can't "rm /usr/bin/XXX". I often have > > that in my build scripts. No need to clutter the build options for > > that. > > Bespoke downstream file removal has its place -- but there's a > break-even point. > > IMO, it's better for projects to provide a reasonable baseline > client/server split. It allows the project to express a broad, > informed recommendation about where the split should occur. It also > allows the project to change that split in a controlled and > long-term-ecosystem-friendly manner if the need arises. In the NTPsec case, the client is the server. So not a good cleave point. Ditto the tools NTPsec ships are for both client and server. So not a good cleave point. We have already imagining a split into an ntpd package and an ntpd-tools package. So just a matter of what goes where. > Splitting client and server is also very appliance- and > embedded-friendly. Anyone doing an appliance or embedded server will already be making their own install scripts. I expect 99% of NTPsec installs to not be done with our scripts, but with distro specific scripts. Just for starters most people install binary packages and NTPsec does not go there, that is for the distros to do. Our scripts are just for developers and for packagers to get a start. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpeQqYsEUTzr.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Information lost when switching to buildprep
Yo Hal! On Wed, 22 Feb 2017 13:26:54 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > Gary said: > >> 2) It drags in a big pile of stuff, starting with gnuplot. > > No. > > At least one of us is confused. > > buildprep installs gnuplot unconditionally. Perhaps you mean that it > doesn't need to do that. But currently it does. buildprep is optional. We already agreed to make gnuplot optional in buildprep. Next? > What does ntpviz do without gnuplot and/or why would I want to do > that? It makes plot files and dumps statistics summaries. The plots can then be plotted elsewrhere. I forsee a future option where it just outputs the text summaries. Just way down on my list. > If I have to move the processed data to another system to view > it, Some will, some will not. Some might use ssh to run a server copy of gnuplot from the ntpd host. Do with it as you wish. > why not copy the raw log files and do all the processing there? The plot files are potentially a lot smaller. > The old text in INSTALL had comments about something being needed at > run time or only at build tiime. That information is no longer in > buildprep. Yeah. Patches welcome. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp8nWm9uDHlQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Hal! On Thu, 23 Feb 2017 03:41:53 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > > Our scripts are just for developers and for packagers to get a > > start. > > I think we can do a better job of providing the information that a > packager needs. No argument there. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpXlXAQkITrc.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘libntp.a unused?
Yo Gary! On Fri, 24 Feb 2017 15:51:54 -0800 "Gary E. Miller" <g...@rellim.com> wrote: > Is there still a point to libntp.a? I see it being built, but never > used or installed... Uh, never mind. I found it used 5 places... RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpVjxY9za4Qv.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘libntp.a unused?
Yo All! Is there still a point to libntp.a? I see it being built, but never used or installed... The tests do not use it, the tests compile their own copies of the C files in libntp.a RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp4DKNrQXYij.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Extra precision for avgint field in ntpmon (#247)
Yo Hal! On Wed, 22 Feb 2017 04:09:13 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > We (at least I) want the extra precision so we can tell how bad > abusive clients are. I sent something saying that, but it didn't > make it to the issue tracker. +1 RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpeYz94A94v4.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [Bug] 1361811cb botches unused macro
Yo Achim!
On Sun, 19 Feb 2017 13:50:16 +0100
Achim Gratz <strom...@nexgo.de> wrote:
> While hunting for changes that might have affected the DCF driver I've
> come across this gem:
>
> --8<---cut here---start->8---
> @@ -433,7 +433,13 @@ struct peer {
> #define CRYPTO_TO_ZERO(p)((char *)&((p)->clear_to_zero))
> #define END_CRYPTO_TO_ZERO(p)((char
> *)&((p)->end_clear_to_zero)) #define LEN_CRYPTO_TO_ZERO
> (END_CRYPTO_TO_ZERO((struct peer *)0) \
> - - CRYPTO_TO_ZERO((struct peer
> *)0)) +
> +/*
> + * It's ugly that refid is sometimes treated as a uint32_t and
> sometimes
> + * as a string; that should be fixed. Using this in memcpy() at least
> + * contains the problem.
> + */
> +#define REFIDLEN sizeof(uint32_t)
>
> #define LEN_PKT_NOMAC 48 /* min header length */
>
> --8<---cut here---end--->8---
>
> Luckily the macro isn't used anywhere, so it's not been doing any
> harm. In fact, all three CRYPTO macros are unused and can be
> eliminated.
I am unclear which macro you are referring to? I thought were you talking
about REFIDLEN, that is used a lot.
Can you be specific on which macros you think can be removed?
I think you mean these three?
spidey ntpsec # fgrep CRYPTO_TO_ * -r
include/ntp.h:#define CRYPTO_TO_ZERO(p) ((char *)&((p)->clear_to_zero))
include/ntp.h:#define END_CRYPTO_TO_ZERO(p) ((char
*)&((p)->end_clear_to_zero))
include/ntp.h:#define LEN_CRYPTO_TO_ZERO(END_CRYPTO_TO_ZERO((struct
peer *)0) \
If you canfirm I'll remove them.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
pgp8kb_57jsMZ.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Generic doesn't log into clockstat
Yo Achim!
On Sun, 19 Feb 2017 13:18:12 +0100
Achim Gratz <strom...@nexgo.de> wrote:
> It seems that the generic clock driver doesn't log into clockstats.
> The GPS NMEA driver on the other hand does. If there's a flag or
> configuration option to enable that seperately, I've not found it.
> I'm not sure if that was ever working, however I think it should be
> fixed anyway.
Here is how refclock_nmes writes to logstats:
/*
* If extended logging is required, write the tally stats to the
* clockstats file; otherwise just do a normal clock stats
* record. Clear the tally stats anyway.
*/
if (peer->ttl & NMEA_EXTLOG_MASK) {
/* Log & reset counters with extended logging */
const char *nmea = pp->a_lastcode;
if (*nmea == '\0') nmea = "(none)";
mprintf_clock_stats(
peer, "%s %u %u %u %u %u %u",
nmea,
up->tally.total, up->tally.accepted,
up->tally.rejected, up->tally.malformed,
up->tally.filtered, up->tally.pps_used);
} else {
record_clock_stats(peer, pp->a_lastcode);
}
The key funciton is mprintf_clock_stats(), which is nowhere to be
found in refclock_generic.c. Looks like a flag bit would need to
be added, and a write to clockstats of what you find interesting.
Each refclock writes a different style clockstats. So tell us what you
would like logged.
RGDS
GARY
-------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
pgpkDihoRHVcn.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: DCF77 driver seems to be broken
Yo Achim! On Sat, 18 Feb 2017 21:30:33 +0100 Achim Gratz <strom...@nexgo.de> wrote: > Eric S. Raymond writes: > > I'd revert this, but I didn't understand it well enough to avoid > > breaking it. Can you supply a fix patch? > > > > If not, file an issue and I'll give it a try. > > I'll first have to understand what all the original functions were > doing and then what the replacements do differently. Say what you > will, but that stuff is crying for C++ to encapsulate the various > datatypes used… NTP code loves to make everything into individual global variables. Feel free to roll things into structures and organize. There is nothing in C++, as defined by Stroustrup, that you can not do in C. C++, until the commitee messed it up, was just a different syntax that made existing best practice a bit simpler to code. Plus adding some new warnings. You are the only person we know with a DCF77... RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpQnDA2Rc3e6.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Eric! On Tue, 21 Feb 2017 17:13:54 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > > We need to figure out how to handle ntpviz and friends. I think it > > should NOT be part of the standard install set. At a minimum, > > there should be an easy way to skip it during install. > > I've forgotten. What's the actual problem with including ntpviz in > the standard install? I think Hal objected to installing gnuplot, which does pull in a number of packages. ntpviz does not require gnuplot to run, or even to install, just a pain to use w/o it. gnuplot is a huge 1.4 MB, but it can pull in a lot of other packages (X, qt4, etc.) if you are not careful. I have no objection to having ntpviz be an install option, most people will never use it. But seems silly for just 1.4MB. And a lot of more important waf stuff to fix first. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpxTa8d4nysp.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Fw: [Git][NTPsec/ntpsec][master] Address GitLab issue #247: Extra precision for avgint field...
Yo Eric! I object to this. We need better float formatting, not worse. Let NTPClassic keep their bugs to themselves. Commits: 253de053 by Eric S. Raymond at 2017-02-21T11:04:54-05:00 Address GitLab issue #247: Extra precision for avgint field... = pylib/util.py = --- a/pylib/util.py +++ b/pylib/util.py @@ -583,12 +583,6 @@ class MRUSummary: else: favgint = active / (entry.ct-1) avgint = int(favgint + 0.5) -if 5.0 < favgint or 1 == entry.ct: -stats += " %6d" % avgint -elif 1.0 <= favgint: -stats += " %6.2f" % favgint -else: -stats += " %6.3f" % favgint if entry.rs & ntp.magic.RES_KOD: rscode = 'K' elif entry.rs & ntp.magic.RES_LIMITED: RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin Title: GitLab Eric S. Raymond pushed to branch master at NTPsec / ntpsec Commits: 253de053 by Eric S. Raymond at 2017-02-21T11:04:54-05:00 Address GitLab issue #247: Extra precision for avgint field... This tracks a post-fork change in Classic. 1 changed file: pylib/util.py Changes: pylib/util.py ... ... @@ -583,12 +583,6 @@ class MRUSummary: 583 583 else: 584 584 favgint = active / (entry.ct-1) 585 585 avgint = int(favgint + 0.5) 586 -if 5.0 < favgint or 1 == entry.ct: 587 -stats += " %6d" % avgint 588 -elif 1.0 <= favgint: 589 -stats += " %6.2f" % favgint 590 -else: 591 -stats += " %6.3f" % favgint 592 586 if entry.rs & ntp.magic.RES_KOD: 593 587 rscode = 'K' 594 588 elif entry.rs & ntp.magic.RES_LIMITED: ... ... @@ -599,8 +593,8 @@ class MRUSummary: 599 593 try: 600 594 if self.showhostnames: 601 595 dns = canonicalize_dns(dns) 602 -stats += " %4hx %c %d %d %6d %5s %s" % \ 603 - (entry.rs, rscode, 596 +stats += " %6d %4hx %c %d %d %6d %5s %s" % \ 597 + (avgint, entry.rs, rscode, 604 598 ntp.magic.PKT_MODE(entry.mv), 605 599 ntp.magic.PKT_VERSION(entry.mv), 606 600 entry.ct, port[1:], dns) — View it on GitLab. You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings. ___ vc mailing list v...@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/vc pgp7qqto_yvPm.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Hal! On Tue, 21 Feb 2017 13:01:35 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > >>gps-log -> ntpgpslog > >> temp-log -> ntptemplog > >> makeheat -> ntpmakeheat > > > That works for me. I'd make 'em shorter if I could, but don't see > > any obvious way to do that that wouldn't reduce them to garble. > > Those names aren't going to be typed by hand very often so I don't > think the length is important. I type temp-log by hand all day. But I agree, that is a very rare use case. Actually, I use bash history and autocomplete, so length does not matter to me either. So I don't care about length either. Got something you prefer that is longer or shorter? > As long as they don't get installed, I don't think the ntp prefix is > important. A hyphen after the ntp might make them easier to read. The first does get installed. The second might be installed soon. > We need to figure out how to handle ntpviz and friends. I think it > should NOT be part of the standard install set. At a minimum, there > should be an easy way to skip it during install. Mark was thinking of a separate ntp-tools package or option. Many distros has a X package and a matching X-tools package. We could make that easy with a build option. I see the vast majority of users only using ntpd. But seriously, do you really need to save USD$0.001 of disk space? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp5dM2yBfvzW.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpclient names
Yo Hal! On Tue, 21 Feb 2017 14:58:33 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > e...@thyrsus.com said: > > I've forgotten. What's the actual problem with including ntpviz in > > the standard install? > > 1) General clutter for the 99% who won't use it. Yes. > 2) It drags in a big pile of stuff, starting with gnuplot. No. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpBaWnVQ_M8U.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: current HEAD is broken on old gcc (and warnings on current clang)
Yo Fred! On Mon, 13 Feb 2017 13:26:31 -0800 (PST) Fred Wright <f...@fwright.net> wrote: > On Mon, 13 Feb 2017, Gary E. Miller wrote: > > On Mon, 13 Feb 2017 13:02:49 -0800 (PST) > > Fred Wright <f...@fwright.net> wrote: > > > > > I suggest reverting 287a00b9a until a more judicious way to apply > > > the appropriate options can be worked out. > > > > Sorry, can't do that. Can only move forward, not back. > > I contend that any properly conditional means of adding those flags > will look completely different from 287a00b9a, so the change as it > stands has no value (not to mention negative value on some > platforms). I've already locally reverted it just to get something > that isn't broken. Feel free to do what you will in your private branch. Better yet, just wait a day. > > > Note that one can always get > > > the same effect temporarily for testing just by specifying > > > CFLAGS/LDFLAGS on the command line. > > > > Except doing that with buildbot is a PITA. > > Don't the buildbots have a way to specify environment variables? > Travis certainly does. > > It would also be useful to have the buildbots feed from a testing > branch, so that the master branch doesn't get used as a testing > sandbox (e.g., 016eda025/4ca79909a). I inherited a pretty cranky buildbot structure. In theory what you say is true, in practice it is a PTIA. And a pointless PITA to customize buildbot for each worker since that is the purpose of waf. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp_TPKrnJkKx.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Timekeeping oddities on MacMini G4s
Yo Hal! On Sun, 05 Feb 2017 19:47:37 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > strom...@nexgo.de said: > >> # ntpq -c 'rv 0 frequency' > >> frequency=-0.928558 > > Make that number go into the loopstats file as well? I don't > > suppose I should log the output of ntpq to benefit from that extra > > precision. > > Is anybody actually running gear where more than 3 fractional digits > is interesting? I'm not saying this happens often, but this is from on one of my RasPi's: Local Clock Frequency Offset Percitiles: Min -4.475 ppm 1% -4.397 ppm 5% -4.390 ppm 50% -4.377 ppm 95% -4.363 ppm 99% -4.361 ppm Max -4.357 ppm Ranges: 90% 0.027 ppm 95% 0.036 ppm StdDev 0.009 ppm Mean-4.377 ppm Notice the Standard Deviation: 9 ppb! See attached. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpObHQXcDSEL.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: current HEAD is broken on old gcc (and warnings on current clang)
Yo Hal! On Mon, 13 Feb 2017 01:18:58 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > Debian wheezy > gcc (Debian 4.7.2-5) 4.7.2 > > [96/97] Linking deb/main/ntpd/ntpd > /usr/bin/ld: libntp/pymodule.c.2.o: relocation R_X86_64_PC32 against > symbol `progname' can not be used when making a shared object; > recompile with -fPIC /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status Yes, reported yesterday. I'm working on a solution. What I need to know is the breakpoint between gccc versions that fail and those that work. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpIC0NP6wJ9I.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpkeygen patch
Yo All! No better patches than Greg Rubin's have appeared, so I have marged his patch. The system call ntpkeygen uses will block in Python 3.6 when not enough entropy is available. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpudwNxOZUtA.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Eric! On Thu, 19 Jan 2017 17:23:01 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Gary E. Miller <g...@rellim.com>: > > Yo Eric! > > > > On Thu, 19 Jan 2017 14:30:35 -0500 > > "Eric S. Raymond" <e...@thyrsus.com> wrote: > > > > > Gary E. Miller <g...@rellim.com>: > > > > > - to fuzz the low-order bits of the clock. > > > > > > > > Hmm, can you expand on this a bit? Which clock? How much fuzz? > > > > Does this degrade anything? > > > > > > Whenever ntpd polls the system clock, it fuzzes the lowest-order > > > digits of the result. The amount of fuzz to apply is bounded by > > > half the measured interval between system clock ticks. > > > > Hmm, and how much would that typically be? > > I...don't actually know. Probably less than a microsecond. I little less than a micro Second would concern me. A lot less would not. > It > should be available as the value of the system variable > "fuzz" (internally sys_fuzz) but I see > > ntpq> rv 0 fuzz > fuzz=0.001 > > which makes me suspect a units problem somewhere. ntpd/ntp_proto.c line 2639 says the units are Seconds. If true that makes your sys_fuzz 1 milli Second. So adding a bit of randomness around 500 micro Seconds. That is terrible. 500x worse than we can see in the PPS refclock. > > Can you point me to this code? I want to rip it out and do a > > test. > > libntp/systime.c On line 65 it says that sys_fuzz is in seconds! That agrees with ntp_proto.c. So still terrible. > Have fun. You'll probably do a better job of ayditing that code than > I would. Very interesting stuff. It will have to wait until the libsodium thing is put to bed. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpVX_qLYpr55.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Introducing buildprep
Yo Eric! On Thu, 19 Jan 2017 17:00:31 -0500 (EST) e...@thyrsus.com (Eric S. Raymond) wrote: > There is now an executable script named "buildprep" in the top-level > directory that attempts to automate the job of installing build > perequisites. Not there. I just did this: kong ntpsec # git pull Already up-to-date. kong ntpsec # ls atticdocs libiscLICENSE ntpdigntpsweep pylibwaf buildetc libjsmn NEWSntpfrob ntptime README wafhelpers contrib include libntpntpclients ntpq ntptrace testswscript develINSTALL libparse ntpdntpstats ntpwait VERSION www kong ntpsec # RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpsMwBY8KRBN.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Kurt! On Thu, 19 Jan 2017 23:11:18 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > > In my GR-601W experiments I can show it would be bad. > > I really have no idea what kind of experiment that was, but I > doubt that it somehow has an ADC. That is getting the most accurate time possible onto an NTP server that only has a USB bus. > > I'm worried about 1 micro Second or less. And one should not > > confuse accuracy with resolution. A PPS signal only has a > > resolution of one Second, but can eaaily have an accuracy of 10 > > nano seconds. > > Please don't confuse accuracy with precision. I'm not sure your 10 > nano seconds is the accuracy or precision, both are possible, but > I think you're talking about precision. The accuracy is probably > not that easy to measure. You are right, I probably should have said the resolution of the PPS is just one second That PPS just fires once a second. There is no way to tall anything about anything, except that one moment in time at the top of the second. I tend to use precision interchangeabley with resolution. The number of significant digits past the second is zero. If you doubt a PPS is accurate to 10 nano Seconds then head over to time-nuts. They'll give you an earfull. I'm happy just to know that the ACCURACY of when the PPS pulse happens is quoted as 10 nano Seconds on the data sheets of many GPS. Other GPS only claim 1 micro Second. By accurate I mean that you can sompare it to an atomic clock that is NIST traceable and get an offset less than that number. > > A signal on a USB 2.0 bus can only have a resolution of about 1 > > micro Second, but that can be locked to a PPS to 100 micro Seconds > > jitter. > > I'm not sure what you're trying to say. Each USB 2.0 device is polled 1024 times a second. So you would think you could only sync time over a USB 2.0 bus to 1/1024th of a second. About 1 micro Second. But that is not true, you can sync time over USB 2.0 to 100 microseconds. If you said the resolution is only 1 micro second, and you added 500 micro Seccond of jitter, you would make the sync 5 times worse, not better. > But if you're talking about jitter, you're really talking about > the precision. NTP uses yet another definition for precision, so it is confusing. NTP calculates precision from jitter. NTP precision (not accuracy) is assumed to be slightly worse than the jitter. The NTP precision can be no better than the jitter. Conversly the NTP jitter is better than the precision. In my experiments the NTP precision and the NTP jitter are about 100 micro Seconds, but the accuracy (NTP offset) does wander, slowly, the expected 1 micro Second. So the top of the scond on the system clock may not be at the right place, but the length of a second is held to 10x better. Maybe the raw data and graphs will help: https://pi.rellim.com/day/ That is a GR-610W on a RasPi version 1, so not the best test bed, but what I have running right now. > > > But I'm currently not really sure that it either improves > > > things, make things worse, or has no effect at all. > > > > Hal does not think it is in the measurement path at all. If it is > > then it will be eauy to do some testing. > > As far as I understood, the packets that go out have their > timestamp adjusted to add a random value. Well then, there is a lack of consensus on where the randomness is used. Further investigation required. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpxp4I8kA4pm.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Eric! On Thu, 19 Jan 2017 13:32:20 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > > waf errors out when it can't find sodium.h even if you haven't > > configured with --enable-crypto > > That is correct behavior. The code uses ntp_random() - which calls > libsodium And sad we need a crypto library just to get random numbers, but it seems so, at least for now. > - to fuzz the low-order bits of the clock. Hmm, can you expand on this a bit? Which clock? How much fuzz? Does this degrade anything? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp_A3VMUSCKH.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Hal! On Thu, 19 Jan 2017 12:03:51 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > > At first glance this seems reasonable, but my experience with the > > GR-601W suggests otherwise. My experience with the GR-601W shows > > that ntpd can find a timing edge and hold onto it very well. > > The fuzz we are talking about has nothing to do with where the time > comes from. It's the precision slot in ntpq rv 0 Precision? Mine is -22 on my server. Or am I looking at the wrong thing? > I think it's left over from the old days when the clock was update on > the scheduler interrupts. With the current code, it's how fast you > can read the clock. So, no rason to keep it? RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpiUsdhfKJfW.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Kurt! On Thu, 19 Jan 2017 21:20:23 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote: > > Gary E. Miller <g...@rellim.com>: > > > > - to fuzz the low-order bits of the clock. > > > > > > Hmm, can you expand on this a bit? Which clock? How much fuzz? > > > Does this degrade anything? > > > > Whenever ntpd polls the system clock, it fuzzes the lowest-order > > digits of the result. The amount of fuzz to apply is bounded by > > half the measured interval between system clock ticks. > > > > That shouldn't degrade anything. I presume it's a measure to foil > > timing attacks of some sort. Daniel might be able to say more. > > Adding random (white) noise to a measurement is done to improve the > resolution after averaging, it's ussually in combination with > oversampling. Adding this white noise is done in the analog signal, > before you convert it to digital. Yeah, I have seen that before. It can be good, or it can be bad. In my GR-601W experiments I can show it would be bad. > And I guess improving the resolution was important > when on some systems you have a resolution in the order of 1 to 50 > ms. I'm worried about 1 micro Second or less. And one should not confuse accuracy with resolution. A PPS signal only has a resolution of one Second, but can eaaily have an accuracy of 10 nano seconds. A signal on a USB 2.0 bus can only have a resolution of about 1 micro Second, but that can be locked to a PPS to 100 micro Seconds jitter. > But I'm currently not really sure that it either improves > things, make things worse, or has no effect at all. Hal does not think it is in the measurement path at all. If it is then it will be eauy to do some testing. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp9jXn4PaEG3.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
ence in time it can see is about sys_fuzz. Basically how fast the clock can be read and/or the smallest tick in the clock that it can see. Not to be confused with the LSB of the read system clock. The precision can be 10e6 worse than that sys_fuzz. Once again, we really need an NTP specific dictionary because NTP defines things in unusual ways. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp82G0lXWk5F.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
Yo Eric! On Thu, 19 Jan 2017 14:30:35 -0500 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Gary E. Miller <g...@rellim.com>: > > > - to fuzz the low-order bits of the clock. > > > > Hmm, can you expand on this a bit? Which clock? How much fuzz? > > Does this degrade anything? > > Whenever ntpd polls the system clock, it fuzzes the lowest-order > digits of the result. The amount of fuzz to apply is bounded by half > the measured interval between system clock ticks. Hmm, and how much would that typically be? > That shouldn't degrade anything. I presume it's a measure to foil > timing attacks of some sort. Daniel might be able to say more. At first glance this seems reasonable, but my experience with the GR-601W suggests otherwise. My experience with the GR-601W shows that ntpd can find a timing edge and hold onto it very well. Whe ends up is there will be an offset of up to 1/1024 sec from the correct time, but the jitter is much less. Can you point me to this code? I want to rip it out and do a test. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpqEOT9uxF_K.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Bounding the target platforms
Yo Hal! On Wed, 01 Mar 2017 15:24:08 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > RFC1589 describes an in-kernel PLL that synchronizes the system clock to an > external PPS signal. RFC1589 is what the kernel did in 1995. Mills had input to an update to the in kernel PLL in 1999. I have no idea about any changes after that. A quick search of git log showed no changes there for a while. > Some/many OSes/distros don't ship a kernel that supports the > in-kernel PLL. In particular, it isn't available in Linux when > compiled with NO_HZ. I think that is an implementation detail rather > than anything fundamental. NO_HZ saves power on idle systems. It's > important for battery life on laptops. NO_HZ is gone in Linux 4.10. If is sort of replaced by CONFIG_NO_HZ_IDLE CONFIG_NO_HZ=y is the default in all in tree defconfig's. > I think it is likely that we would get results similar to the > in-kernel PLL if we copied the code to user-land and called it as > soon as the PPS data was available. Would be an interesting check. The code is in kernel/time/time.c > We should work on a NO_HZ version of ntpd. ntpd works just fine with NO_HZ_IDLE. I'm not sure how it exactly compares to the other 2 options; NO_HZ_FULL and HZ_PERIODIC. But I agree it could be better at power awareness. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpHHwIDOSSaA.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Feature Removals, NMEA GPS
Yo Achim! On Sun, 26 Feb 2017 17:56:51 +0100 Achim Gratz <strom...@nexgo.de> wrote: > I'd like to ask for this driver to be retained until it's eventually > replaced by matching functionality in the generic parse driver > framework. It may well be that gpsd is technically superior, but the > additional hassle of setting things up for it counts against it. What hassle? Just install and run, gpsd auto configures. > Also > it can't be assumed that a system that has ntpsec also has gpsd > available (at all or in a reasonably current version) and ntpd should > be able to use a GPS unit without it. Pretty hard to find a distro that does not have gpsd in their packages. Got one in mind? I'll go bug them. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpd4k0OlJafZ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Precision and accuracy
Yo Achim! On Sun, 26 Feb 2017 13:58:36 +0100 Achim Gratz <strom...@nexgo.de> wrote: > That list of definitions already exists since at least the year 2000, > so maybe you'll read up on it there: > https://www.ijs.si/time/ Interesting, but a bit dated and I do not totally agree with their definitions. Nor do many of them agree with existing NTPClassis and NTPsec usage. > > Many will disagree with my terms, for those that do, just think of > > the names I use as random variable names and try to follow the > > concept. > > Claiming the Humpty-Dumpty privilege usually doesn't improve the > communications. Lost me there. I defined my terms before I used tham. Maybe in the future you prefer if I say Parameter1 and Parameter2 so not to get confused with other random definitions of the same terms to mean different things. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpxh2Jb5pjz5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Feature Removals, NMEA GPS
Yo Hal! On Mon, 27 Feb 2017 04:24:02 -0800 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > > What hassle? Just install and run, gpsd auto configures. > > Autoconfigure can be a bug or a feature. > > It can be great if it does what you want. > > I often have more than one serial device plugged into a system. It's > a bug if gpsd messes with the ones I don't want it to touch. gpsd never touches a serial port it was not told to touch. I think you are confusing gpsd autoconfig with when distros use the -F option and auto plug. I agree that is not a good way to run gpsd. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpmamHrbHHIu.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PPS documentation
Yo Achim! On Sun, 26 Feb 2017 14:29:59 +0100 Achim Gratz <strom...@nexgo.de> wrote: > The kernel PPS documentation in docs/kernpps.txt still mentions > PPSkit as the PPS API provider on Linux. PPSkit has not seen a > release since 2007 and was replaced with the integration of LinuxPPS > into the mainline kernel somewhere in 2009. I do not see anything in that file I disagree with. Can you be more specific on what you dislike in there? > It should probably be mentioned that hardpps is not available even > with the PPS API present on most distributions since it is > incompatible with a tickless kernel, something that became standard > somewhere in the 3.x line of Linux kernels ca. 2012. Ah, no. KPPS works better on kernels with a tick, but not incompatible with tickless. And most tickless kernels distributed by distros have the option at boot time to change the tick configuration. Certainly RasPian is that way. Can you be more specific on a kernel that does not work? I'm not even sure how much better going 1kHz tick is than the other options. I'll run some tests. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpTHIpdMeacm.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Comments about ntpviz
Yo Hal! On Tue, 23 Aug 2016 01:53:35 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > I have a script that uses rsync to collect the log files from various > machines. Eric is working on something like that. > Mostly, I plot 2 days, yesterday and as much of today as is available. So two graphs, one for today and yesterday? ntpviz can do that. > There are more kludgy scripts that split -peer into > -peer- ntpviz does that. > A lot of the graphs I'm interested in need two scales, one that shows > everything and another that ignores the outliers and shows the main > stuff. For those, I add something like: > set yscale [xx:xx]; replot > pause -1 Yeah, I do see that is handy now and then. > I have a few graphs that are long running, months. For those, I > typically use different colors on odd/even days, and another pair of > colors for alternate months. Here are a couple of samples: Looks like a holiday tree, I find it hard to ficus on the red/green pairs. > Some of gnuplots colors are hard to see, at least on my setup with my > eyes. Yellow is the worst case. Yeah, if you have any specificc suggestions on how ntpviz can fix that. But please no red/green barber polls... > If a server is down for a while, the long straight line linking over > that gap looks ugly to me. Yeah, a down server is ugly. It should be shown ugly. > Using microseconds for everything is hard to read for long delays > typical of network links. In bufferbloat cases, I see delays of > several seconds. I've seen delays of 10s of seconds. I can't count > all those 0s quickly. I think milliseconds would be better. (Looks > like Gary tweaked things while I was typing this in.) Yup, I'm working on autoscaling. A lot more to do. I'm thinking of just clipping the outliers ( < 0.5%, > 99.5% ) with a text message of the worst ones > The round trip time is interesting, especially if you have a > bufferbloated DLS link. Yes. Dan Drown had those. They are in the work queue. > If you assume that both your local clock and the server's clock are > accurate, you can get the network transit delay in each direction. > If you plot that you can match steps in the round trip time with > steps in a particular direction. An interessting idea, but NTPsec needs to focus on core ntpd needs until those are nailed down. > There is interesting data in clockstats, at least for some drivers. > One of the important ones is the count for the PPS driver. It's real > interesting if your PPS pulse isn't wide enough to work all the time. Yeah, been looking at that. Since ntpd is undersampling the PPS it can be either good, or real bad. I'm tempted to get Eric to fix the bug first, but maybe I'll need to data so he sees the bug first. > If you have a busy server, there is interesting stuff in usestats. Such as? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpvdvQv_bS3U.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: â ntpviz ±(rtt/2)Mime-Version: 1.0
Yo Hal! On Wed, 07 Sep 2016 16:53:06 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > I prefer RTT rather than RTT/2. > > RTT/2 suggests that the routing is symmetric which is wrong quite > often. . RTT/2 was what Dan Drown used, I'm not sure I care either way. Either way, RTT, or RTT/2, the impression from the graph is of symmetry. So I don't see one is better than the other... RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpXX1W_x2Skc.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: â ntpviz ±(rtt/2)Mime-Version: 1.0
Yo Hal! On Wed, 07 Sep 2016 16:53:06 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 Time to get a better email client, yours is mangling my UTF-8 when you respond to me RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpZzh1xFdVoR.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Stratum one autonomy and assumptions about GPS
Yo Eric! On Thu, 25 Aug 2016 00:19:46 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote: > This was going to be a note to just Hal originally, but it will do the > rest of the team no harm to know more about the scenarios and > assumptions driving some of my design choices. > > Hal objected (off list) to me drawing a conclusion from today's > offset multiplot that check servers aren't necessary when you have > a local GPS - a Stratum 1 really can run autonomously. He said, > correctly of course, that the check servers aren't there to improve > time accuracy when the GPS has sat lock, but to backstop the GPS when > it flakes out. > > I shall now discuss three interlocking reasons this possibility does > not loom as large in my mind as it does in Hal's. > > 1. GPS outage length and frequencies are decreasing Don't care. If you need your NTP to work, you need to know it is working. Otherwise failure are not noticed. > 2. The autonomy scenarios I think about are not hobbyist-budget > productions Yeah, and the big biys REALLY need to know their NTP is right. > 3. There's a lower bound below which outages don't matter; we may be > there. I don't agree. I monitor all my services 24x7, and I do get NTP problems in my logs. > Any given fixed accuracy target for deviation from UTC, combined with > a maximum crystal drift rate, defines a longest tolerable GPS outage. Not the majority failure mode. > We may already be at a technological place where GPS outages don't > bust the tolerable-error budget, even with cheap hardware. If we > aren't, we'll probably be there soon. We can't define a single tolerable error budget. We can provide some ranges of options for the user. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpaaxhDoxlFQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Stratum one autonomy and assumptions about GPS
Yo Hal! On Thu, 25 Aug 2016 15:30:25 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > e...@thyrsus.com said: > > I have a USB thermometer on order, they're cheap. Might I suggest > > you get one and repeat this experiment, actually plotting your > > temperature variation? > > Most CPU chips include a temperature sensor. Which I have found does not correlate with any of my NTP data. I now have a lot of data, just need to finish up the ntpviz temp module. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgps41ssZY_xi.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Comments about ntpviz
Yo Hal! On Wed, 31 Aug 2016 00:38:58 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > > I'm noty sure how this appies to ntpviz??? > > I was trying to describe what I'm doing currently and what I like and > don't like about it. > > The current ntpviz makes a bunch of graphs as files and puts a web > page wrapper around it. Yes. > I'd like to avoid that and put the output of > gnuplot directly on the screen. So ignore the html and just look at the png output graphs with the png viewer of your choice. You could multipane, 3D wheel, carosel, etc. Or a simple Python script with some GUI buttons. > I'd also like a bunch of knobs so I can tweak the graph I'm looking > at. Most likely zoom in or out. > I assume all that would be reasonably simple after I knew how to do > it, but it hasn't gotten to the top of my list yet. Pretty much any pnng viewer can do that. Granted the png resolution may be too low, but that is an easy fix. > > Since the graphs are every 30 mins or hour, I'm not sure what you > > are trying for? > > I'm not interested in automatically making graphs for somebody else > to look at. I'm only interested in "now", when I want to look at > things. > > A frequent thing that happens is that I see something interesting on > a graph and then want to look more carefully at a graph I was looking > at a few seconds ago. ntpviz only takes 20 seconds to run on a Pi3 for me, ant then I have all the graphs. Or just ask ntpviz for the one graph you want, prolly about a second, RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgps1T4_QOwkC.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PPS undersampling
Yo Hal! On Wed, 31 Aug 2016 01:19:49 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > > Saving power is good, but I suspect the extra power is minimal. I > > hace USB power meters, so we can measure this. > > It depends on the details. You can save a lot of power by turning > stuff off. The more you turn off, the more power you save but the > longer it takes to get running again. I think most CPUs these days > have an instruction that is roughly "halt and wait for an > interrupt". That lets the CPU turn off the clock for the instruction > unit so it doesn't have to burn power running a tight loop. As an > experiment, you could write some code that goes into a tight loop and > see if that takes more power than not running anything. All I care about is how it affects ntpd. As long as ntpd does a usleep() the OS will do the right thing. > The next step is things like putting the memory into self refresh > mode or turning off the disk controller. Turning those off is a deep sleep. That will not work for ntpd. > USB is ugly to power down since there aren't any interrupt wires. Yup, not gonna happen. > In the extreme, you can power off the clock generation circuit. And then there is no point in running ntpd. > Your USB power meter should work for a Raspberry Pi or BeagleBone. I > assume you have a wall-power meter for a laptop or desktop. Yeah, but they all average over a good part of a second. Nothing ntpd does will move the (virtual) needle. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp8lhTE7PH7a.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: How much do we care about high-load scenarios?
Yo Eric! On Wed, 14 Sep 2016 17:22:51 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Gary E. Miller <g...@rellim.com>: > > Sadly, unless you have threading there is no way to A/B test it > > against no threading. So let us not rip out any existing threading > > until it gets tested. > > There isn't threading any there to rip out, except for the one hack > to avoid stalls on DNS lookups. Different part of the code. Oh, well then it becomes just another feature on the todo list, near the bottom until there is a demonstrated need. I suspect NIST, Apple, M$ and a few others have the problem. If they need a solution they'll ask, and help. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpNvVvmxhNN3.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: How much do we care about high-load scenarios?
Yo Eric! On Wed, 14 Sep 2016 16:41:47 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Eric S. Raymond <e...@thyrsus.com>: > > John D. Bell <j...@systemsartisans.com>: > > > *If* I were the architect on this project (thankfully I'm not!) I > > > would get the code simplified and streamlined in single-thread > > > mode as far as possible, and then design and code a > > > POSIX-threading-conformant "improvement". > > > > That is exactly the contingency plan I have unless Higher Authority > > (Mark and LF) tells me we need to do something else and do it now. > > I should amplify that a little. > > I will not willingly take the complexity hit of multithreading > *anything* until I see benchmark numbers demonstrating a bottleneck > that can be effectively addressed in no other way. It's not good > enough to just handwave and say "high load, we gotta optimize" - > without measurements optimization is premature and you know what > *that* means. Sadly, unless you have threading there is no way to A/B test it against no threading. So let us not rip out any existing threading until it gets tested. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgplbPJlBOQic.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘Python broken %
Yo All!
Yet another undocumented Python failure:
i>>> d = {}
>>> d[1] = "one"
>>> d[2] = "two"
>>> str(d[2])
'two'
>>> echo "%s(d[2])s" % locals
File "", line 1
echo "%s(d[2])s" % locals
^
SyntaxError: invalid syntax
Python says %s(x)s works for any x that str(x) works.
Here is the Python doc:
https://docs.python.org/2.7/library/stdtypes.html#string-formatting
"'s'String (converts any Python object using str())."
WRONG!
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
pgpGAwwVttFBr.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
✘namedtuples overly limited
Yo All!
2nd Python undocumented limitation:
https://docs.python.org/2.7/library/collections.html?highlight=namedtuples#collections.namedtuple
namedtuples makes no mention of a limitation on the number of elements in
a namedtuple.
But:
>>> a = collections.namedtuple('a', 'b', 'c', 'd', 'e')
Traceback (most recent call last):
File "", line 1, in
TypeError: namedtuple() takes at most 4 arguments (5 given)
RGDS
GARY
-------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
pgpSoDgZLaZMY.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
✘Python 3!
Yo All! Good progress today on getting NTPsec to be Python 3 compatible. Eric got waf 1.9.4 installed. Matt Selsky fixed a huge number of nits that where fatal errors in Python 3. The result is you can now build and install NTPsec with Python 2.7 and Python 3.4! "./waf check" even works. I was not so lucky with ntpviz. Just one annoying thing in ntpviz I can't fix. Documented on line 74. I can make it work in Python 2, or Python 3, but not polyglot... RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgppel7KelHPR.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘minpoll=maxpoll=2
Yo All! I have some solid results on minpoll=maxpoll=1. That gives a poll time of 2 seconds. When minpoll=maxpoll=0 works Ill be testing that. UNtil thne I'll be testing other values. First, the good news. On a Raspberry Pi 3B, with Uputronics hat, minpoll=maxpoll=1 is much better than minpoll=maxpoll=6 (64s). At poll=64: Local Clock Freq Offset: 90% 1.4ppm, Jitter 90% 3.3 us Local Stability 90%: 2.2 ppt PPS Offset 90% 68us, Jitter 90% 9.7 us At poll=2: Local Clock Freq Offset: 90% 1.1ppm, Jitter 90% 0.43 us Local Stability 90%: 2.3 ppt PPS Offset 90% 1.6us, Jitter 90% 0.34 us See attached pi3-local-offset.png. Before 18:25 12 Sep 2016 UTC is poll=64s after is poll=2. Pretty nice, a very good improvement in time, for a slight decrease in frequency. And NTP is all about time, right? Now the bad news. On a quad XEON, with an MR-350P serial GPS: At poll=64 Local Clock Freq Offset: 90% 570ppb, Jitter 90% 10.2 us Local Stability 90%: 1.2 ppt PPS Offset 90% 34.2us, Jitter 90% 16.3 us At poll=2 Local Clock Freq Offset: 90% 495ppb, Jitter 90% 16.9 us Local Stability 90%: 27.7 ppt PPS Offset 90% 39.0us, Jitter 90% 26.7 us See attached spidey-local-offset.png. Before 18:10 12 Sep 2016 UTC is poll=64s after is poll=2. That went really, really badly... So, the answer to the best poll? It depends... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpp6m3D3Xoqa.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: -g screqup (from IRC)
Yo Hal! On Mon, 12 Sep 2016 13:26:38 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > > 12:09:40gemiller > > | "killall ntpd; sleep 1; ntpd -N -g" > > | screws up the clock for over a day, > > | much better without the -g > > You have either found a very interesting bug or you are on a wild > goose chase. Intersting, but not new. I've been complaining about btpd startup for a while. -g is just one aspect of it. > The -g switch is supposed to be very simple. It allows a large > initial step. Other than that, it shouldn't do anything. Sadly, simple things have bad consequences. See all my previous posts about nntpd bad startup behavior. > Are you getting steps at all? grep your ntpd.log for "clock_step". > It needs lots of logging turned on. You can test it with the bump > option in ntpfrob. Can you tell me which logging? Then I can test for this case. > steps are reasonably common at first-boot. The size of the step > depends upon how good your TOY/CMOS clock is. RasPis do not have CMOS clocks. So the startup step is huge. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpFow9VGpITI.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘minpoll=maxpoll=2
Yo All! I have some solid results on minpoll=maxpoll=2. That gives a poll time of 4 seconds. This results set after about 43 hours of run time. Eric delegated me the task to fix for minnpoll=maxpoll=0. On my list to fix early next week. First, the bbad news. On a Raspberry Pi 3B, with Uputronics hat, minpoll=maxpoll=2 (4s) results are a bit worse than than minpoll=maxpoll=1 (2s). At poll=4s: Local Clock Freq Offset: 90% 1.1ppm, Jitter 90% 0.08 us Local Stability 90%: 2.9 ppt PPS Offset 90% 2.2us, Jitter 90% 0.20 us At poll=2s: Local Clock Freq Offset: 90% 1.1ppm, Jitter 90% 0.43 us Local Stability 90%: 2.3 ppt PPS Offset 90% 1.6us, Jitter 90% 0.34 us At poll=64s: Local Clock Freq Offset: 90% 1.4ppm, Jitter 90% 3.3 us Local Stability 90%: 2.2 ppt PPS Offset 90% 68us, Jitter 90% 9.7 us Poll=2s is still the bast for this hardware, but there is a little tradeoff between offset and jitter. Since NTP is about time, not frequency, we go with the best time. Now the good news. On a quad XEON, with an MR-350P serial GPS: At poll=4s: Local Clock Freq Offset: 90% 332ppb, Jitter 90% 20.9 us Local Stability 90%: 15,6 ppt PPS Offset 90% 40.6us, Jitter 90% 29.7 us At poll=2s Local Clock Freq Offset: 90% 495ppb, Jitter 90% 16.9 us Local Stability 90%: 27.7 ppt PPS Offset 90% 39.0us, Jitter 90% 26.7 us At poll=64s Local Clock Freq Offset: 90% 570ppb, Jitter 90% 10.2 us Local Stability 90%: 1.2 ppt PPS Offset 90% 34.2us, Jitter 90% 16.3 us For this hardware poll=64s is stil the bast, and both low poll times are much worse. Not much to see in the graphs, so I skipped them. Next time (poll=8s) I'll put the numbers in chart form. So, the answer to the best poll? It depends, but poll=4s does not seem optimal for my two cases. So far poll=2s for RasPi+HAT, and poll=64s for Xeon+Serial GPS. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpi8b4JcxS5F.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘minpoll=maxpoll from 0 to 8 for RasPi 3
Yo All! Since minpoll=maxpoll=0 is starting to work, I added another test on the RasPi 3 for that value. No need to do so on the Xeon since that would clearly be a bad setting. RasPi3: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 0 1.0 ppm0.65µs 8.2 ppt 1.55µs0.76µs 1 1.1 ppm0.43µs 2.3 ppt 1.6µs 0.34µs 2 1.1 ppm0.08µs 2.9 ppt 2.2µs 0.20µs 3 0.5 ppm0.18µs 1.9 ppt 3.0µs 0.56µs 4 1.12ppm1.27µs 2.26ppt10.3µs 4.11µs 5 1.36ppm1.34µs 2.64ppt11.4µs 4.43µs 6 1.4 ppm3.3 µs 2.2 ppt68. µs 9.7 µs 7 1.15ppm1.14µs 1.77ppt 9.4µs 3.45µs 8 0.89ppm 39.9 µs 6.86ppt 977. µs95.2 µs Here poll=1 (2 sec) still looks best to me. But poll=0 (1 sec) pretty close. A 1/5 second poll would be interesting, but that would require major surgery in ntpd, so not likely anytime soon. I wish all the data was a bit more linear. The poll=7 data sticks out, I'll prolly have to rerun the data sometime. I don't think the Local CLock Frequency Offset data is useful here, it corelates to room temp not to poll. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp4bsejOfhI0.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Something broken with minpoll/maxpoll
Yo Hal! On Sat, 24 Sep 2016 13:30:29 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > Some of my PPS refclocks are now ramping up the poll interval. > I think there used to be some code that set maxpoll to minpoll for > refclocks. Did you break that? Fix pushed. Please test. An undefined maxpoll is not always set to the default maxpoll (NTP_MAXDPOLL). For a local refclock the default max poll is the minpoll. How to add regression tests for such config options? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpxXLOWEC8MB.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Something broken with minpoll/maxpoll
Yo Hal! On Sat, 24 Sep 2016 13:30:29 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > Some of my PPS refclocks are now ramping up the poll interval. > I think there used to be some code that set maxpoll to minpoll for > refclocks. Did you break that? Yes. That was me. I was wondering how long until someone noticed. I left a FIXME at the problem area in ntp_config.c /* FIXME: 0 no longer a magic value */ /* this needs to be fixed */ if (maxpoll == 0) /* default maxpoll for * refclocks is minpoll */ peer->maxpoll = peer->minpoll; I'm gonna take another part of your patch as the start of my fix. RGDS GARY ----------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpHRk7FeJM6M.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘--disable-kernel-pll
Yo Daniel! On Thu, 29 Sep 2016 14:34:08 -0400 Daniel Franke <dfoxfra...@gmail.com> wrote: > On Sep 29, 2016 2:23 PM, "Gary E. Miller" <g...@rellim.com> wrote: > > > Then maybe a worth while experimment to copy the kernel PLL into > > ntpd to see how it works there? > > I can't conceive of how you'd do that. It's too tightly integrated > with the rest of the kernel timing subsystem and other internal > kernel APIs. Ouch. I guess it does not matter, except for those few OS that do not have adjtimex(). RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpan8HZBh9ri.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [time-nuts] Need Time Help
Yo Hal! On Wed, 05 Oct 2016 23:38:44 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > > Looks like NTPsec really need SNTP to support Windows clients, and > > the accuracy needs are minimal. > > SNTP and real NTP use the same packet formats so we can already > support Windows clients. Please note this commit: commit da212799bdd54c02b11ec5957254b478893a265e Merge: 39ab6f5 52f93c4 Author: Eric S. Raymond <e...@thyrsus.com> Date: Mon Oct 3 22:02:31 2016 -0400 Merge branch 'proto-refactor' This deliberately discards interleave interleave support. Peer mode may be broken, broadcast modes probably are broken, MS-SNTP is not reimplemented. I take Eric at his word, until proven otherwise. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpmug5dp07LP.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Incompatible changes, security, and good practice
Yo Eric! On Thu, 6 Oct 2016 17:06:29 -0400 (EDT) e...@thyrsus.com (Eric S. Raymond) wrote: > 1. Technical justification > The narrow technical case for disabling unauthenticated symmetric-peer > mode is clear. No, for many reasons. a) Silently breaking existing working configurations is always bad. b) When NTPsec can not interoperate with existingg systems (that can not be updated), then people will just not use NTPsec. Only when NTPsec has dominant market share can we just tell users to suck it. c) There were other changes that can be done to improve the situation that do not have the problems a) and b). Things might be different if there were no other options, but that is not the case. Stop hijacking the discussion like this is the only way to solve the problem. > 2. Proper communication > > All kinds of havoc and tsuris ensued because dfranke did not realize > he needed to broadcast a much louder alert about this change. As he > later said: No. The commit was all the communication I needed to know something had gone horribley wrong. Big and grossly intrusive changes need to be made a small step at a time. And quickly reverted when fixable issues come tom light. Possibly only in testing branches. > 3. Compatibility vs. security tradeoffs. > > This is one of those cases - like the proposed change in access > defaults I posted about recently - where there are serious questions > about how we trade off backward compatibility versus improved > security. Actually, I agree with the comparision of this change to the defaults change. I just come to totally different conclusions than you do. The defaults change has been widely touted for years as the proper thing to do. Now that years have passed, and any system that could be fixed has been fixed, it is appropriate to shoot the last straglers. This change is exactly the opposite. No years long consensus that this is the right thing. No internet wide consensus that this is the right thing. No years of testing to be sure the fixs works as intended. > I think *everything* other than pure client mode with an ntp.conf full > of dumb defaults is a sufficiently rarely used feature to be sacrified > for any significant security gain. Many facts not in evidence. And ignoring facts in evidence. > I understand that some of us think > differently because we're in the tiny minority of those who operate > servers and tinker with ntp.conf. It is perfectly natural that we have > a perspective exaggerating our own concerns, but the truth is that > J. Random Linux or BSD user will never even notice any of the things > we argue about. ASadly, in this case, the major breakage this caused show your statement to be incorrect. And you continue to ignore other good options. > If any of you have a principled position different from that, I want > to hear about it. If you *agree* with that position, let me hear > that, too. What I want is for us to arrive at a rough consensus > so the arguments stay civilized. This is NOT an all or nothing decision. There are other ways to mitigate this problem that do not involve major silent breakage. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpsTXszgmwOm.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Incompatible changes, security, and good practice
Yo Eric! On Thu, 6 Oct 2016 23:10:37 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote: > Gary E. Miller <g...@rellim.com>: > > Yo Eric! > > > > On Thu, 6 Oct 2016 17:06:29 -0400 (EDT) > > e...@thyrsus.com (Eric S. Raymond) wrote: > > > > > 1. Technical justification > > > > > The narrow technical case for disabling unauthenticated > > > symmetric-peer mode is clear. > > > > No, for many reasons. > > > > a) Silently breaking existing working configurations is always bad. > > > > b) When NTPsec can not interoperate with existingg systems (that > > can not be updated), then people will just not use NTPsec. Only > > when NTPsec has dominant market share can we just tell users to > > suck it. > > > > c) There were other changes that can be done to improve the > > situation that do not have the problems a) and b). Things might be > > different if there were no other options, but that is not the > > case. Stop hijacking the discussion like this is the only way to > > solve the problem. > > You've changed the subject. Your objections here jump ahead to point > 3, the policy question about compatibility/security tradeoffs. The > sole issue under point 1 is whether Daniel's assessment of high threat > level with no real benefits is correct. Scroll up. I already said no. Also reference Daniel's email late today where he comes up with a plan that might solve his and my issues at the same time. > I expect and want you to be in the policy argument, but to do it > right. Confusing these different kinds of issues is not doing it > right. Well, right back at you. > > No. The commit was all the communication I needed to know something > > had gone horribley wrong. > > Evidently it wasn't, because you mis-identified the breaking commit. > You thought it was my TESTFRAME removal, or one of the two immediately > following. That's what you told me, and havoc (including the head > reset) ensued. Yeah, after I spent hours getting my git back to workings... I was gonna let that one slide... > Let me emphasize that point, not because I want to beat up on you but > because we need to be clear about what went wrong in order to improve. > If you had correctly identified the merge commit as the place where > symmetric-peer behavior changed, I would not have concluded that we > were in shit so deep that the head reset was required. Several days > of scrambling to put the pieces back together in a sane order would > have been avoided. Well, right back at you. Please do not get git so balled up and we don't both waste time on commits taht no longer exist. > > Big and grossly intrusive changes need to be made a small step at a > > time. And quickly reverted when fixable issues come tom light. > > Possibly only in testing branches. > > Generally agreed, but there comes a point where the big merge has to > happen. The team didn't handle that well. Daniel screwed up, you > screwed up, I screwed up. We need to do better next time. +1 > > Many facts not in evidence. And ignoring facts in evidence. > > I'm listening, when you're ready to produce them. Read the discussion Daniel and I had this afternoon. New proposal we both want to work on is agreed. > > This is NOT an all or nothing decision. There are other ways to > > mitigate this problem that do not involve major silent breakage. > > What "this problem" are you referring to? If it's what to do about > symmetric peer mode, maybe you're right. But now, under point 3, > that's over-focusing on the point problem. "this problem" is when I do a "git pull", reinstall, and most of my NTP hosts go down... > What I want to hear from you is what criteria you want us to use > for making security vs. compatibility tradeoffs in general. You > don't like my criterion; that's OK, but if we're going to reach > a theory we can all live with, you need to put yours on the table. Not time go shear that yack. We have a current mess to fix. > You can use a proposed disposition of peer mode to illustrate > your more general criteria, but the discussion won't advance > much if you stop there. Easy, when we work on it together, we can usually find a mutually agreeable solution. I'll not spend time on hypotheticals about hypotheticals when git head is broken and there is a good plan to fix it. Someday, when we really do have an all or none issue, and we have rael agree facts, then we cn discuss the real implications of that. I'll bet that does not happen in the next year or more. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpRthLMEuGgp.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘macOS build log
Yo All! FYI, see attached for an NTPsec build log from macOS, and Xcode 8.0 Seems OK. OTOH, the SHM not working for gpsd... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 nohup.out Description: Binary data pgpE0Ok4BbVYr.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Fw: [time-nuts] Need Time Help
Yo All! There has been an interesting discussion of late on time-nuts about how bad Windows timekeeping is. This one snippet is very relavant to current NTPsec plans: From: Tim Shoppa <tsho...@gmail.com> > I agree that the built in Microsoft tools are SNTP only and will not > work at the 15ms level. Looks like NTPsec really need SNTP to support Windows clients, and the accuracy needs are minimal. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpK43EClqqzz.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Forward-planning towards release 1.0
Yo Hal! On Wed, 05 Oct 2016 02:20:58 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: I'd vote for getting rid of KERNEL_PLL. Me too, but the alternative has to not suck. The last test remove was a terrible failure. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpHAKEgeq6kZ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Forward-planning towards release 1.0
Yo Hal! On Wed, 05 Oct 2016 11:55:36 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > g...@rellim.com said: > >> I'd vote for getting rid of KERNEL_PLL. > > Me too, but the alternative has to not suck. The last test remove > > was a terrible failure. > > What "test remove" was that? Eric added --disable-kernel-pll last week. commit c6b45a2d332ab98f278691fbb462e6b65a528649 Author: Eric S. Raymond <e...@thyrsus.com> Date: Wed Sep 28 14:20:51 2016 -0400 Implement --disable-kernel-pll configuration option. I posted the results to this email list. I have attached one of the graphs from that thread that shows the bad results. The option was applied at 28-18:45. After that time the time offset and jitter got way worse. The time to recover from LF changes also got much worse. Check out the list archives for the entire discussion. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp5eXweX7EVc.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Did your fix for minpoll=0 work?
Yo Hal! On Wed, 21 Sep 2016 10:48:04 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > I worked out a (much) more complicated fix. I'll happily dump it if > yours works. I have nothing yet. Just a start of a patch, pushed a tiny bit last night. > When I was testing things, ntpq showd a poll of 1, but clockstats was > acting like it was 2. So there are 2 options for what "works" means. Minpoll=0 and maxpoll=0 are used internally to signal NTP_MINDPOLL (6) and NTP_MAXDPOLL (10). So until that is fixed we can not grab 0 to actually mean 0. If you have something that works, love to see it. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpDjRzNVCMSe.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘minpoll=maxpoll=2
Yo Achim! On Fri, 16 Sep 2016 20:17:50 +0200 Achim Gratz <strom...@nexgo.de> wrote: > Gary E. Miller writes: > > Poll=2s is still the bast for this hardware, but there is a little > > tradeoff between offset and jitter. Since NTP is about time, not > > frequency, we go with the best time. > > You 've made this argument before, but I think it's circular > reasoning. Really? I think the data is very clear, you can optimize for time or for frequency. > You make the local clock follow external jitter faster. What external jiitter? Assumption #1 is that the PPS is way better than the internal XTAL. An assumption supported by the GPS data sheets. > Whether or not that gets you closer to true time isn't something you > can decide from your data, since the NTP offset value only tells you > how close the PLL controller thinks it is to the external source. Yes, it is a bit dodgy, using our dependent cvariable to measure itself. I'm open to better ways to measure. But when offset varies by over a factor of 10 it is certainly indicative. Large enough that local peers can see the improvement. And please notice I am optimizing for self-referencetial stable time, not some 'true' time. Until it is stable, no point playing with static offsets to make it 'true'. > > Now the good news. On a quad XEON, with an MR-350P serial GPS: > > I think as that example amply shows (I think you are using serial line > discipline for PPS here), Yes, sort of serial line PPS. The Xeon is RS-232, the RasPi's are actually using the GPIO lines, but very similar results. > having the obviously better (than the rasPi) > local clock follow a noisy reference (likely more jittery than the one > on the rasPi) isn't helping the precision. Uh, lost me. My RasPi and my XEON are following local PPS. That local PPS is far more stable than annything else in the vicinity. Depending on who's talking the PPS may be accurate down to 50 or even 10 ns. No way to tell. So the whole point is to track the PPS as well as possible. When I can track it down to under 1 us then it will be worth comparing different PGS to see the best ones. > BTW, both your plots showed relatively large swings in frequency > offset in a short period of time. Both plots? I'm up to dozens now Gotta be a bit more specific. > Do you have an A/C that is > producing larger temperature swings? Nope. My house has no A/C. It would likely be better if I did have A/C. If you look at the complete graphs (with CPU, Room, HR, etc. temps) you will see a temperature correlation. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpCYTqrOm1_6.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘minpoll=maxpoll=3
Yo All! New data for poll=3 (8 Sec). Xeon: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 1 495ppb 16.9us 27.7ppt 39.0us 26.7us 2 332ppb 20.9us 15.6ppt 40.6us 29.7us 3 165ppb 20.5us 7.5ppt 34.6us 27.9us 6 570ppb 10.2us 1.2ppt 34.2us 16.3us The above is pretty clear that for every 90% measure the best is for poll=6, except Frequency Stability. That is OK since the goal is to optimize for time, not frequency. I think the frequency shifting is due to ntpd pulling the xtal against temp changes. RasPi3: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 1 1.1ppm 0.43us 2.3ppt 1.6us 0.34us 2 1.1ppm 0.08us 2.9ppt 2.2us 0.20us 3 0.5ppm 0.18us 1.9ppt 3.0us 0.56us 6 1.4ppm 3.3us2.2ppt68us 9.7us Here it is a litle less clear if poll=1 or =2 is best. poll=1 has the least PPS Offset, but for a 30% reduction in offset, the Local Clock Jitter reduces by over a factor of 5. 3 is getting worse and 6 is just bad. I'll probably rerun the =1 and =2 numbers eventually, But poll=4 is running now. More data in a few days. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp46QuIWUpk2.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘minpoll=maxpoll=2
Yo Achim! On Mon, 19 Sep 2016 20:09:04 +0200 Achim Gratz <strom...@nexgo.de> wrote: > Oh, I see it now. You're plotting days-hh:mm, not hh-mm:ss as I > assumed initially. I just pushed a change to the x label. From "Time" to "Time (dd-hh:mm)". Does that resolve the confusion? RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpzpK5rI5fbM.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘minpoll=maxpoll from 1 to 8 - 'final' data
Yo All! New data for poll=8 (256 Sec). Like before, all data is 90% bounds, run over 24 hours or more. Looks like 8 is clearly too high for either of these PPS hosts. So this is the end of this test series. Xeon: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 1 495ppb 16.9µs 27.7ppt 39.0µs 26.7µs 2 332ppb 20.9µs 15.6ppt 40.6µs 29.7µs 3 165ppb 20.5µs 7.5ppt 34.6µs 27.9µs 4 465ppb 15.5µs 3.1ppt 22.5µs 20.1µs 5 435ppb 13.3µs 3.4ppt 17.7µs 16.9µs 6 570ppb 10.2µs 1.2ppt 34.2µs 16.3µs 7 330ppb 11.0µs 1.4ppt 102 µs 21.2µs 8 251ppb 43.6µs 2.1ppt 364 µs 103 µs I will go with poll=5 (32 sec) for this host. One could also argue for poll=6 (64 sec). RasPi3: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 1 1.1 ppm0.43µs 2.3 ppt 1.6µs 0.34µs 2 1.1 ppm0.08µs 2.9 ppt 2.2µs 0.20µs 3 0.5 ppm0.18µs 1.9 ppt 3.0µs 0.56µs 4 1.12ppm1.27µs 2.26ppt10.3µs 4.11µs 5 1.36ppm1.34µs 2.64ppt11.4µs 4.43µs 6 1.4 ppm3.3 µs 2.2 ppt68. µs 9.7 µs 7 1.15ppm1.14µs 1.77ppt 9.4µs 3.45µs 8 0.89ppm 39.9 µs 6.86ppt 977. µs95.2 µs Here poll=1 (2 sec) looks best to me. A good reason to get poll=0 fixed so I can test that. The bottom line to what is the best poll value? The answer: it depends... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpl5okd5_YME.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘minpoll=maxpoll from 1 to 7
Yo All! New data for poll=7 (128 Sec). Like before, all data is 90% bounds, run over 24 hours or more. poll=8 up next. Xeon: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 1 495ppb 16.9µs 27.7ppt 39.0µs 26.7µs 2 332ppb 20.9µs 15.6ppt 40.6µs 29.7µs 3 165ppb 20.5µs 7.5ppt 34.6µs 27.9µs 4 465ppb 15.5µs 3.1ppt 22.5µs 20.1µs 5 435ppb 13.3µs 3.4ppt 17.7µs 16.9µs 6 570ppb 10.2µs 1.2ppt 34.2µs 16.3µs 7 330ppb 11.0µs 1.4ppt 102 µs 21.2µs 7 is looking to prolly be past the best. RasPi3: Local Clock Local Clock Local ClockPPS PPS Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90% 1 1.1 ppm0.43µs 2.3 ppt 1.6µs 0.34µs 2 1.1 ppm0.08µs 2.9 ppt 2.2µs 0.20µs 3 0.5 ppm0.18µs 1.9 ppt 3.0µs 0.56µs 4 1.12ppm1.27µs 2.26ppt10.3µs 4.11µs 5 1.36ppm1.34µs 2.64ppt11.4µs 4.43µs 6 1.4 ppm3.3 µs 2.2 ppt68 µs 9.7 µs 7 1.15ppm1.14µs 1.77ppt 9.4µs 3.45µs 6 sorta stands out. I'll eventualy rerun that one to be sure. More to come. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpNtXFDuunBo.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: minpoll=maxpoll from 1 to 7
Yo Hal! On Wed, 21 Sep 2016 19:24:31 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > Nice work. Thanks. I wish it brought more clarity... > Would you please remind us about what the PPS setups on those systems > are. (I think you said the Xeon has a USB setup.) https://pi3.rellim.com/day/ https://rellim.com/ntpstats/day/ Notes on the system config, and links to the ntp.conf are on those pages. > And what do the column headings really mean? Those match the headings on the ntpviz pages, links just above. > Do you have a recipe for generating that data? I expect it comes > from ntpviz, but what do I type? Is there anything interesting on > the graphs? ... I just copy the numbers off the graphs. I think I'll need to automate it some more. > For things like this, there is usually a tradeoff. If you sample too > close together (short poll) the errors are dominated by the accuracy > of the measurement. If you sample far apart, the underlying clock is > changing while you are measuring it. That leads to the classic V > shape for ADEV graphs. The bottom of the V is usually the best place > to measure. Yeah, I'm just surprised at how different the Pi3 and the Xeon are. > For a good PPS (GPIO or real serial port) that works out to be 1 > second or less. SO far I'm seeing 4s as the best on the Pi3. > For PPS over USB things get messy because the error may not be > Gaussian. If you don't hit one of the ugly hanging-bridge cases, > more measurements help to average out the noise. Yeah, not even started to look at that yet. What I see is the USB phase locks to the PPS and the results are 'too good'. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpCS5p053RVa.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
