Re: [ntp:questions] Looking for a NTP stratum 2 appliance
There is a way of securing a free NTP appliance, but I am not sure, but it might be limited to Stratum 1, and it has to be public facing. And the network connection must not be asymmetric. All the recipient has to do is pay the operating cost (electricity and maintenance). The latter might be an issue though, since none that I have been acquainted with have stayed live for any considerable period, e.g., USTime Corp. Judah Levine (judah.lev...@nist.gov, jlev...@boulder.nist.gov, judah.lev...@colorado.edu) has available NTP appliances for people who are willing to provide public time servers. The criteria for receiving one are fairly strict. Charles Elliott -Original Message- From: questions [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of Miroslav Lichvar Sent: Friday, May 26, 2017 5:29 AM To: Matthew Huff Cc: NTP Questions Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance On Thu, May 25, 2017 at 11:31:27AM +, Matthew Huff wrote: > For the last 20 years I've run our stratum 2 ntp servers under Solaris then Linux. I'm looking to replace them with an appliance for a number of reasons. One of the main one is clock stability. We have 2 microsemi GPS synced stratum 1 servers with rubidium oscillators. I am not looking for a linux/bsd/unix box running NTP, but a dedicated non-os appliance. I don't know if such an appliance exists (all I saw that had a real NTP client ran a regular OS), but I'm curious what problems is the (in)stability of an ordinary computer oscillator causing. Are the servers supposed to be able to hold over long periods of time in case the stratum-1 servers fail? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Mon, May 29, 2017 at 4:24 AM, François Meyer wrote: > the problem is with GPS Time, that is not UTC(USNO) and not traceable This is not correct (per USNO). "GPS Time" is traceable (in NIST usage) to UTC(USNO) and hence UTC. The GPS message carries the current offset and USNO produces retrospective reports. It's worth noting that that "GPS Time" may not be legally traceable to UTC outside of the US since the USNO is not an internationally "recognized" national metrology institute. That would depend on case law. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Sat, 27 May 2017, Matthew Huff wrote:
I'll pass this along to our auditors, but I doubt it will make any
difference. For another example, we had to block all access to
removable USB drives because of possible transfer of unauthorized
data, but DropBox was okay. We have to archive all IM messages, but
not phone calls. /boggle
Again, the goal is to satisfy auditors, not do the right thing. But
either way, we are synced to two S1 clocks on all of our ntp clients
which have their source as GPS. So we are correct, either way.
I jump in the discussion, you can probably get out of problems just
by adding some infos in your QMS, detailing why you need (or not)
to check the UTC(NIST) - GPSTime traceability, and how you achieve
that, if needed ; since NIST declares it provides this information (with a
24 hour delay), you can rely on this to setup a more or less automatic
online check from the NIST website (that would prove to be technically
useless since offests will stubbornly be 0 as far as milliseconds are concerned).
Instead of useless equipment, it is a one time documentation job, a daily
automated data retrieval and check with email alarm for example.
Arguing against possible objections to the 24 hour delay is left to the reader
:)
If you do need a proven, real time access to UTC(whatever) <5ms, then it might get
a bit muddier.
(The problem is not between UTC(NIST) and UTC(USNO), both are
equivalently traceable to SI ; the problem is with GPS Time,
that is not UTC(USNO) and not traceable)
Matthew Huff | 1 Manhattanville Rd
Director of Operations | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff | Fax: 914-694-5669
-Original Message-
From: questions [mailto:questions-bounces+mhuff=ox@lists.ntp.org]
On Behalf Of Paul
Sent: Saturday, May 27, 2017 1:32 AM
To: Harlan Stenn
Cc: NTP Questions
Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Fri, May 26, 2017 at 10:33 PM, Harlan Stenn wrote:
NIST doesn't control GPS. That's done by USNO and the USAF.
This is true(ish)* but irrelevant. NIST defines traceability to NIST
and
GPS can be a component of UTC(NIST) traceability.
More importantly the premise of this issue is incorrect (if it has been
properly presented). If I have an S2 clock peering both with a GPS
disciplined S1 clock and a NIST clock via NTP then "apparent" errors
("drift") are measurements of network instability not variance from
UTC(NIST). E.g. this line:
time-d.nist.gov .NIST. 1 u 35 5127 48.0371.714
2.137
does not mean this clock has a 1.7ms offset and 2.1ms of jitter with
respect to UTC(NIST).
Since NIST specs the NTP error O(50ms) due to network issues it's
insufficient for the stated need in any case.
*NIST publishes the delta and the two groups work to maintain
constrained
offset between UTC(NIST) and UTC(USNO) so they can be considered
equivalent
instances of UTC in the US.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
--
François MeyerTel : (+33) 3 81 66 69 27 Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
I'll pass this along to our auditors, but I doubt it will make any difference.
For another example, we had to block all access to removable USB drives because
of possible transfer of unauthorized data, but DropBox was okay. We have to
archive all IM messages, but not phone calls. /boggle
Again, the goal is to satisfy auditors, not do the right thing. But either way,
we are synced to two S1 clocks on all of our ntp clients which have their
source as GPS. So we are correct, either way.
Matthew Huff | 1 Manhattanville Rd
Director of Operations | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff | Fax: 914-694-5669
> -Original Message-
> From: questions [mailto:questions-bounces+mhuff=ox@lists.ntp.org]
> On Behalf Of Paul
> Sent: Saturday, May 27, 2017 1:32 AM
> To: Harlan Stenn
> Cc: NTP Questions
> Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance
>
> On Fri, May 26, 2017 at 10:33 PM, Harlan Stenn wrote:
>
> > NIST doesn't control GPS. That's done by USNO and the USAF.
> >
>
> This is true(ish)* but irrelevant. NIST defines traceability to NIST
> and
> GPS can be a component of UTC(NIST) traceability.
>
> More importantly the premise of this issue is incorrect (if it has been
> properly presented). If I have an S2 clock peering both with a GPS
> disciplined S1 clock and a NIST clock via NTP then "apparent" errors
> ("drift") are measurements of network instability not variance from
> UTC(NIST). E.g. this line:
>
> time-d.nist.gov .NIST. 1 u 35 5127 48.0371.714
> 2.137
>
> does not mean this clock has a 1.7ms offset and 2.1ms of jitter with
> respect to UTC(NIST).
>
> Since NIST specs the NTP error O(50ms) due to network issues it's
> insufficient for the stated need in any case.
>
> *NIST publishes the delta and the two groups work to maintain
> constrained
> offset between UTC(NIST) and UTC(USNO) so they can be considered
> equivalent
> instances of UTC in the US.
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Fri, May 26, 2017 at 10:33 PM, Harlan Stenn wrote:
> NIST doesn't control GPS. That's done by USNO and the USAF.
>
This is true(ish)* but irrelevant. NIST defines traceability to NIST and
GPS can be a component of UTC(NIST) traceability.
More importantly the premise of this issue is incorrect (if it has been
properly presented). If I have an S2 clock peering both with a GPS
disciplined S1 clock and a NIST clock via NTP then "apparent" errors
("drift") are measurements of network instability not variance from
UTC(NIST). E.g. this line:
time-d.nist.gov .NIST. 1 u 35 5127 48.0371.714
2.137
does not mean this clock has a 1.7ms offset and 2.1ms of jitter with
respect to UTC(NIST).
Since NIST specs the NTP error O(50ms) due to network issues it's
insufficient for the stated need in any case.
*NIST publishes the delta and the two groups work to maintain constrained
offset between UTC(NIST) and UTC(USNO) so they can be considered equivalent
instances of UTC in the US.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
NIST doesn't control GPS. That's done by USNO and the USAF. Civil time is NIST. It just so happens that NIST and USNO (and various other countries) go to great lengths to keep their clocks sync'd to within a handful of nanoseconds. I'm not saying your FINRA auditors are correct in their assumptions. But they are the ones you have to satisfy, until their perceptions change. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
Thanks. I'm testing with minpoll 4 and minpoll 5 currently. Minpoll 6 wasn't "often enough" Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -Original Message- > From: Harlan Stenn [mailto:st...@ntp.org] > Sent: Friday, May 26, 2017 7:57 PM > To: Matthew Huff > Cc: Paul ; NTP Questions > Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance > > If you have other S1 sources (and you do, as you should), you don't > need > to be polling NIST all that often. Once a minute is probably plenty. > > Your S2 sources should poll their remote sources "often enough". > > Your clients should be polling your several/many S2 sources "often > enough". > > This is why you want adquate monitoring and logging. > > H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
If you have other S1 sources (and you do, as you should), you don't need to be polling NIST all that often. Once a minute is probably plenty. Your S2 sources should poll their remote sources "often enough". Your clients should be polling your several/many S2 sources "often enough". This is why you want adquate monitoring and logging. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
Again, we are not setting our NTP clients time to the Internet NIST time, the clients sync to our stratum 1 clocks, however by having them also be clients of stratum 2 servers that are synced to NIST then we can monitor deviance from NIST so that it satisfies the auditors. The goal of compliance is not to do the right thing, it's to get the auditors off your back. > On May 26, 2017, at 1:19 PM, Matthew Huff wrote: > > Sorry, via NTP and not GPS > >> On May 26, 2017, at 1:18 PM, Matthew Huff wrote: >> >> That makes sense to me, but not to our FINRA auditors. They specifically >> specified that it had to be NIST time via NTP via gps >> >> On May 26, 2017, at 1:13 PM, Paul >> mailto:tik-...@bodosom.net>> wrote: >> >> I also assumed that despite what you wrote you were using your (too few) S1 >> devices. I would agree that you probably should not poll NIST at small >> intervals for various reasons. However I suspect that there's a deeper >> misunderstanding. Per NIST the US Federal GNSS system (known as the Global >> Positioning System or GPS) can be part of system* that is considered to >> produce measurements traceable to the NIST national standards. Using NIST >> servers via the public Internet likely *cannot* produce measurements that >> are traceable to NIST (in a meaningful way). >> >> *"GPS disciplined oscillators can be used to establish traceability to the >> national time and frequency standards maintained by NIST" >> [https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive]. >> Note that NTP fed by a GPS PPS produces a GPS disciplined oscillator. >> >> On Fri, May 26, 2017 at 10:31 AM, Matthew Huff >> mailto:mh...@ox.com>> wrote: >> We do sync our systems to our stratum 1 servers. The issue is that the >> regulations require us to verify that we aren't 50 msec away from NIST time, >> not GPS time. By running our stratum 2 servers with a preference to nist >> servers and also other ntp servers, our client machines can connect to our >> stratum 1 and 2 servers and we can monitor the diff between the local client >> time and NIST >> On May 26, 2017, at 9:49 AM, Miroslav Lichvar mailto:mlich...@redhat.com>> wrote: On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: Thanks. I agree that the appliance doesn't appear to exist. It's a shame that it doesn't, I think it would be a good idea. The 50 msec isn't that hard to reach on an average basis, but we routinely see drifts away from that on occasions. The minpoll idea would probably fix this, but was hesitant to poll that frequently. I just found NIST's NTP page and they specify to not poll more frequently that every 4 seconds (minpoll 2). I wouldn't have thought that they would want polling with minpoll 3, but it appears I was wrong. This may fix the issue by itself. >>> >>> Using such a short polling interval over Internet would be a horrible >>> idea. NIST servers are overloaded and located in a network that has >>> problems with asymmetric routing. It's better to avoid them if >>> accuracy is a requirement. I thought you were using those stratum-1 >>> servers you have and the requirement for accuracy was 10 or 100 >>> microseconds, not milliseconds. >>> >>> Anything should do better than 50 milliseconds as long as it's on >>> local network. >>> >>> -- >>> Miroslav Lichvar >> >> ___ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
Sorry, via NTP and not GPS > On May 26, 2017, at 1:18 PM, Matthew Huff wrote: > > That makes sense to me, but not to our FINRA auditors. They specifically > specified that it had to be NIST time via NTP via gps > > On May 26, 2017, at 1:13 PM, Paul > mailto:tik-...@bodosom.net>> wrote: > > I also assumed that despite what you wrote you were using your (too few) S1 > devices. I would agree that you probably should not poll NIST at small > intervals for various reasons. However I suspect that there's a deeper > misunderstanding. Per NIST the US Federal GNSS system (known as the Global > Positioning System or GPS) can be part of system* that is considered to > produce measurements traceable to the NIST national standards. Using NIST > servers via the public Internet likely *cannot* produce measurements that are > traceable to NIST (in a meaningful way). > > *"GPS disciplined oscillators can be used to establish traceability to the > national time and frequency standards maintained by NIST" > [https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive]. > Note that NTP fed by a GPS PPS produces a GPS disciplined oscillator. > > On Fri, May 26, 2017 at 10:31 AM, Matthew Huff > mailto:mh...@ox.com>> wrote: > We do sync our systems to our stratum 1 servers. The issue is that the > regulations require us to verify that we aren't 50 msec away from NIST time, > not GPS time. By running our stratum 2 servers with a preference to nist > servers and also other ntp servers, our client machines can connect to our > stratum 1 and 2 servers and we can monitor the diff between the local client > time and NIST > >>> On May 26, 2017, at 9:49 AM, Miroslav Lichvar >>> mailto:mlich...@redhat.com>> wrote: >>> >>> On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: >>> Thanks. I agree that the appliance doesn't appear to exist. It's a shame >>> that it doesn't, I think it would be a good idea. >>> >>> The 50 msec isn't that hard to reach on an average basis, but we routinely >>> see drifts away from that on occasions. The minpoll idea would probably fix >>> this, but was hesitant to poll that frequently. I just found NIST's NTP >>> page and they specify to not poll more frequently that every 4 seconds >>> (minpoll 2). I wouldn't have thought that they would want polling with >>> minpoll 3, but it appears I was wrong. This may fix the issue by itself. >> >> Using such a short polling interval over Internet would be a horrible >> idea. NIST servers are overloaded and located in a network that has >> problems with asymmetric routing. It's better to avoid them if >> accuracy is a requirement. I thought you were using those stratum-1 >> servers you have and the requirement for accuracy was 10 or 100 >> microseconds, not milliseconds. >> >> Anything should do better than 50 milliseconds as long as it's on >> local network. >> >> -- >> Miroslav Lichvar > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
That makes sense to me, but not to our FINRA auditors. They specifically specified that it had to be NIST time via NTP via gps On May 26, 2017, at 1:13 PM, Paul mailto:tik-...@bodosom.net>> wrote: I also assumed that despite what you wrote you were using your (too few) S1 devices. I would agree that you probably should not poll NIST at small intervals for various reasons. However I suspect that there's a deeper misunderstanding. Per NIST the US Federal GNSS system (known as the Global Positioning System or GPS) can be part of system* that is considered to produce measurements traceable to the NIST national standards. Using NIST servers via the public Internet likely *cannot* produce measurements that are traceable to NIST (in a meaningful way). *"GPS disciplined oscillators can be used to establish traceability to the national time and frequency standards maintained by NIST" [https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive]. Note that NTP fed by a GPS PPS produces a GPS disciplined oscillator. On Fri, May 26, 2017 at 10:31 AM, Matthew Huff mailto:mh...@ox.com>> wrote: We do sync our systems to our stratum 1 servers. The issue is that the regulations require us to verify that we aren't 50 msec away from NIST time, not GPS time. By running our stratum 2 servers with a preference to nist servers and also other ntp servers, our client machines can connect to our stratum 1 and 2 servers and we can monitor the diff between the local client time and NIST > On May 26, 2017, at 9:49 AM, Miroslav Lichvar > mailto:mlich...@redhat.com>> wrote: > >> On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: >> Thanks. I agree that the appliance doesn't appear to exist. It's a shame >> that it doesn't, I think it would be a good idea. >> >> The 50 msec isn't that hard to reach on an average basis, but we routinely >> see drifts away from that on occasions. The minpoll idea would probably fix >> this, but was hesitant to poll that frequently. I just found NIST's NTP page >> and they specify to not poll more frequently that every 4 seconds (minpoll >> 2). I wouldn't have thought that they would want polling with minpoll 3, but >> it appears I was wrong. This may fix the issue by itself. > > Using such a short polling interval over Internet would be a horrible > idea. NIST servers are overloaded and located in a network that has > problems with asymmetric routing. It's better to avoid them if > accuracy is a requirement. I thought you were using those stratum-1 > servers you have and the requirement for accuracy was 10 or 100 > microseconds, not milliseconds. > > Anything should do better than 50 milliseconds as long as it's on > local network. > > -- > Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
I also assumed that despite what you wrote you were using your (too few) S1 devices. I would agree that you probably should not poll NIST at small intervals for various reasons. However I suspect that there's a deeper misunderstanding. Per NIST the US Federal GNSS system (known as the Global Positioning System or GPS) can be part of system* that is considered to produce measurements traceable to the NIST national standards. Using NIST servers via the public Internet likely *cannot* produce measurements that are traceable to NIST (in a meaningful way). *"GPS disciplined oscillators can be used to establish traceability to the national time and frequency standards maintained by NIST" [ https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive]. Note that NTP fed by a GPS PPS produces a GPS disciplined oscillator. On Fri, May 26, 2017 at 10:31 AM, Matthew Huff wrote: > We do sync our systems to our stratum 1 servers. The issue is that the > regulations require us to verify that we aren't 50 msec away from NIST > time, not GPS time. By running our stratum 2 servers with a preference to > nist servers and also other ntp servers, our client machines can connect to > our stratum 1 and 2 servers and we can monitor the diff between the local > client time and NIST > > > On May 26, 2017, at 9:49 AM, Miroslav Lichvar > wrote: > > > >> On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: > >> Thanks. I agree that the appliance doesn’t appear to exist. It’s a > shame that it doesn’t, I think it would be a good idea. > >> > >> The 50 msec isn’t that hard to reach on an average basis, but we > routinely see drifts away from that on occasions. The minpoll idea would > probably fix this, but was hesitant to poll that frequently. I just found > NIST’s NTP page and they specify to not poll more frequently that every 4 > seconds (minpoll 2). I wouldn’t have thought that they would want polling > with minpoll 3, but it appears I was wrong. This may fix the issue by > itself. > > > > Using such a short polling interval over Internet would be a horrible > > idea. NIST servers are overloaded and located in a network that has > > problems with asymmetric routing. It's better to avoid them if > > accuracy is a requirement. I thought you were using those stratum-1 > > servers you have and the requirement for accuracy was 10 or 100 > > microseconds, not milliseconds. > > > > Anything should do better than 50 milliseconds as long as it's on > > local network. > > > > -- > > Miroslav Lichvar > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
We do sync our systems to our stratum 1 servers. The issue is that the regulations require us to verify that we aren't 50 msec away from NIST time, not GPS time. By running our stratum 2 servers with a preference to nist servers and also other ntp servers, our client machines can connect to our stratum 1 and 2 servers and we can monitor the diff between the local client time and NIST > On May 26, 2017, at 9:49 AM, Miroslav Lichvar wrote: > >> On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: >> Thanks. I agree that the appliance doesn’t appear to exist. It’s a shame >> that it doesn’t, I think it would be a good idea. >> >> The 50 msec isn’t that hard to reach on an average basis, but we routinely >> see drifts away from that on occasions. The minpoll idea would probably fix >> this, but was hesitant to poll that frequently. I just found NIST’s NTP page >> and they specify to not poll more frequently that every 4 seconds (minpoll >> 2). I wouldn’t have thought that they would want polling with minpoll 3, but >> it appears I was wrong. This may fix the issue by itself. > > Using such a short polling interval over Internet would be a horrible > idea. NIST servers are overloaded and located in a network that has > problems with asymmetric routing. It's better to avoid them if > accuracy is a requirement. I thought you were using those stratum-1 > servers you have and the requirement for accuracy was 10 or 100 > microseconds, not milliseconds. > > Anything should do better than 50 milliseconds as long as it's on > local network. > > -- > Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote: > Thanks. I agree that the appliance doesn’t appear to exist. It’s a shame that > it doesn’t, I think it would be a good idea. > > The 50 msec isn’t that hard to reach on an average basis, but we routinely > see drifts away from that on occasions. The minpoll idea would probably fix > this, but was hesitant to poll that frequently. I just found NIST’s NTP page > and they specify to not poll more frequently that every 4 seconds (minpoll > 2). I wouldn’t have thought that they would want polling with minpoll 3, but > it appears I was wrong. This may fix the issue by itself. Using such a short polling interval over Internet would be a horrible idea. NIST servers are overloaded and located in a network that has problems with asymmetric routing. It's better to avoid them if accuracy is a requirement. I thought you were using those stratum-1 servers you have and the requirement for accuracy was 10 or 100 microseconds, not milliseconds. Anything should do better than 50 milliseconds as long as it's on local network. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
Correct. However that is costly. We already have 2 x Stratum 1 microsemi servers and it's overkill for a stratum 2 server that gets it's time from internet NTP sources. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -Original Message- > From: questions [mailto:questions-bounces+mhuff=ox@lists.ntp.org] > On Behalf Of Jochen Bern > Sent: Friday, May 26, 2017 8:53 AM > To: questions@lists.ntp.org > Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance > > On 05/26/2017 12:25 PM, Matthew Huff wrote: > > You are correct that we don't need OXCO oscillators, and we could > drop > > that requirement, but it would be a good indicator that the hardware > > manufacturer isn't just slapping a regular PC together. > > I'ld guess that buying a stratum *1* unit with the capability to use a > "fallback" NTP source might be a better (and more readily available) > indicator for that ... > > Regards, > -- > Jochen Bern > Systemingenieur > > Fon:+49 6151 9067-231 > Fax:+49 6151 9067-290 > E-Mail: jochen.b...@binect.de > > www.binect.de > www.facebook.de/binect > > Binect ist ausgezeichnet: > Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 > > Binect GmbH > > Robert-Koch-Straße 9, 64331 Weiterstadt, DE > > Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold > Unternehmenssitz: Weiterstadt > Register: Amtsgericht Darmstadt, HRB 94685 > Umsatzsteuer-ID: DE 221 302 264 > > MAX 21-Unternehmensgruppe > ✁ > Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht > der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, > informieren Sie bitte sofort den Absender und vernichten Sie diese > E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser > Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der > Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch > schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu > einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH > ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen > unternommen, > um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu > minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf > alle Anhänge an dieser Nachricht durchzuführen. > Wir schließen, außer für den Fall von Vorsatz oder grober > Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch > virenbefallene Software oder E-Mail aus. > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any > unauthorized copying, disclosure or distribution of contents of this > e-mail is strictly prohibited. All Binect GmbH emails are created > thoroughly, nevertheless we do not accept any legal obligation for the > information and wording contained herein. Binect GmbH has taken > precautionary measures to reduce the risk of possible distribution of > virus infected software or emails. However, we advise you to check > attachments to this email for viruses. Except for cases of intent or > gross negligence, we cannot accept any legal obligation for loss or > damage by virus infected software. > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
Thanks. I agree that the appliance doesn’t appear to exist. It’s a shame that it doesn’t, I think it would be a good idea. The 50 msec isn’t that hard to reach on an average basis, but we routinely see drifts away from that on occasions. The minpoll idea would probably fix this, but was hesitant to poll that frequently. I just found NIST’s NTP page and they specify to not poll more frequently that every 4 seconds (minpoll 2). I wouldn’t have thought that they would want polling with minpoll 3, but it appears I was wrong. This may fix the issue by itself. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-694-5669 From: Paul [mailto:tik-...@bodosom.net] Sent: Friday, May 26, 2017 8:03 AM To: Matthew Huff Cc: NTP Questions Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance "The Securities and Exchange Commission (SEC) approved a new clock synchronization standard of 50 milliseconds applicable to computer clocks that are used to record certain events in NMS securities or OTC equity securities. Firms have six months from the effective date, until February 20, 2017, to apply the new 50 millisecond standard to impacted system clocks that capture time in milliseconds. Firms have eighteen months from the effective date, until February 19, 2018, to apply the new standard to impacted system clocks that do not capture time in milliseconds. [http://www.finra.org/industry/notices/16-23]"; Perhaps you are referring to something other than the above requirement. In any case 50 or 5 milliseconds is easily achieved on any random computer unless there are uncontrolled external events. You should control those events. A common problem is setting minpoll to some value other than 3. Another is a misconfigured NIC or a speed mismatch. Our nearly unmaintained S2 Linux servers manage less than 100 microseconds of jitter and 500 microseconds of offset compared to the S1 servers. I'd be surprised if an appliance as spec'ed exists. On Fri, May 26, 2017 at 6:25 AM, Matthew Huff mailto:mh...@ox.com>> wrote: The issues is that sometimes our stratum 2 servers drift away from NIST time (our stratum 2 servers are synced to NIST stratum 1 servers) by > 5 msec, violating FINRA regulations (it's a silly requirement). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
> Le 26 mai 2017 à 11:35, Matthew Huff a écrit : > > The OXCO oscillator requirement is for hold-over, but we are looking for less > jitter in the system. We could strip down the OS machines and run only NTP > and make other system adjustments that would accomplish much of the same, but > to dedicated a server just for NTP when an appliance is available seems a > waste. > > FINRA has made new timing requirements that are pushing this. Switching to > PTP is ultimately the solution, but the switches in our core data center > don't support it, and would be very costly to migrate to. > You could check out the Spectracom NetClock Model 9489, which although is primarily a GPS stratum one device, also has Ethernet input for stratum 2 operation. It has a TCXO as LO, but with S1 servers upstream should easily keep to the FIRNA constraints that I have been able to dig up. Any unloaded (other than NTP) micro server will get there as well. Mixing NTP with production loads never works. > > > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff| Fax: 914-694-5669 > > >> -Original Message- >> From: Miroslav Lichvar [mailto:mlich...@redhat.com] >> Sent: Friday, May 26, 2017 5:29 AM >> To: Matthew Huff >> Cc: NTP Questions >> Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance >> >> On Thu, May 25, 2017 at 11:31:27AM +, Matthew Huff wrote: >>> For the last 20 years I've run our stratum 2 ntp servers under >> Solaris then Linux. I'm looking to replace them with an appliance for a >> number of reasons. One of the main one is clock stability. We have 2 >> microsemi GPS synced stratum 1 servers with rubidium oscillators. I am >> not looking for a linux/bsd/unix box running NTP, but a dedicated non- >> os appliance. >> >> I don't know if such an appliance exists (all I saw that had a real >> NTP client ran a regular OS), but I'm curious what problems is the >> (in)stability of an ordinary computer oscillator causing. Are the >> servers supposed to be able to hold over long periods of time in case >> the stratum-1 servers fail? >> >> -- >> Miroslav Lichvar > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On 05/26/2017 12:25 PM, Matthew Huff wrote: > You are correct that we don't need OXCO oscillators, and we could drop > that requirement, but it would be a good indicator that the hardware > manufacturer isn't just slapping a regular PC together. I'ld guess that buying a stratum *1* unit with the capability to use a "fallback" NTP source might be a better (and more readily available) indicator for that ... Regards, -- Jochen Bern Systemingenieur Fon:+49 6151 9067-231 Fax:+49 6151 9067-290 E-Mail: jochen.b...@binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 Binect GmbH Robert-Koch-Straße 9, 64331 Weiterstadt, DE Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
"The Securities and Exchange Commission (SEC) approved a new clock synchronization standard of 50 milliseconds applicable to computer clocks that are used to record certain events in NMS securities or OTC equity securities. Firms have six months from the effective date, until February 20, 2017, to apply the new 50 millisecond standard to impacted system clocks that capture time in milliseconds. Firms have eighteen months from the effective date, until February 19, 2018, to apply the new standard to impacted system clocks that do not capture time in milliseconds. [ http://www.finra.org/industry/notices/16-23]"; Perhaps you are referring to something other than the above requirement. In any case 50 or 5 milliseconds is easily achieved on any random computer unless there are uncontrolled external events. You should control those events. A common problem is setting minpoll to some value other than 3. Another is a misconfigured NIC or a speed mismatch. Our nearly unmaintained S2 Linux servers manage less than 100 microseconds of jitter and 500 microseconds of offset compared to the S1 servers. I'd be surprised if an appliance as spec'ed exists. On Fri, May 26, 2017 at 6:25 AM, Matthew Huff wrote: > The issues is that sometimes our stratum 2 servers drift away from NIST > time (our stratum 2 servers are synced to NIST stratum 1 servers) by > 5 > msec, violating FINRA regulations (it's a silly requirement). > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
The OXCO oscillator requirement is for hold-over, but we are looking for less jitter in the system. We could strip down the OS machines and run only NTP and make other system adjustments that would accomplish much of the same, but to dedicated a server just for NTP when an appliance is available seems a waste. FINRA has made new timing requirements that are pushing this. Switching to PTP is ultimately the solution, but the switches in our core data center don't support it, and would be very costly to migrate to. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -Original Message- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Friday, May 26, 2017 5:29 AM > To: Matthew Huff > Cc: NTP Questions > Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance > > On Thu, May 25, 2017 at 11:31:27AM +, Matthew Huff wrote: > > For the last 20 years I've run our stratum 2 ntp servers under > Solaris then Linux. I'm looking to replace them with an appliance for a > number of reasons. One of the main one is clock stability. We have 2 > microsemi GPS synced stratum 1 servers with rubidium oscillators. I am > not looking for a linux/bsd/unix box running NTP, but a dedicated non- > os appliance. > > I don't know if such an appliance exists (all I saw that had a real > NTP client ran a regular OS), but I'm curious what problems is the > (in)stability of an ordinary computer oscillator causing. Are the > servers supposed to be able to hold over long periods of time in case > the stratum-1 servers fail? > > -- > Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
You make some good points, but regulations don't always make technical sense. You are correct that we don't need OXCO oscillators, and we could drop that requirement, but it would be a good indicator that the hardware manufacturer isn't just slapping a regular PC together. Replacing the NIC card on hundreds of servers and in some cases replacing/upgrading blades would be more expensive/time consuming than just purchasing dedicated NTP servers. It is our long term goal especially since we will eventually move to PTP. Our blade chassis at our colo site are already using PTP, just not our core datacenter. The issues is that sometimes our stratum 2 servers drift away from NIST time (our stratum 2 servers are synced to NIST stratum 1 servers) by > 5 msec, violating FINRA regulations (it's a silly requirement). We are just trying to do our due diligence. I think I could accomplish the same thing by dedicated an OS box for just NTP, but again, if there was an appliance, and cost effective, it would be better. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -Original Message- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Friday, May 26, 2017 6:17 AM > To: Matthew Huff > Cc: NTP Questions > Subject: Re: [ntp:questions] Looking for a NTP stratum 2 appliance > > On Fri, May 26, 2017 at 09:35:14AM +, Matthew Huff wrote: > > The OXCO oscillator requirement is for hold-over, but we are looking > for less jitter in the system. We could strip down the OS machines and > run only NTP and make other system adjustments that would accomplish > much of the same, but to dedicated a server just for NTP when an > appliance is available seems a waste. > > If the stratum-1 servers have stable clocks for hold-over, will OXCO > on stratum-2 server make much of a difference? Also, why not point the > clients directly to the stratum-1 servers? > > > FINRA has made new timing requirements that are pushing this. > Switching to PTP is ultimately the solution, but the switches in our > core data center don't support it, and would be very costly to migrate > to. > > You might want to consider using NTP with HW timestamping if you have > servers with NICs that support it. In my experience that usually > reduces the jitter down to a sub-microsecond level. Unless the network > is heavily loaded for longer periods of time, it should not be > necessary to use PTP and expensive switches. > > -- > Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Fri, May 26, 2017 at 09:35:14AM +, Matthew Huff wrote: > The OXCO oscillator requirement is for hold-over, but we are looking for less > jitter in the system. We could strip down the OS machines and run only NTP > and make other system adjustments that would accomplish much of the same, but > to dedicated a server just for NTP when an appliance is available seems a > waste. If the stratum-1 servers have stable clocks for hold-over, will OXCO on stratum-2 server make much of a difference? Also, why not point the clients directly to the stratum-1 servers? > FINRA has made new timing requirements that are pushing this. Switching to > PTP is ultimately the solution, but the switches in our core data center > don't support it, and would be very costly to migrate to. You might want to consider using NTP with HW timestamping if you have servers with NICs that support it. In my experience that usually reduces the jitter down to a sub-microsecond level. Unless the network is heavily loaded for longer periods of time, it should not be necessary to use PTP and expensive switches. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On Thu, May 25, 2017 at 11:31:27AM +, Matthew Huff wrote: > For the last 20 years I've run our stratum 2 ntp servers under Solaris then > Linux. I'm looking to replace them with an appliance for a number of reasons. > One of the main one is clock stability. We have 2 microsemi GPS synced > stratum 1 servers with rubidium oscillators. I am not looking for a > linux/bsd/unix box running NTP, but a dedicated non-os appliance. I don't know if such an appliance exists (all I saw that had a real NTP client ran a regular OS), but I'm curious what problems is the (in)stability of an ordinary computer oscillator causing. Are the servers supposed to be able to hold over long periods of time in case the stratum-1 servers fail? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Looking for a NTP stratum 2 appliance
For the last 20 years I've run our stratum 2 ntp servers under Solaris then Linux. I'm looking to replace them with an appliance for a number of reasons. One of the main one is clock stability. We have 2 microsemi GPS synced stratum 1 servers with rubidium oscillators. I am not looking for a linux/bsd/unix box running NTP, but a dedicated non-os appliance. I'm looking for: 1) Stratum 2 NTP server (does not need IRIG, PPS, GPS, or other inputs, only needs to get its source from NTP stratum 1 servers) 2) OXCO oscillator or better 3) Support for hundreds of NTP clients (does not need to support thousands+) 4) Internal only clients, no external exposure 5) Rack mountable 6) Hardware support (next business day replacement) 7) Regular software updates (NTP and security fixes) 8) Preferably under $2,000 US Any suggestions? Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
