I corrected the example by removing the min/max polling. Sorry for posting the example which I had not explicitly tested on the ASUS router.Polite Parameters for public NTP servers
If you also have your own NTP server
- Minpoll defaults to 6 (64 seconds). Minpoll should never be set lower than six.
- Maxpoll defaults to 10 (1024 seconds). It is acceptable to go as low as six. Most clocks perform poorly, so wide clock offsets from changes in ambient temperature and computer load may make maxpoll as low as 6 desirable.
- Iburst is acceptable but burst is not acceptable
- Minpoll can be set to the minimum of 3 (8 seconds) but is not very effective unless NTP server is connected to GPS
- Set iburst to your NTP server and remove iburst from the public NTP servers in your ntp.conf.
Yes, your statements are accurate.
My warnings about NOT using burst and being careful with Publics are clearly notated in the example. Maybe it was not clear. Thanks for the clarifications.
I explained why we use maxpoll 7 - too many less than ideal "internal" NTP sources mostly driven by commodity PC's (very bad choice by IT) and routers both using drifting time-chips never designed to be reliable NTP sources.
BTW, as long as you have a highly accurate time-base minpoll can be lowered. For instance, if you have mainframe-class machines as part of an enterprise NTP network, their clocks are very accurate and good-enough to be stratum 2 easily. Far too often I see what I described earlier where IT thinks anything running an NTP server is just fine. That's also why I'm cautious with the "public" networks and really prefer to go after specific targets. You just need to make sure you have 3-5 reliable sources to thwart MIM attacks. I'm sure there's a paper or discussion floating around about that too somewhere. You would not believe the time I had just getting that point across our local IT team!!
My apologies for all the confusion above!
Last edited: