AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Chris.Vandever@lsi.com>,<John.Keiffer@lsi.com>,<Larry.Scheer@lsi.com>,<Dave.Johnson@lsi.com>,<Ed.Kwan@lsi.com>,<Maxim.Kozlovsky@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	F9DCB1C30AC37B4EB352D0DE0AE18E5F011A732E39@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 3 Dec 2009 11:57:27 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Vandever, Chris" <Chris.Vandever@lsi.com>
Cc: "Keiffer, John" <John.Keiffer@lsi.com>, "Scheer, Larry"
 <Larry.Scheer@lsi.com>, "Johnson, Dave" <Dave.Johnson@lsi.com>, "Kwan, Ed"
 <Ed.Kwan@lsi.com>, "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: using pool.ntp.org
Message-ID: <20091203115727.7a8729ee@ripper.onstor.net>
In-Reply-To: <F9DCB1C30AC37B4EB352D0DE0AE18E5F011A732E39@cosmail02.lsi.com>
References: <2B044E14371DA244B71F8BF2514563F5041920DA@cosmail03.lsi.com>
	<20091202103931.6c0a1be9@ripper.onstor.net>
	<2B044E14371DA244B71F8BF2514563F50419221A@cosmail03.lsi.com>
	<C5277CB418429641BC1498607A9F4805A66D866C@cosmail01.lsi.com>
	<DEC609CD0E54B2448DAF023C89AE9755E9275AC2@cosmail02.lsi.com>
	<C5277CB418429641BC1498607A9F4805A66D86F3@cosmail01.lsi.com>
	<DEC609CD0E54B2448DAF023C89AE9755E9275AC3@cosmail02.lsi.com>
	<20091202135406.1dbd4637@ripper.onstor.net>
	<C5277CB418429641BC1498607A9F4805A66D876A@cosmail01.lsi.com>
	<DEC609CD0E54B2448DAF023C89AE9755E9275AC5@cosmail02.lsi.com>
	<85A1D09038E3C1438820EF7A7FAFDD300107E5BFF8@cosmail01.lsi.com>
	<F9DCB1C30AC37B4EB352D0DE0AE18E5F011A732E39@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm in favor of this idea.  For instance, we could use some previous
info from the FTI to suggest a continent code for a pool.ntp.org entry
rather than a default entry.  Or say something like:

pick one: {us,euro,asia,what,ever}.pool.ntp.org


On Thu, 3 Dec 2009 10:27:20 -0700 "Vandever, Chris"
<Chris.Vandever@lsi.com> wrote:

> It seems to me we're discussing two different issues here -- how to
> default the initial config and the optimal way for the user to set up
> the system.  At ICW we don't have a cluster, so we can't set one node
> to refer to the other.  That's something we'll need to rely on the
> user to do when they create the cluster, IFF they are concerned about
> not having a sufficient number of reliable external NTP servers.
>=20
> Regarding ICW, we know the current mechanism which allows the user to
> not set any NTP server doesn't work.  We know we want to require at
> least 1 NTP server, and optionally allow up to 3 NTP servers to be
> configured.  Do we need to default any of them?  Can't we just
> require that the user configure at least 1 NTP server, and allow 2
> additional NTP servers to be optional?  If we are concerned that the
> customer is unprepared with an NTP server name or address, we could
> provide text with possible values they could use, but still require
> them to explicitly set a value, i.e., not provide a default.
>=20
> You can all shoot John now for adding me to the dlist.  :)
>=20
> ChrisV
>=20
> ________________________________________
> From: Keiffer, John
> Sent: Thursday, December 03, 2009 8:09 AM
> To: Scheer, Larry; Johnson, Dave; Sharp, Andy; Vandever, Chris
> Cc: Kwan, Ed; Kozlovsky, Maxim
> Subject: RE: using pool.ntp.org
>=20
> Adding Chris based on Larry's comments...
>=20
> -----Original Message-----
> From: Scheer, Larry
> Sent: Wednesday, December 02, 2009 11:42 PM
> To: Johnson, Dave; Sharp, Andy
> Cc: Kwan, Ed; Kozlovsky, Maxim; Keiffer, John
> Subject: RE: using pool.ntp.org
>=20
> My memory is a bit fuzzy on this and it may be outdated, but I read
> somewhere that companies creating default configuration files that
> use the Internet's stratum one servers was considered bad form and
> was highly discouraged. (Another reason for the founding of
> ntp.org.)  Before we use these servers we better be 100% sure that
> what we are doing is legitimate and considered proper use of these
> systems.
>=20
> One way out of the problem with the other node syncing to a different
> ntp pool server is have one node in the cluster configured to be the
> time server for the cluster and have the nodes use this server as the
> time reference. Was there some issue with this work flow? It seems
> like the obvious solution.
>=20
> ________________________________________
> From: Johnson, Dave
> Sent: Wednesday, December 02, 2009 2:12 PM
> To: Sharp, Andy; Scheer, Larry
> Cc: Kwan, Ed; Kozlovsky, Maxim; Keiffer, John
> Subject: RE: using pool.ntp.org
>=20
> I agree that the allowance for DNS names would be a nice addition.
> I agree we should stop "system time ntp disable" from deleting ntp
> entries.
>=20
> It seems the only question that remains is do we ship our default
> configuration with 4 known-poor-but-accessible NTP servers or 3
> geographically-diverse stratum-1 server IP addresses that may
> disappear in the future.
>=20
> Issues against x.pool.ntp.org:
> -Requires valid DNS resolution to function so if nfxsh DNS breaks, so
> does clustering time sync -DNS route-robin of pool.ntp.org assures
> address changes will occur upon reboot or flush of nfxsh DNS resolver
> cache -DNS round-robin of pool.ntp.org allows high likelyhood that
> two servers in cluster will sync to different NTP servers -Servers
> are of questionably accuracy (Stratum 2 or above)
>=20
> Issues against NIST server IPs:
> -Servers may go away entirely
>=20
> I tend to lean toward the NIST option.  As Larry said, this config is
> to get *something* there until they configure NTP correctly.  The
> NIST servers don't change very often and having 3 of them go away
> within a few years is highly unlikely
>=20
> Thoughts ?
>=20
> -=3Ddave
>=20
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> Sent: Wednesday, December 02, 2009 1:54 PM
> To: Scheer, Larry
> Cc: Johnson, Dave; Kwan, Ed; Kozlovsky, Maxim; Keiffer, John
> Subject: Re: using pool.ntp.org
>=20
> For now I would like to stick to the plan we agreed upon, because it's
> the only one that has been thought through in any non-trivial way.
> And it still may cause as many problems as it solves.  Perhaps we
> will get some experience with the results that we can use to direct a
> better solution which we can add to the product before it starts
> shipping in large quantities.
>=20
> The main points are changing the software to allow hostnames not just
> IP addresses and a few other touch-ups that will give us some badly
> needed flexibility.  It's not like we're shipping to 12 zillion new
> customers next month.
>=20
> I saw nothing in "Ed's test" that lead me to any conclusions that
> would suggest we should try and change the plan again.
>=20
> On Wed, 2 Dec 2009 14:42:09 -0700 "Scheer, Larry"
> <Larry.Scheer@lsi.com> wrote:
>=20
> > Perhaps I did not state this to clearly enough, using IP addresses
> > of  "well known servers" doesn't work because the IP address of the
> > servers change. It may be valid today but not in a month or so.
> > Names of the servers stick around a bit longer but also are removed
> > after a period of time. There is no time server on the Internet
> > that is: a.) open to the public and guaranteed to be accurate
> > (stratum 1 server) b.) guaranteed to be accurate
> >
> > This is why ntp.org was started.
> >
> > You say "based on Ed's testing" your solution is better. It was only
> > better at the time Ed did his test. It could be worse a day or two
> > later. Collect several weeks of data comparing the use of
> > pool.ntp.org versus the selected servers and then we will see.
> >
> > How do you know the servers Ed selected are "know good" and will
> > remain so?
> >
> > ________________________________________
> > From: Johnson, Dave
> > Sent: Wednesday, December 02, 2009 12:35 PM
> > To: Scheer, Larry; Kwan, Ed; Sharp, Andy
> > Cc: Kozlovsky, Maxim; Keiffer, John
> > Subject: RE: using pool.ntp.org
> >
> > So of the two options you admitted were non-ideal:
> >
> > -Having no servers and relying on the customer to configure
> > correctly -Having default servers and relying on the customer to
> > configure correctly
> >
> > We have tried the first and it has proven a minor failure.
> >
> > While there is a lot of good arguments why the second method isn't
> > ideal, I've seen no reasonable argument why the method will work any
> > less ideal than the first, so we need to move to it.  I've spoken
> > with Caeli and keeping the first method is not an option.
> >
> > I've spoken with various ESG folks and they state that they have
> > several different time synchronization methods used as well so any
> > well-intentioned re-architecture of our current process will likely
> > be supplanted entirely in Orion.
> >
> > Ed's new method of including a default selection of known-good
> > geographically disperse NTP servers and asking for the local NTP
> > server during install is still our best quick-fix option for now.
> >
> > If anyone still feels strongly that we need to stick with our old
> > method, then say so and I will arrange a meeting with Caeli and
> > others to discuss.
> >
> > So are we good ?
> >
> > -=3Ddave
> >
> > -----Original Message-----
> > From: Scheer, Larry
> > Sent: Wednesday, December 02, 2009 12:05 PM
> > To: Johnson, Dave; Kwan, Ed; Sharp, Andy
> > Cc: Kozlovsky, Maxim; Keiffer, John
> > Subject: RE: using pool.ntp.org
> >
> > The way to set the default servers to a geographic location is to
> > use a country code in the configuration, example: 0.us.pool.ntp.org
> > 1.us.pool.ntp.org
> > 2.us.pool.ntp.org
> > 3.us.pool.ntp.org
> >
> > It would be more work to setup a default configuration file based on
> > timezone but possible. I am not 100% convinced it is worth the
> > effort.
> >
> > The reason we are doing all of this work is to provide a reasonable
> > solution for time until the customer gets a valid NTP server
> > configured. It is not meant to be a replacement for a local
> > configuration.
> >
> > I considered all of the arguments posted in this thread before I
> > came up with the current default ntp.conf file, there was no
> > superior solution, each had their flaws and drawbacks.  In the end
> > I went with the solution that matched what was done for the bobcat:
> > no default external servers, document the need for a valid ntp
> > server and trust the customer to get it right.
> >
> >
> > ________________________________________
> > From: Johnson, Dave
> > Sent: Wednesday, December 02, 2009 10:56 AM
> > To: Kwan, Ed; Sharp, Andy
> > Cc: Kozlovsky, Maxim; Scheer, Larry; Keiffer, John
> > Subject: RE: using pool.ntp.org
> >
> > Based on Ed's findings, I think the current geographically-diverse
> > default IP servers is the better of the "half-assed" configs and
> > will fix 95% of the support issues we see.  The other 5% from
> > having no external net access (same as having zero default servers)
> > and bad local NTP servers configured, we'll never be able to code
> > around and will deal with as we do now.
> >
> > I do still agree that allowing DNS entries into  our NTP
> > configuration and changing the behavior of "system time ntp disable"
> > to not jettison existing entries are worthwhile eventual changes.
> >
> >
> > -=3Ddave
> >
> > -----Original Message-----
> > From: Kwan, Ed
> > Sent: Wednesday, December 02, 2009 10:47 AM
> > To: Sharp, Andy
> > Cc: Kozlovsky, Maxim; Scheer, Larry; Johnson, Dave; Keiffer, John
> > Subject: RE: using pool.ntp.org
> >
> > 1.  I=E2=80=99m not sure about the "geographically appropriate" part of=
 your
> > statement.  From http://www.pool.ntp.org/en/use.html As pool.ntp.org
> > will assign you timeservers from all over the world, time quality
> > will not be ideal. 2.  Also from the same web site: The 0, 1 and
> > 2.pool.ntp.org names point to a random set of servers that will
> > change every hour. That means different nodes in the cluster will
> > likely be pointing to different NTP servers.  Since the servers are
> > not that consistent, per my example, then this will cause clustering
> > issues.  I continue to argue we need to pick fixed known good NTP
> > servers.
> >
> > -----Original Message-----
> > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > Sent: Wednesday, December 02, 2009 10:40 AM
> > To: Kwan, Ed
> > Cc: Kozlovsky, Maxim; Scheer, Larry; Johnson, Dave; Keiffer, John
> > Subject: Re: using pool.ntp.org
> >
> > On Wed, 2 Dec 2009 00:41:35 -0700 "Kwan, Ed" <Ed.Kwan@lsi.com>
> > wrote:
> >
> > > I tried and got these servers, which seems pretty crappy.  And
> > > since the name to IP address changes frequently, we can't be sure
> > > all nodes in the cluster use the same NTP servers.  So are we
> > > sure we want to use <0-3>.pool.ntp.org?  Seems a lot worse than
> > > the ones I picked earlier.
> > >
> > >      remote           refid      st t when poll reach   delay
> > > offset  jitter
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
> > > 127.127.1.0     .LOCL.          10 l   16   64  377    0.000
> > > 0.000   0.001 +66.45.62.14     208.201.242.2    3 u   23  128  377
> > > 47.024    6.079   0.734 -216.184.20.83   69.36.224.15     2 u    4
> > > 128  377   73.661  -38.925   1.994 +198.186.191.229 199.165.76.11
> > > 2 u   13  128  377   17.389   -2.059   0.752 *38.117.195.101
> > > 206.246.118.250  2 u   69  128  377   79.856    3.444   0.805
> >
> > The point is that they will resolve to servers that are
> > geographically appropriate wherever the box is, so that's one
> > thing.  Another is that -- for the purposes of our product -- this
> > is a half-assed config no matter how it's sliced, so if the
> > customer wants something not-half-assed (tm), they should put in a
> > proper ntp config.
