Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Fri, 10 Jun 2016 00:55:09 -0700 Hal Murray wrote: > g...@rellim.com said: > >> The pool command hasn't been in the middle of this sort of sharp > >> eyed=20 scrutiny. I won't be surprised if there are bugs or > >> quirks. > > Well, if we can't prove it is better I would not be in a hurry to > > use it. > > Please give it a try. We can't possibly prove anything if nobody > tries it. I'll wait until bug #79 is closed. One way or another. That is a blocker. And how it is closed will make a big difference. Likely only git versions after the fix will work, so I'll wait for the fix. Worse yet, I'd hate to publish a how to that fails on 99.99% of the installed base. So it would have to be an experimental only feature of any howto. > g...@rellim.com said: > > Do we need the 'restict nopeer'? From a quick google pretty much > > every one says to use it. If we need nppeer, we can't use 'pool' > > until that bug is fixed. > > > From what I can see the nopeer is to prevent DoS. We certainly do > > not want to have a configuration that is know to allow DoS. > > > That pretty much makes up my mind. Until issue #79 is closed we > > can not use 'pool'. > > I don't know of any DoS mechanism that nopeer would fix. There was a big media storm last year about it. All the usual talking heads saying to make the change. True or not, we can't appear to ignore the 'common wisdon'. From my cursory reading I see the potential of memory exhaustion. Looks like without nopeer then each clients make ntpd allocate some RAM. If someone sprays your server with spoofed from addresses they will exhaust your RAM. Maybe not practical, but certainly theoretical. NTPsec can't appear to not take it seriously. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpGhTyeV2elw.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
g...@rellim.com said: >> The pool command hasn't been in the middle of this sort of sharp eyed=20 >> scrutiny. I won't be surprised if there are bugs or quirks. > Well, if we can't prove it is better I would not be in a hurry to use it. Please give it a try. We can't possibly prove anything if nobody tries it. I haven't noticed any problems other than the nopeer issue. g...@rellim.com said: > Do we need the 'restict nopeer'? From a quick google pretty much every one > says to use it. If we need nppeer, we can't use 'pool' until that bug is > fixed. > From what I can see the nopeer is to prevent DoS. We certainly do not > want to have a configuration that is know to allow DoS. > That pretty much makes up my mind. Until issue #79 is closed we can not use > 'pool'. I don't know of any DoS mechanism that nopeer would fix. You will probably find it in most examples along with the options that do block DoS mechanisms. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Thu, 09 Jun 2016 17:38:33 -0700 Hal Murray wrote: > > Are they all suboptimal? > > How about way out of date. Not relevant. Are they suboptimal? Is so, can you distill this to three or four lines to go in the config file? > The pool command hasn't been in the middle of this sort of sharp eyed > scrutiny. I won't be surprised if there are bugs or quirks. Well, if we can't prove it is better I would not be in a hurry to use it. > The > only one that I know of is that you have to remove the nopeer from > the default restrict lines. Do we need the 'restict nopeer'? From a quick google pretty much every one says to use it. If we need nppeer, we can't use 'pool' until that bug is fixed. From what I can see the nopeer is to prevent DoS. We certainly do not want to have a configuration that is know to allow DoS. That pretty much makes up my mind. Until issue #79 is closed we can not use 'pool'. > g...@rellim.com said: > ># The iburst option tells ntpd to query the pool servers with an > > initial # burst instead of single requests. This can yield better > > results on # startup to remote servers. > > I dislike that use of "better". Why not say "faster"? They won't be > better in the sense of more accurate. Well, in my tests it is slower. So I can't say faster, that is clearly untrue. ntpd does not wait on startup to send the first challenge packet. And one RTT is certainly faster than 8 RTT. Eight RTT with 2 second delays in between: "the spacing between packets is about 2s" This is easy to see this way: # killall ntpd # ntpd -N -g ; watch ntpq -p RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp2EoRrmuKXS.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
> Are they all suboptimal? How about way out of date. The pool got started before the pool command existed and/or distros are/were running old versions of ntp. Using several server lines was/is a way to use the pool without saying "pool". Early versions of the pool command may not have worked well. I don't remember that far back. Using the pool command will drop servers that don't respond and replace them with new ones. [In the future, we should be able to teach it to occasionally drop the worst server in hopes that the replacement is better.] I think you should replace the 4 server lines with 1 pool line. The 2 pools use IPv6 too. The pool command hasn't been in the middle of this sort of sharp eyed scrutiny. I won't be surprised if there are bugs or quirks. The only one that I know of is that you have to remove the nopeer from the default restrict lines. g...@rellim.com said: ># The iburst option tells ntpd to query the pool servers with an initial ># burst instead of single requests. This can yield better results on ># startup to remote servers. I dislike that use of "better". Why not say "faster"? They won't be better in the sense of more accurate. I would say The iburst option lets ntpd get started faster. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Thu, 09 Jun 2016 16:21:15 -0700 Hal Murray wrote: > g...@rellim.com said: > > # The iburst option tells ntpd to query the pool serers with > > bursts ins= tead > > # of single requests. This can yield better results to remote > > servers. > > That part is just wrong. Got a code reference? We are both reading the same doc and coming to different conclusions. I already updated my peer section to reflect your comments. See below for the latest. Before we dive down that rat hole, do you agree with the latest peer section, as below? If not, got a proposed wording change? > He's using the pool via multiple server lines rather than a pool > line, so he gets one server per line unless they happen to be a > duplicate. > > # server 0.us.pool.ntp.org iburst Is there a better way than I am doing? I just copied off the pool, ubuntu, gentoo and redhat howtos: http://www.pool.ntp.org/en/use.html https://help.ubuntu.com/lts/serverguide/NTP.html https://wiki.gentoo.org/wiki/Ntp https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-Date_and_Time_Configuration-Command_Line_Configuration-Network_Time_Protocol.html Are they all suboptimal? > g...@rellim.com said: > >> Just any one such line is enough. > > No, I get a lot of dead servers from the pool. And with more than > > one there is achance one is not 2,000 miles away. > > One line is enough if you say "pool" rather than "server". Your suggested ntp.conf line? If there is a better way, then the howto should explain why the 'common knowledge' on the internet is wrong. Until then, this is our best guess: # If you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool servers with an initial # burst instead of single requests. This can yield better results on # startup to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpjxx2aT86Z0.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
g...@rellim.com said: > # The iburst option tells ntpd to query the pool serers with bursts ins= > tead > # of single requests. This can yield better results to remote servers. That part is just wrong. iburst tells it to send the first few requests at 2 second intervals rather than wait for the poll interval which defaults to 64 seconds. That greatly speeds up the time for ntpd to set the system time and start responding to requests. iburst does nothing to influence the way ntpd uses local or remote servers after it is past the startup transient. strom...@nexgo.de said: > Just any one such line is enough. It seems that chosing multiple pools from > the same zone increases the chances of getting the same server assigned > twice. ntpd ignores duplicates. He's using the pool via multiple server lines rather than a pool line, so he gets one server per line unless they happen to be a duplicate. > # server 0.us.pool.ntp.org iburst ... g...@rellim.com said: >> Just any one such line is enough. > No, I get a lot of dead servers from the pool. And with more than one there > is achance one is not 2,000 miles away. One line is enough if you say "pool" rather than "server". -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Achim! On Thu, 09 Jun 2016 21:54:56 +0200 Achim Gratz wrote: > Gary E. Miller writes: > > # if you have no other local chimers to help NTP perform sanity > > checks # then you can use some public chimers from the NTP public > > pool: # http://www.pool.ntp.org/en/ > > Perhaps mention that there's a link to the continental zones on that > page with more links to the country zones on that continent. Got a suggested working? > > # To use the pool servers uncomment the last four lines in this > > section. > > Just any one such line is enough. No, I get a lot of dead servers from the pool. And with more than one there is achance one is not 2,000 miles away. > It seems that chosing multiple > pools from the same zone increases the chances of getting the same > server assigned twice. Not a problem. > > # The iburst option tells ntpd to query the pool serers with > > bursts instead > > s/serers/servers/ Fixed. > The iburst is supposed to only affect the initial contact to the > servers, contrary to the burst option (which IIRC is shunned by > NTPpool), which would use bursts on all contacts. I tweaked the wording to make that clearer. > I'd still drop the country code since someone not in the U.S. will > just uncomment the line(s) anyway. I get horrible servers when I do that. Sure it works for some people and is insanely perverse for others. That leads to the pool getting an aweful reputation. > The add a text to the effect that > one should use the local country or continental zone after looking it > up via the address given above. Having spent a lot of time in asia, I can tell you that using the asia.pool.ntp.org can be worse than the basic pool. You would think that a place like Sinagpore would be low ping to Malaysia, but almost all the interlinks go to LA and back! I have heard of similar issues in Africa. The text already links to the pool web, do you have suggested better wording? > Now, at least for the raspberryPi, the easier way of doing this is > keeping the ntpd package installed and configured, I'll leave that argument between you and Eric. I'm a Gentoo user and that does not apply to me, nor do I wish to aid and abet Jessie. So, current best wording: # If you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool servers with an initial # bursts instead of single requests. This can yield better results on # startup to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpD_NdKZkDre.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Eric S. Raymond writes: > Would we really want to preserve anything but ntp.conf? Yes (at least I do), unless you fancy writing all the startup scripts yourself from scratch, especially now that systemd is in the picture. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Achim Gratz : > Now, at least for the raspberryPi, the easier way of doing this is > keeping the ntpd package installed and configured, just lock the package > so it doesn't get altered during later updates. Then install the ntpsec > binaries into /usr prefix, replacing the original ones. That leaves the > original service files in place, which crucially will mobilize the NTP > server you get via DHCP from your provider and/or nearest router. That > gives you a fallback without any further mucking and you can still add > pool servers or local peers later f you fancy that. Would we really want to preserve anything but ntp.conf? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Gary E. Miller writes: > # if you have no other local chimers to help NTP perform sanity checks > # then you can use some public chimers from the NTP public pool: > # http://www.pool.ntp.org/en/ Perhaps mention that there's a link to the continental zones on that page with more links to the country zones on that continent. > # To use the pool servers uncomment the last four lines in this > section. Just any one such line is enough. It seems that chosing multiple pools from the same zone increases the chances of getting the same server assigned twice. > # The iburst option tells ntpd to query the pool serers with > bursts instead s/serers/servers/ The iburst is supposed to only affect the initial contact to the servers, contrary to the burst option (which IIRC is shunned by NTPpool), which would use bursts on all contacts. > # of single requests. This can yield better results to remote servers. > # Notice I use the 'us' country code servers, otherwise I might get one > # pool server from Ukraine and another from Singapore. If you are > # not in the USA, then change the 'us' to your two letter country code. > # server 0.us.pool.ntp.org iburst > # server 1.us.pool.ntp.org iburst > # server 2.us.pool.ntp.org iburst > # server 3.us.pool.ntp.org iburst I'd still drop the country code since someone not in the U.S. will just uncomment the line(s) anyway. The add a text to the effect that one should use the local country or continental zone after looking it up via the address given above. Now, at least for the raspberryPi, the easier way of doing this is keeping the ntpd package installed and configured, just lock the package so it doesn't get altered during later updates. Then install the ntpsec binaries into /usr prefix, replacing the original ones. That leaves the original service files in place, which crucially will mobilize the NTP server you get via DHCP from your provider and/or nearest router. That gives you a fallback without any further mucking and you can still add pool servers or local peers later f you fancy that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Achim! On Thu, 09 Jun 2016 21:12:52 +0200 Achim Gratz wrote: > Gary E. Miller writes: > > Even if they have no pool operators in the country, they should at > > least be able to use the country code to get the best possible. > > You can talk all day long about things that other people should do or > teach users how to find out what those same people actually do > instead. Since we have some pool management lurking here I think a gentle nudge to them is appropriate. > Start with Oh, I'm way beyond that, and not relevant to the current issue. The question here is what text to put in the plain howto ntp.conf. Got any specific suggestions? Or are you just talking all day long? :-) Here is my current best effort: # if you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool serers with bursts instead # of single requests. This can yield better results to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst Got any specific text to improve it? Or good enough? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp2oeQxzTh4W.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Gary E. Miller writes: > Even if they have no pool operators in the country, they should at least > be able to use the country code to get the best possible. You can talk all day long about things that other people should do or teach users how to find out what those same people actually do instead. Start with http://www.pool.ntp.org/en/use.html then drill down to your continental zone, then the country zone. That will give you something to contemplate if maybe they should chose another nearby zone (in addition to) their own country zone depending on the number of servers listed as currently active. Depending on what you intend to use your stratum 1 clock for, the NTP server of your internet provider (handed out via DHCP most likely) is usually a good enough fallback all by itself. If you're lucky enough to have multiple connectivity then add maybe one additional server per permanent connection. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Thu, 09 Jun 2016 01:09:25 -0700 Hal Murray wrote: > g...@rellim.com said: > >> Are you confusing iburst with burst? > > Probably. The official descriptions are essentially identical, and > > the iburst seems a tad nicer to my eye. But we know that reading > > between the lines is not useful with NTP doc. :-( > > iburst happens at startup time. That includes restart for things > like plugging an Ethernet cable in. It lets ntpd get (re)started > (much) faster. > > burst happens every time it decides to poke the remote server, aka at > the poll interval. Hmm, that is not how I read the doc. Can you point me at some code? > If you are using your servers you can do anything you want. If you > are using a free resource (pool servers or public servers like NIST), > you should be polite. I don't know of any official pool rules. One > a minute is generally considered OK. I think I've seen something > like that on the NIST web site. I see that Redhat recommends iburst: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-Date_and_Time_Configuration-Command_Line_Configuration-Network_Time_Protocol.html I see that the Pool guys object to burst and minpoll, but do not mention iburst: "So don't use more than four time servers in your configuration, and don't play tricks with burst or minpoll - all you will gain is extra load on the volunteer time servers." So good thing I have not ever advocated either on the pool. I just ran some tests. I found zero improvement to the pool servers with iburst/burst or even watching pings. They must get so much traffic that all the needed bits and pieces are live, not stuck in cache or needing ARP, etc. So I'd be OK with removing iburst from my peer section if you think that is best. But I would like a citation first. I do see burst/minpoll help locally. So I'm keeping it for my locals. Not a huge improvement, so I need to make longer tests. > burst has a bad reputation. If I read things correctly, the size of > the burst is adjusted to not go over the equivalent minpoll rate. > There is a ceiling of 8. So I don't see any problem. Neither do I > see any reason to use it unless you are working with dialup or very > low bandiwidth radio links. I do see they help locally for little used local peers. Like if the poll is longer than the ARP timeout. Of the ntpd gets swapped out on the remote. > Even without any bursting, reducing the polling interval below the > default 6 with minpoll/maxpoll is not friendly to pool/public servers. Nor have I suggested that for pool servers. For local servers I can detect a win. > Similarly, if you have lots of systems, you should setup your own > server (or a few of them) and have most of your systems get time from > your local servers. Which is what the config I first submitted does. > If I'm looking for documentation on something like iburst, I > generally try something like: > grep iburst docs/ -rl > And then poke around in the hits. I do not trust the NTP docs. Too much bit rot. And when reading the same line we can't agree on what it really mmeans. I want to see things in the source. But, back on task, my peer section is below. Are you OK with it other than the iburst thing? Are you OK with it with the iburst thing? If not, can you cite any reference against the iburst thing. # if you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool serers with bursts instead # of single requests. This can yield better results to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpCtXx8kg8sF.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Thu, 09 Jun 2016 02:38:44 -0700 Hal Murray wrote: > >> What are you using for ntp.conf on your test setups? Does it > >> work? > > http://www.catb.org/esr/faqs/stratum-1-microserver-howto/ntp.conf > > Aside from the 3 good servers tangle, it looks good. Would you be good with swapping in the recently discussed peer section as-is? No logging, you need logging, even if commented out. Without logging it is pretty hard to debug. The 'server 127.127.28.0' needs to be last as it is the poorest quality. Where it is will screw up the PLL on restart. It also needs a fudge. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpywnJfXs65Q.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
>> What are you using for ntp.conf on your test setups? Does it work? > http://www.catb.org/esr/faqs/stratum-1-microserver-howto/ntp.conf Aside from the 3 good servers tangle, it looks good. When you switch to pool, you will have to remove the nopeer from the restrict lines. Issue #79: pool command conflicts with restrict nopeer -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
e...@thyrsus.com said: [collecting ntp.conf] >> You are diving down another rathole. Save that for another day. > I think the time is now. We wouldn't have been able to put off really > documenting this range of topics much longer, anyway. Has to happen > before 1.0. ... I agree that collecting sample config files is a good idea, but I don't agree on your timing. The HOWTO only needs one config file. You should be trying to finish off that document so you can get back to working on TESTFRAME. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
g...@rellim.com said: >> Are you confusing iburst with burst? > Probably. The official descriptions are essentially identical, and the > iburst seems a tad nicer to my eye. But we know that reading between the > lines is not useful with NTP doc. :-( iburst happens at startup time. That includes restart for things like plugging an Ethernet cable in. It lets ntpd get (re)started (much) faster. burst happens every time it decides to poke the remote server, aka at the poll interval. If you are using your servers you can do anything you want. If you are using a free resource (pool servers or public servers like NIST), you should be polite. I don't know of any official pool rules. One a minute is generally considered OK. I think I've seen something like that on the NIST web site. Using iburst is generally considered reasonable. The default server side rate limiting will allow iburst but probably kick in if you are behind NAT and restart 2 or more systems using iburst at the same time. burst has a bad reputation. If I read things correctly, the size of the burst is adjusted to not go over the equivalent minpoll rate. There is a ceiling of 8. So I don't see any problem. Neither do I see any reason to use it unless you are working with dialup or very low bandiwidth radio links. Even without any bursting, reducing the polling interval below the default 6 with minpoll/maxpoll is not friendly to pool/public servers. Similarly, if you have lots of systems, you should setup your own server (or a few of them) and have most of your systems get time from your local servers. --- If I'm looking for documentation on something like iburst, I generally try something like: grep iburst docs/ -rl And then poke around in the hits. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Eric! On Thu, 9 Jun 2016 02:55:47 -0400 "Eric S. Raymond" wrote: > Hal Murray : > > > > e...@thyrsus.com said: > > >> I can't find an include file directive in ntp.conf? > > > There isn't one. Eventually, for reasons related to the > > > refclockd split, I know I'll have to fix that. > > > > There is one in the parser: includefile. I haven't tried it. I > > remember scanning something recently (code or doc, not sure) that > > said it went 5 levels deep. > > Hadn't spotted that. It will save me some work. Wow, there it is, even documented: includefile includefile This command allows additional configuration commands to be included from a separate file. Include files may be nested to a depth of five; upon reaching the end of any include file, command processing resumes in the previous configuration file. This option is useful for sites that run ntpd(8) on multiple hosts, with (mostly) common options (e.g., a restriction list). Thanks for that. Much easier to comment out an include file, than all that same data directly in the master config file. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpqplHfRA0bS.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Hal Murray : > > e...@thyrsus.com said: > >> I can't find an include file directive in ntp.conf? > > There isn't one. Eventually, for reasons related to the refclockd split, I > > know I'll have to fix that. > > There is one in the parser: includefile. I haven't tried it. I remember > scanning something recently (code or doc, not sure) that said it went 5 > levels deep. Hadn't spotted that. It will save me some work. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Wed, 08 Jun 2016 23:34:44 -0700 Hal Murray wrote: > [country code in pool command] > > I'm thinking about having clockmaker do that edit. I think it's > > possible. > > Maybe, but the pool doesn't support all countries (not enough > volunteers) so that code will need to track the actual pool details > and I don't think they make that information available in a > convenient format. Even if they have no pool operators in the country, they should at least be able to use the country code to get the best possible. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpjyAXhwzvWh.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
[country code in pool command] > I'm thinking about having clockmaker do that edit. I think it's possible. Maybe, but the pool doesn't support all countries (not enough volunteers) so that code will need to track the actual pool details and I don't think they make that information available in a convenient format. You might ask Ask and/or the pool list. He could probably add an easy to parse web page. I have now idea how busy he is or where that would fit on his priorities. If you have clean code he might like to copy it and/or various distros might like to run it as part of their post-install stuff. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
e...@thyrsus.com said: >> I can't find an include file directive in ntp.conf? > There isn't one. Eventually, for reasons related to the refclockd split, I > know I'll have to fix that. There is one in the parser: includefile. I haven't tried it. I remember scanning something recently (code or doc, not sure) that said it went 5 levels deep. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Hal Murray : > > e...@thyrsus.com said: > > I am attempting to assemble a gallery of working ntp.conf files that we can > > ship with the HOWTO. My intentions include adding these to the NTP > > documentation as tutorial examples. > > You are diving down another rathole. Save that for another day. I think the time is now. We wouldn't have been able to put off really documenting this range of topics much longer, anyway. Has to happen before 1.0. And my experience is that knowledge-engineering excavations of this kind seldom work out unless there at least some pressure to ship in the background; it concentrates minds. > For the HOWTO, you should focus on one that is appropriate for your goals. > (Which goes back to figuring out what your goals are and telling us.) Then you should assume I weant the simplest possible, minimal-care, fire-and-forget configuration the most. I was hoping you would also write the refclocks 20+22 one. > What are you using for ntp.conf on your test setups? Does it work? http://www.catb.org/esr/faqs/stratum-1-microserver-howto/ntp.conf It works. > I think you should do two things. One is to relax the "good" part and live > with what you get from the pool. The other is to set things up with a > comment (and URL for the pool page) with directions about editing the country > code so you get better than horrible. I'm thinking about having clockmaker do that edit. I think it's possible. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Gary E. Miller : > Yo Eric! > > On Wed, 8 Jun 2016 08:09:42 -0400 > "Eric S. Raymond" wrote: > > > One of these files may replace the single one we ship now. At the > > moment it uses gpsd via the SHM channel and IPs for three public > > timeservers. I'm told the latter is bad practice and should be got > > rid of; I want someone wuth operational experience to show me (and > > *explain*!) a better alternative. > > This is in my example: > > > # if you have no other local chimers to help NTP perform sanity checks > # then you can use some public chimers from the NTP public pool: > # http://www.pool.ntp.org/en/ > > # To use the pool servers uncomment the last four lines in this section. > # The iburst option tells ntpd to query the pool serers with bursts > instead > # of single requests. This can yield better results to remote servers. > # Notice I use the 'us' country code servers, otherwise I might get one > # pool server from Ukraine and another from Singapore. If you are > # not in the USA, then change the 'us' to your two letter country code. > # server 0.us.pool.ntp.org iburst > # server 1.us.pool.ntp.org iburst > # server 2.us.pool.ntp.org iburst > # server 3.us.pool.ntp.org iburst > > I just ran a test of pool servers. The basic pool gave me servers in > Switzerland, German, Czech Republic and one in New Jersey. > > Not good. You can't count on geo-location. Specify the country! You have explained that before. I get it. > > Please send me configurations. > > I think that will be too hard. Everyone want to focus on the > different part of the ntp.conf. Everyone can do that. What I don't want to do is have to micropatch the piece each person takes responsibility for a zillion times because I get sent incremental corrections rather than a clean version of their piece. > I suggest we split the ntp.conf up into several parts. Then pick the > winner in each section. Some things will be boer plate for almost > all configurations, others will be very specific to certain refclocks. OK, but these are still the things I need to see from the process. > > Here are some themes I'd like to see expressed in configurations: > > > > * Simplest possible, minimal-knowledge, fire-and-forget configuration. > > (The one we ship now is intended to be like this.) > > > > * Fully "native" configuration that uses drivers 20 and 22 rather than > > gpsd + SHM. > > > > * A configuration that is truly autonomous and doesn't use remote > > check servers at all. Header comment should try to explain the > > tradeoffs. > > > > * A configuration that uses the pool. > > > > * A configuration intended to feed the pool. > > > > * A configuration illustrating and explaning good logging practice > > for performance analysis. > > Thus WAY too much duplication! Most of those should be identical! > Stop the duplication! Let *me* worry about that. If get the pieces and explanations I need, I'll take eresponsibility for joining them together. > I can't find an include file directive in ntp.conf? There isn't one. Eventually, for reasons related to the refclockd split, I know I'll have to fix that. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Wed, 08 Jun 2016 16:13:37 -0700 Hal Murray wrote: > g...@rellim.com said: > > # The iburst option tells ntpd to query the pool serers with > > bursts ins= tead > > # of single requests. This can yield better results to remote > > servers. > > Are you confusing iburst with burst? Probably. The official descriptions are essentially identical, and the iburst seems a tad nicer to my eye. But we know that reading between the lines is not useful with NTP doc. :-( Your suggestions? Anyone know that piece of code? > Is it worth describing iburst here? Not in detail, but we should mention it is brief. Basically to reduce errors due to ARP and routing delays on the first packet. I love how the iburst and burst are designed to wait for a modem to connect. :-) I still often see the first ping is a lot slower than later ones. Both locally and remotely. > Should we setup a FAQ for that > sort of thing? Later... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpIO8_wJ9ER4.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
g...@rellim.com said: > # The iburst option tells ntpd to query the pool serers with bursts ins= > tead > # of single requests. This can yield better results to remote servers. Are you confusing iburst with burst? Is it worth describing iburst here? Should we setup a FAQ for that sort of thing? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Hal! On Wed, 08 Jun 2016 15:29:20 -0700 Hal Murray wrote: > I think you should do two things. One is to relax the "good" part > and live with what you get from the pool. The other is to set things > up with a comment (and URL for the pool page) with directions about > editing the country code so you get better than horrible. I think we agree here. Any comments on my pool example?? # if you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool serers with bursts instead # of single requests. This can yield better results to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpsAOYc_H5NP.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
e...@thyrsus.com said: > I am attempting to assemble a gallery of working ntp.conf files that we can > ship with the HOWTO. My intentions include adding these to the NTP > documentation as tutorial examples. You are diving down another rathole. Save that for another day. For the HOWTO, you should focus on one that is appropriate for your goals. (Which goes back to figuring out what your goals are and telling us.) What are you using for ntp.conf on your test setups? Does it work? > uses gpsd via the SHM channel and IPs for three public timeservers. I'm > told the latter is bad practice and should be got rid of; I want someone > wuth operational experience to show me (and There are 2 reasons not to wire in IP Addresses of public servers, both important. The first is that it sets a bad example of policy. Some chain of idiots will copy them and we will end up with another example for the ntp-abuse wiki collection. The main problem is that you lose control. There is nothing you can do to recall that sort of info - as compared to if you distribute it via DNS where you can change it. (Then you have to worry about DNS abuse, but those are your servers.) The other problem is that it won't work well. You can't pick 3 servers that will be good even if you restrict the users to being in the US. With sites outside the US it goes from not good to probably horrible. I think you should do two things. One is to relax the "good" part and live with what you get from the pool. The other is to set things up with a comment (and URL for the pool page) with directions about editing the country code so you get better than horrible. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Shippable ntp.conf files for the HOWTO
Yo Eric! On Wed, 8 Jun 2016 08:09:42 -0400 "Eric S. Raymond" wrote: > One of these files may replace the single one we ship now. At the > moment it uses gpsd via the SHM channel and IPs for three public > timeservers. I'm told the latter is bad practice and should be got > rid of; I want someone wuth operational experience to show me (and > *explain*!) a better alternative. This is in my example: # if you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool serers with bursts instead # of single requests. This can yield better results to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst I just ran a test of pool servers. The basic pool gave me servers in Switzerland, German, Czech Republic and one in New Jersey. Not good. You can't count on geo-location. Specify the country! > Please send me configurations. I think that will be too hard. Everyone want to focus on the different part of the ntp.conf. I suggest we split the ntp.conf up into several parts. Then pick the winner in each section. Some things will be boer plate for almost all configurations, others will be very specific to certain refclocks. For a start: 1. logging, stats, etc. 2. trust and access 3. local refclocks (SHM, DVB, etc.). Above all other chimers 4. local network refclocks 5. pool (at the bottom of the config!) So, take my above pool example as the pool section. > 1. Every submission must be an entire config file, *not* just > instructions to "tweak this other one thus". Change-merging at this > level is error-prone, tedious, and drives me batty. If I want to see > changes I'll use diff. As above, I object. > 2. Every submission must include a header comment explaining the > theory of the configuration and any unusual pieces of it. Consider > "unusual" to include any keyword or clause that doesn't occur in the > current uber-simple one. I would say each section. > 4. Submissions should not contain references to private or local > servers that a reader of the HOWTO cannot use. Not in the basic config, but needed in advanced ones. > enough" and therefore reject a submission even if it's technically > sound. If this happens, please try again with better explanation. > Remember that part of our purpose is to teach newbies. > > Here are some themes I'd like to see expressed in configurations: > > * Simplest possible, minimal-knowledge, fire-and-forget configuration. > (The one we ship now is intended to be like this.) > > * Fully "native" configuration that uses drivers 20 and 22 rather than > gpsd + SHM. > > * A configuration that is truly autonomous and doesn't use remote > check servers at all. Header comment should try to explain the > tradeoffs. > > * A configuration that uses the pool. > > * A configuration intended to feed the pool. > > * A configuration illustrating and explaning good logging practice > for performance analysis. Thus WAY too much duplication! Most of those should be identical! Stop the duplication! I can't find an include file directive in ntp.conf? > Another reveal: I hope to use these as bases for comparative > benchmarking. Another good reason for them to be modular. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgph538a0ZF_n.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
