Re: [ntp:questions] Issues trying to sync to NIST public servers

2019-02-02 Thread Jan Ceuleers
On 03/02/2019 00:39, François Meyer wrote:
>
> In case NIST servers are hard to reach, a metrologically defendable
> fallback could be to use ntp servers from another national metrology
> institute which would provide the same traceability to UTC. 

I agree that this is a sensible answer from a technical perspective.
However has anyone else done this and passed SEC scrutiny? Remember that
US law is rules-based, not principles-based.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Issues trying to sync to NIST public servers

2019-02-02 Thread Majdi S. Abbas
On Fri, Feb 01, 2019 at 11:52:40AM -0500, Erez Lirov wrote:
> I'm sorry.. I meant almost immediate in comparison to the nist servers,
> which often never sync.  It does take a couple of minutes to get there with
> the non nist servers.  We're not using burst mode, but polling every 16
> seconds.

Try with the default min and maxpoll; if you're polling NIST
that often you are likely being rate limited.

--msa
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Issues trying to sync to NIST public servers

2019-02-02 Thread François Meyer

Yes, the main reason behind the requirement is probably the traceability
to UTC of the stratum 0 used by the server : NIST servers are traceable
to UTC, which is (formally) not the case for a server with a GNSS
as stratum 0.

In case NIST servers are hard to reach, a metrologically defendable fallback 
could be to use ntp servers from another national metrology institute 
which would provide the same traceability to UTC.


From the US, servers operated by the NRC in Canada is the most 
sensible (geographically speaking) option, and those servers 
have the same traceability status as NIST servers.


https://www.nrc-cnrc.gc.ca/eng/services/time/network_time.html

Just log the reason why you pick a server outside the US, locate 
and log the page on the NRC site stating the traceability to UTC

of their time servers and Bob's your uncle ; thats enough to prove
that you have taken the issue seriously and have taken the appropriate 
steps to ensure both your requirements and the traceability concern.


In Europe, picking a server operated by for example PTB in Germany, 
OP (Syrte) in France, NPL in the UK and so on would do the job.



On Fri, 1 Feb 2019, Jason Rabel wrote:


Yes, this is a common PITA. FINRA and/or SEC getting onto you?
They are still "defining" the regulation, but the current idea is rather silly.
Many of the NIST servers are run out of the University of Colorado and
are single home with CenturyLink. Congestion and/or other network
issues causes false alarms all the time.


I don't know anything about the financial regulations, but what about
having a local GNSS or cellular based S1 NTP (or PTP) server? You will
gain an order of magnitude in accuracy syncing to a LAN source vs
traversing the Internet. Or possibly using the USNO NTP servers? I
suppose if it *has* to be traceable to NIST (which operates
independently of USNO/GPS) you could get a WWVB based NTP server. NIST
& USNO are generally less than 10 ns difference from each other, which
for NTP over ethernet the best you are going to get is in the ms range
so it's technically a non-issue.


IMHO, if FINRA is going to require something like that, then NIST should
provide hardened NTP/PTP services at major peering/colocation facilities.


Or use existing facilities at other major universities around the
country that could also benefit from having extra local NIST-synced
atomic standards.

I've often wondered why they don't have multiple network providers at
their two existing facilities, having a single point of failure seems
awfully ironic seeing as how they have dozens of atomic clocks and
servers in the facility... lol.

Though one has to remember this is also a very tiny part of overall
NIST. IIRC last time I saw NIST's 2019 budget figures they were taking
a pretty sizable cut in funding across the board, so expanding
services is probably out of the question unless it's deemed critical
for national security or something (Which I would think would still
fall under USNO & GPS before NIST).

Jason
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions



--
François Meyer
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Issues trying to sync to NIST public servers

2019-02-02 Thread Erez Lirov
Emailed.. no response so far

On Fri, Feb 1, 2019, 12:05 AM Kiss Gábor  > We're having issues syncing to all nist servers:
> > https://tf.nist.gov/tf-cgi/servers.cgi
>
> > Unfortunately, government regulations require us to sync to a public
> NIST server.  Any ideas?
>
> Have you already asked NIST?
> The above web page writes:
> | Please address comments to: jlev...@nist.gov
>
> Gabor
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Issues trying to sync to NIST public servers

2019-02-02 Thread Erez Lirov
I'm sorry.. I meant almost immediate in comparison to the nist servers,
which often never sync.  It does take a couple of minutes to get there with
the non nist servers.  We're not using burst mode, but polling every 16
seconds.

On Fri, Feb 1, 2019, 10:46 AM Majdi S. Abbas  On Wed, Jan 30, 2019 at 01:23:42PM -0800, eli...@espoc.com wrote:
> > We're having issues syncing to all nist servers:
> > https://tf.nist.gov/tf-cgi/servers.cgi
> >
> > But are easily able to sync to time.google.com and pool.ntp.org.
> >
> > ntpq -p shows reach numbers that clearly indicate intermittent failures
> (even numbers etc)
> > when going against any nist server (including time.nist.gov, but zero
> failures and almost
> > immediate reach of 377 when syncing to pool.ntp.org or time.google.com.
>
> Immediate 377?
>
> Are you using burst mode?
>
> --msa
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions