|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] NTP process FYI
|
> Date: Tue, 25 Mar 2008 16:37:52 -0400
> From: Eugene Smiley <eug+plug@esmiley.net>
> Subject: Re: [PLUG] NTP process FYI
>
> JP Vossen wrote:
>> 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.
>
> I see. I'd recommend being a bit more lenient then. I had a server in the pool
> that once got up to ST 5. This means that any clients I had where ST 6. I doubt
> it happens very often, though. The big issue is not being ST 16. That should be
> your test.
I admit you are correct. However, I'm a bit anal about time and so
lower is better. With my almost stock config I've never noticed I was
above 4 on my main time server, with my clients +1, of course. But I
only started my monitoring recently.
Can you think of a better way to monitor?
> The question that this leads me to is how many servers do you have in your
> ntp.conf? Do you have enough to protect yourself from false tickers? What would
> have your NTP go ST 16 besides a downed Internet link?
I believe my ST16 issues were of the self-inflicted conf/FW/daemon not
running type. So my monitoring is to protect me from myself. :-)
My ntp.conf is stock Debian Etch except:
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
[...]
restrict 192.168.x.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.y.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.z.0 mask 255.255.255.0 nomodify notrap
> http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.
Right, I'm doing "5.3.7. Using pool.ntp.org Servers"
> The new pool DNS system uses geocaching to give results nearer to the requesting
> client. This means that even if you use [0123.|]pool.ntp.org for a couple
> servers you'll get closer results.
Yup, that's the plan.
>> 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.
>
> I couldn't agree more, but Mills doesn't accept patches to upgrade the
> source/interface/features at all, much to the disdain of the community. OpenNTP
> could use some muscle to work the bugs out, improve the interface, and add features.
I didn't know that. Bummer. We could all down to to UDel and picket
his office. ;-) I'd not heard of OpenNTP either, but it's in the Etch
repos, cool! Does the interface suck less?
> I wasn't referring to the cron job. What I thought you were doing was picking
> only ST1 and ST2 servers. When the NTP clients say, "I'll only use ST1 (or ST 1
> and 2) pool servers, it puts strain on those servers versus spreading the load
> across the entire pool. This is much like what caused pool.ntp.org to be created
> in the first place. ST1 servers on the Public NTP list were taking such a heavy
> load that they'd couldn't justify the cost.
>
> The pool has lost servers over the issue of abusive clients and overloading. I
> know that this is not your intent though.
I agree that would be bad, and that's not what I intend or what I'm
doing, as far as I know.
>> That's significantly less and more local traffic than those who use the
>> Debian/Ubuntu default global vendor pools. I'd prefer to use
>> *.us.debian.pool.ntp.org but that sub-pool is broken, and
>> *.us.ubuntu.pool.ntp.org doesn't even exist.
>
> Define broken. I'll pass it along to the pool.ntp.org mailing list and I'll find
> out what is up with ubuntu.*
$ for pool in {0,1,2,3,4}.us.debian.pool.ntp.org; do host $pool; done
Host 0.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
Host 1.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
2.us.debian.pool.ntp.org has address 208.67.217.130
Host 2.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
Host 2.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
3.us.debian.pool.ntp.org has address 208.67.217.130
Host 3.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
Host 3.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
Host 4.us.debian.pool.ntp.org not found: 3(NXDOMAIN)
$ for pool in {0,1,2,3,4}.us.ubuntu.pool.ntp.org; do host $pool; done
Host 0.us.ubuntu.pool.ntp.org not found: 3(NXDOMAIN)
Host 1.us.ubuntu.pool.ntp.org not found: 3(NXDOMAIN)
Host 2.us.ubuntu.pool.ntp.org not found: 3(NXDOMAIN)
Host 3.us.ubuntu.pool.ntp.org not found: 3(NXDOMAIN)
Host 4.us.ubuntu.pool.ntp.org not found: 3(NXDOMAIN)
I've never seen a pool >4, but I threw that one in there just for
overkill. FYI, my upstream DNS is OpenDNS, if that matters, which in
theory it shouldn't.
> To be honest I'd rather see all my household
> clocks/TVs/VCRs/stove/microwave replaced with 'dumb' clocks that get
> the time from a timeserver blackbox that plugs into a broadband
> connection. The drawback being that every piece of equipment
> (clock/TV/VCR/stove/microwave) would require a Powerline
> Ethernet chip (or similar tech) adding to the cost and complexity.
Yes!!! That drives me NUTS!!! (Well, more nuts than I already am.)
Not only can't that stuff be set right (+-1 minute is NOT good enough),
but it can't keep time accurately. As you are probably aware, most of
that stuff is based on a cheap timing circuit that counts cycles in the
60Hz US residential electric service. So based on both the quality of
the components and the quality of your AC power, your appliances may
keep really bad time. And if not that, it's a cheap quartz oscillator
that's probably +- a few seconds per day! :-(
I think I read someplace that in Germany all the appliance/device clocks
sync from a radio signal. I can see that, since my--err
intensity--about time probably comes from my German side. But NTP might
be the only argument I'd accept for the coffee maker to have an IPv6
address and be on the 'Net. :-) I wonder is USB or RFID could somehow
be used since both are everywhere and cheaper than dirt?
Related, see http://www.jpsdomain.org/networking/time.html, which was
once included (with my permission) in a manual or something for the US
Navy (I think that's who it was).
Finally, does anyone know why the KYW time signal is off NTP time by
about 15 seconds? Per http://www.leapsecond.com/java/gpsclock.htm I'd
guess they are on GPS time while I'm on NTP time?
Thanks for the feedback,
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP |:::======| jp{at}jpsdomain{dot}org
My Account, My Opinions |=========| http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"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 -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|