[ntp:questions] Looking for a NTP stratum 2 appliance
mhuff at ox.com
Fri May 26 17:25:57 UTC 2017
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 <mhuff at ox.com> wrote:
> Sorry, via NTP and not GPS
>> On May 26, 2017, at 1:18 PM, Matthew Huff <mhuff at ox.com> 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 <tik-tok at bodosom.net<mailto:tik-tok at 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 <mhuff at ox.com<mailto:mhuff at 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 <mlichvar at redhat.com<mailto:mlichvar at redhat.com>> wrote:
>>>> On Fri, May 26, 2017 at 12:11:30PM +0000, 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 at lists.ntp.org
> questions mailing list
> questions at lists.ntp.org
More information about the questions