|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] NTP process FYI
|
JP Vossen wrote:
> Not "the NTP server" *my* NTP server...
The/my. We are talking about one and the same. ;)
> 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.
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?
http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.
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.
> 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.
>> 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.
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.
> 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.*
___________________________________________________________________________
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
|
|