Well, if someone felt offended by my words, i apologize. I'm a somewhat complicated being and don't have steady capabilities to be polite at all time. So again .. i'm sorry.
But still, the part about unnecessary full quotes and probably poor management of big devices which just boot and in a big rush do their NTP syncs stay and are imho still valid. Even if i used a not so nice wording. ;) (Again sorry, besides all this complicated stuff, we germans tend to talk cleartext most times;)). Anyway.. On 21 June 2017 at 09:17, Tim Bray <[email protected]> wrote: > > On 19/06/17 22:10, Andreas Krüger wrote: > > But I'm afraid of the "every 43200 seconds since boot" stuff, > > too... > > > > I imagine a big city with many devices. Or maybe just a big > > factory yard deploying thousands of little devices integrated > > into heaven-knows-what, all with the same ntp client build > > in. That client diligently follows the rule. > It is a problem. In other areas. I don't know about the ntp pool. > Well, even a bigger city (like mine, Hamburg, Germany) and - let's say the controllers for traffic signs (and yeah, any bigger city need a _lot_ of them;)), usually includes some sort of backbone to get them connected to the control center. Even if this uplink is partially just some landline link (probably ISDN 1TR6 over here, maybe with GSM fallback. ;)), having all of them using just default values pointing to the general round-robin hosts/domains from the pool is at least definitely not best practice _imho_. But; > > I've seen 20 SIP phones bootup and take out the (not very good) DHCP > server. Even a 10 msec of difference fixes the problem. > > A very simple work around to the "every 43200 seconds since boot" is to > make it: > > "every 43200 + last byte of mac address seconds since boot" Thus > there will be a spread of devices which connect between every 43200 > seconds and every 43455 seconds. > > Thus if loads of devices come on at the same time, there is some > separation on the second call home. > > (They will in theory, all come back together again, but takes a while) > > Full ack. It's a very simple and so far even somewhat usable and stable solution to this problem, which will even help _if_ a vendor or provider already has it's own vendor zone and can not setup his own proxies for this. (Like [*.]debian.ntp.org as example). > > Tim Thx for mentioning that Tim. If one asks me, i would vote to put this into the basic guidelines for vendors. It just makes sense, at least for me. ;) Greetings from sunny Hamburg, Daniel 'hackbyte' Mitzlaff _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
