[ale] semi [OT] NTP questions - and NTP Windows - was: possibility of running an NTP server

Michael H. Warfield mhw at WittsEnd.com
Sat Jan 14 11:57:48 EST 2012


On Sat, 2012-01-14 at 11:14 -0500, Ron Frazier wrote: 
> On 1/14/2012 1:38 AM, mike at trausch.us wrote:
> > On 01/13/2012 04:54 PM, Ron Frazier wrote:
> >    
> >> NTP is polling the NIST service every 4 minutes, and, as you can see
> >> from the red graph, my clock offset is all over the place, varying from
> >> -5 ms to +110 ms.  I also notice that the frequency is drifting up from
> >> -13 to -9.  Can someone explain to me in a few words what the frequency
> >> means?  Does this graph mean that the system is trimming my clock?
> >>      
> > It is more than sufficient to set your clock once a day.  Much more
> > frequently than that and it is considered impolite.
> >
> > Even the most horrible of PC clocks I have encountered don't drift more
> > than 10 seconds per day.  The average, IME, is 0.5 to 4 seconds per day.
> >   If you need to get more accurate than that, then purchase or build a
> > WWVB receiver that can feed your computer the current time directly from
> > the radio signal.  Then you can have your computer constantly up-to-date
> > when the signal is coming in, and you shouldn't drift horribly when it
> > isn't.
> >
> > 	--- Mike
> >
> >    
> Hi Mike,

> I understand what you're saying.  I think my worst clock is about 15 sec 
> / day.  Based on my recent experiments, it seems to vary widely with the 
> usage of the machine and drift worse when the machine is busy.  That 
> correlates with the information I found that said sometimes the 
> interrupts get disabled when the computer is busy and the OS misses RTC 
> pulses.  I know some Linux systems have "kernel discipline" functions 
> which help NTP fine tune the kernel timing.  I don't know if Ubuntu 
> 11.04 has it, and I don't know if Windows has anything similar.

The kernel has some timing parameters which can be set through the proc
file system to fine tune the clock.  I have systems where I care less
about accuracy than I do precision and coherency (i.e. time must never
STEP BACKWARDS so I can always tell one even occurred before or after
another).  It order to sync them, I have to "drift" them close enough
for ntpd to take over by adjusting the tick counters speed up or slow
down the clock.  when it's within the target range for ntpd, I reset the
the tick count to the most accurate rate and kick ntpd in.  When it's
under 10 seconds, ntpd will also use a drift method to maintain the
clock and won't step it.
> I thoroughly checked the NIST site's server list, and the only thing 
> they mentioned about polling interval is not to do it more than every 4 
> seconds.  Also, their posted access policy on the public lists at 
> NTP.ORG says they're open access for up to 20 queries / hour, which 
> would be once every 3 minutes.  Also, the default settings for the NTPD 
> daemon are to poll starting every 64 seconds and expanding out to every 
> ~ 16 minutes.  So, it certainly seems that the systems are designed to 
> poll more often.  On my Linux machines, I have set the poll settings set 
> for 4 minutes minimum to 32 minutes maximum.  The minimum complies with 
> the NIST lower limit.  Usually, after a while, the NTPD will settle down 
> into a polling cycle of 32 minutes.  On the Windows side, I've got it 
> set to 8 minutes to 32 minutes.  It usually settles down to either 
> polling every 8 minutes or every 16 minutes and sometimes goes to 32 
> minutes.  So, just by running the algorithm with it's normal default 
> behavior, it polls much more than once / day.  Not only that, as I 
> understand it, the NTPD will terminate if it senses an extremely large 
> time offset from the server.  So, it would probably just bomb out if it 
> detected 5 - 10 sec (5000 - 10000 ms) of offset.

That can be set in the configuration file.

> Having said all that, I'm fine with the idea of maintaining accuracy 
> while reducing internet polling, if possible.  I don't think it's 
> unreasonable to ask a $1000 computer to maintain the same time as a $20 
> wall clock.  That is, always within +/- .5 sec of true time if it's 
> being synced to a trusted source.  I have literally searched hundreds of 
> Google listings with keywords like "ntp reference clock", "ntp wwvb", 
> "ntp lan clock", "ntp local clock", etc.  I keep getting references to 
> rack mounted devices that cost hundreds or thousands of dollars.  I 
> don't have that kind of budget.  It seems to me, that, if I can buy a 
> wall mounted "atomic" clock for $20, I should be able to buy a "LAN 
> mounted" atomic clock for under $100.  How much does it cost to hang a 
> LAN port on the back.  I know I could dedicate an old computer to do 
> this, but that's just another machine to patch and maintain.  I'd rather 
> have some sort of time appliance that I just plug into the LAN and 
> forget it.

What you want to do is just get a cheap GPS receiver and plug it into a
spare machine.  Voila, stratum 1 ntp.  I've been running my own stratum
2 time servers for ages and never had any problems with them.

> Here's what I'd like to have:
> 
> An inexpensive local time source
>     a) that sits on the LAN as an NTP server
>     b) that autoboots and autosets and autoreboots and autoresets
>     c) that's accurate to within +/- .5 sec / 24 to 48 hr without syncing
>     d) that discipline's itself from WWVB or GPS or cell towers, etc.  
> (By the way, it occurs to me that caller ID also provides the time when 
> phone calls come in.)

All of the above can be had with a cheap GPS receiver into a spare
system.  That will maintain it's time synchronized to the polling speed
of the NMEA signal from the GPS receiver.  Effectively continuously.
Your time will be as accurate as the precision of the kernel allows.

> e) that autoselects internet time servers for backup sync services 
> but also allows manual input through ntp.conf

Probably NOT necessary.

> f) that automatically uses the internet servers for sync if it's 
> normal source fails for a period of time
>     g) that automatically "recuses" itself by reporting a higher stratum 
> / error message, if it cannot provide accurate time
>     h) that provides status and error notifications
>     i) that provides access to statistics

All of that says to me ntpd on a Linux system with a GPS receiver.

> Then, what I want my computer to do is:

> a) poll the time appliance as frequently as necessary to maintain 
> +/- .5 seconds offset from true time

Suggestion.  Have your ntpd server chime it out onto your subnet.  You
won't have to poll it.  I believe you can use either unicast (broadcast)
or multicast for that purpose.

> b) periodically, maybe daily, poll a NIST or other external server 
> and cross check the local source

Probably not necessary.  You'll have a figure of merit from the GPS
receiver telling you the status of all the sats and if it loses lock for
any length of time.

> c) use the external source if the local source is off by more than 
> +/- .5 seconds

Your external source is your GPS receiver and you've got a chicken and
egg condition here.  How do you determine that your local source is off
by +- .5 seconds?

>     d) continue to use the external source for as long as needed

How do you determine this?

> e) produce an error message / notification that the local source has 
> failed

Trivial.  You can get that from gpsd and/or ntpd.

> f) periodically check the local source and resume using it when possible

???

> That's all I want ... I think.  8-)

I think you're trying to over engineer it.  It's not that big of a
thing.

> Sincerely,

> Ron

> -- 
> 
> (PS - If you email me and don't get a quick response, you might want to
> call on the phone.  I get about 300 emails per day from alternate energy
> mailing lists and such.  I don't always see new messages very quickly.)

> Ron Frazier

> 770-205-9422 (O)   Leave a message.
> linuxdude AT c3energy.com

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120114/87b7cb41/attachment.bin 


More information about the Ale mailing list