JP Vossen on 25 Mar 2008 12:26:35 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] NTP process FYI

> Date: Mon, 24 Mar 2008 18:06:02 -0400
> From: Eugene Smiley <>
> Subject: Re: [PLUG] NTP process FYI
> JP Vossen wrote:
>> I have a local NTP server synced to [0123]  I keep an 
>> eye on it via a trivial cron job [1].  
>> [1] Trivial NTP health; alert if localhost stratum > 2:
>> 25 * * * * ntptrace | head -n1 | perl -ne 'm/^[\w.]+: stratum (\d+),/ or 
>> next; print qq(NTP not in sync: $_) if ( $1 > 2 );'
> I'm not sure why it's helpful to know if the NTP server is greater than stratum 

Not "the NTP server" *my* NTP server...

> 2. The pool monitoring routine makes sure that all pool servers are within 100ms 
> accuracy regardless of stratum. If you need better than 100ms accuracy, the NTP 
> Pool list recommends establishing your own ST1 server.

It's just my quick & dirty way of making sure *my local time server* is 
actually synced.  I've had issues in the past where it was ST 16 
(unsynced) for a while, and that's bad.  I don't care about 100ms 
accuracy, just as long as it's more-or-less synced.

While I love NTP, I think its interface is much more obscure than it 
should be.  The math is hard and complex, but Mills has done wonderful 
work to solve that problem.  Now the interface could use some work. 
There are too many tools that do too many similar things and provide 
obscure output.  All I want to know is, am I more or less in sync?  If 
you know a better way to find that out, please share.

I actually had to tweak the entry to be >3 as over the weekend my local 
server was getting up that high.  Now it's back down to 2, though I 
haven't done or changed anything, it's just NTP doing its thing.

> Basically what you are doing is no different than what the people who are 
> pummeling the ST1 servers are doing. You are cherry picking the 'better' 
> servers. This is not 'nice' behavior.

No, I'm not.  That cron job runs again *my* local time server, once an 
hour, to make sure it's in sync.  I'm not sure where your pummeling or 
cherry picking ideas are coming from.

> A better way of managing your NTP.conf is to connect to network-wise closer NTP 
> servers. On Comcast in Philly, I could get 10 servers within 30ms delay all 
> within 10ms offset. In Broward on Comcast, I'm lucky to find 10 servers within 
> 60ms delay within 10ms offset. Stratum is irrelevant, especially since I know of 
> ST1 servers that are way off.

My *single* site time server uses the US pool addresses 
[0123]; that's what they're there for.  All of my other 
local machines use my local time server.  That's significantly less and 
more local traffic than those who use the Debian/Ubuntu default global 
vendor pools.  I'd prefer to use * but that 
sub-pool is broken, and * doesn't even exist.

JP Vossen, CISSP            |:::======|        jp{at}jpsdomain{dot}org
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --