[ntp:questions] iburst and NIST servers

Greg Dowd Greg.Dowd at microsemi.com
Wed Aug 5 16:41:53 UTC 2015


I have used the locked poll intervals as well, but mostly for LAN.  The only comment I have is that the steering stays in PLL mode so you get a noisier loop and the frequency correction resolution is poor in the event you lose connectivity to your servers.  But, as you mentioned, you get these nice rails to bounce off of.  When using these "fast" poll times with servers farther away, the error introduced by the network adds more noise to a short measurement interval and I have found that sometimes it's better and sometimes worse.  I find that the network has periods, lasting many minutes, where the path gets twisted or congested.  With the faster poll times, the filter fills with bad data and ntp is forced to consume some of it.  With the standard poll times, sometimes we can get through these network weirdness intervals with just 1 or 2 bad samples.

Of course, in the IEEE-1588 world, we typically query at 64Hz and can go up to 128Hz.  Now there is some real data to crunch :-)



-----Original Message-----
From: questions [mailto:questions-bounces+greg.dowd=microsemi.com at lists.ntp.org] On Behalf Of Charles Elliott
Sent: Tuesday, August 04, 2015 4:57 PM
To: 'Charles Swiger'; 'Mike Cook'
Cc: 'Questions List'
Subject: Re: [ntp:questions] iburst and NIST servers

EXTERNAL EMAIL


I use minpoll 4 maxpoll 5 on the client that accesses external servers and minpoll 4 maxpoll 4 on the LAN.  The results justify the means: consistent
sub-100 millisecond offsets on the LAN (presently -0.011 on this computer).
The only time I have been knocked off an NIST server was when I switched from one computer to another as the external gateway.  Because of the NAT, time-d and time-d.nist.gov picked up the fast request rate right away when both clients were briefly active, and would not let me back on for a day or so.

Charles Elliott

> -----Original Message-----
> From: questions [mailto:questions-
> bounces+elliott.ch=comcast.net at lists.ntp.org] On Behalf Of Charles
> Swiger
> Sent: Sunday, August 2, 2015 10:34 AM
> To: Mike Cook
> Cc: Questions List
> Subject: Re: [ntp:questions] iburst and NIST servers
>
> On Aug 2, 2015, at 2:31 AM, Mike Cook <michael.cook at sfr.fr> wrote:
> >  Can anyone confirm that this is an issue?
> >
> > I habitually put an burst directive in my ntp.conf server statements.
> ex:
> >
> >  server 129.6.15.30 noselect iburst minpoll 4 maxpoll 6  server 
> > 128.138.140.44 noselect iburst minpoll 4 maxpoll 6  server 
> > 98.175.203.200 noselect iburst minpoll 4 maxpoll 6
> >
> > But in the case of these NIST servers, sometimes they never get out
> of INIT state.
>
> iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be 
> considered abusive without prior arrangements.  minpoll 6 is the 
> fastest rate you should query other NTP servers without explicit 
> permission.
>
> To be more specific, folks who implement per-client firewall rate 
> rules tend to block clients who exceed ~100 packets per hour.
>
>
> The main point of iburst is to quickly get a downed NTP server back up 
> and serving valid time.  That matters most for isolated stratum-2+ 
> servers; if you've already got S1 timesources available and multiple 
> redundant NTP servers locally, using iburst is superfluous.
>
> Sure, use iburst on one remote server entry if you want and/or against 
> all of the other NTP peers on your local subnet, but it's not 
> obviously helpful to use iburst everywhere.
>
> Regards,
> --
> -Chuck
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions

_______________________________________________
questions mailing list
questions at lists.ntp.org
http://lists.ntp.org/listinfo/questions


More information about the questions mailing list