AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20091202135351.2e1fc08f@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Larry.Scheer@lsi.com>,<Dave.Johnson@lsi.com>,<Ed.Kwan@lsi.com>,<Maxim.Kozlovsky@lsi.com>,<John.Keiffer@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	DEC609CD0E54B2448DAF023C89AE9755E9275AC3@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 2 Dec 2009 13:54:06 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Scheer, Larry" <Larry.Scheer@lsi.com>
Cc: "Johnson, Dave" <Dave.Johnson@lsi.com>, "Kwan, Ed" <Ed.Kwan@lsi.com>,
 "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>, "Keiffer, John"
 <John.Keiffer@lsi.com>
Subject: Re: using pool.ntp.org
Message-ID: <20091202135406.1dbd4637@ripper.onstor.net>
In-Reply-To: <DEC609CD0E54B2448DAF023C89AE9755E9275AC3@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>
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

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.

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.

I saw nothing in "Ed's test" that lead me to any conclusions that would
suggest we should try and change the plan again.

On Wed, 2 Dec 2009 14:42:09 -0700 "Scheer, Larry"
<Larry.Scheer@lsi.com> wrote:

> 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
>=20
> This is why ntp.org was started.=20
>=20
> 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.
>=20
> How do you know the servers Ed selected are "know good" and will
> remain so?
>=20
> ________________________________________
> 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
>=20
> So of the two options you admitted were non-ideal:
>=20
> -Having no servers and relying on the customer to configure correctly
> -Having default servers and relying on the customer to configure
> correctly
>=20
> We have tried the first and it has proven a minor failure.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> So are we good ?
>=20
> -=3Ddave
>=20
> -----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
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> ________________________________________
> 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
>=20
> 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.
>=20
> 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.
>=20
>=20
> -=3Ddave
>=20
> -----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
>=20
> 1.  I=E2=80=99m not sure about the "geographically appropriate" part of y=
our
> 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.
>=20
> -----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
>=20
> On Wed, 2 Dec 2009 00:41:35 -0700 "Kwan, Ed" <Ed.Kwan@lsi.com> wrote:
>=20
> > 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
>=20
> 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.
