Re: [LEAPSECS] UT1 via NTP

[Rob Seaman]

Heading to the telescope to work on timekeeping for a new instrument, so
don't have time to write emails talking about timekeeping for the old
ones :-)

NTP, of course, can be used with local reference clocks. It would be
great if the NIST UT1 implementation were available for local
deployment, or perhaps the GNSS vendors could support same.

That said, there are use cases for Universal Time over NTP - indeed,
nearly all of them currently - and in addition to precision timekeeping
for scientists, I believe this will continue for many other communities
and the requirements will grow should UTC itself no longer serve this role.

And on the other hand, radio astronomers, solar system astronomers,
space situational awareness, precision navigation, etc, may well need
UT1 now and in the future to significantly more precision than a tenth
second. Indeed, UT1 itself is measured with respect to distant fixed
radio sources.

Jamming of GPS / GNSS is a different, if also important, thread. What
are the robust alternatives for widely distributed sources of TAI / UTC?

Rob

--


On 3/21/18 9:06 AM, Steve Allen wrote:
> On Wed 2018-03-21T08:51:37-0700 Steve Allen hath writ:
>> Our robotic telescope with small FOV on the guider does better if it
>> is given UT1 to 0.1 second.  That telescope grabs the USNO predictions
>> of EOP every week to update the pointing.
> I'll add that I do not see any place where I would want to use UT1 via
> NTP for astronomical observations.  The real-time operation of the
> telescopes does not want to be dependent on a very small number of
> external real-time sources over telecomm links that can fail.
>
> That is why we rely on the USNO predictions, for they give us several
> months of lookahead.  Thus also we have several months of warning if
> the USNO decides to stop publishing EOP, and that is enough time to
> engineer a replacement source of information.
>
> It was not happy when DoD was doing theater-level jamming near Hawaii
> and the Keck telescope GPS time servers had dates that were completely
> insane.  In that case the local system clocks retained sanity for the
> duration of the jamming.  In extension of all this I argue again that
> what is really wanted is a source of Atomic Time that is completely
> robust plus a widely disseminated source of tabular or polynomial
> predictions of Atomic Time minus Universal Time.
>
> --
> Steve Allen  WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
> 1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
> Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Steve Allen]

On Wed 2018-03-21T08:51:37-0700 Steve Allen hath writ:
> Our robotic telescope with small FOV on the guider does better if it
> is given UT1 to 0.1 second.  That telescope grabs the USNO predictions
> of EOP every week to update the pointing.

I'll add that I do not see any place where I would want to use UT1 via
NTP for astronomical observations.  The real-time operation of the
telescopes does not want to be dependent on a very small number of
external real-time sources over telecomm links that can fail.

That is why we rely on the USNO predictions, for they give us several
months of lookahead.  Thus also we have several months of warning if
the USNO decides to stop publishing EOP, and that is enough time to
engineer a replacement source of information.

It was not happy when DoD was doing theater-level jamming near Hawaii
and the Keck telescope GPS time servers had dates that were completely
insane.  In that case the local system clocks retained sanity for the
duration of the jamming.  In extension of all this I argue again that
what is really wanted is a source of Atomic Time that is completely
robust plus a widely disseminated source of tabular or polynomial
predictions of Atomic Time minus Universal Time.

--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Steve Allen]

On Wed 2018-03-21T03:19:15-0700 Hal Murray hath writ:
> I haven't seen any comments from astronomers with info on how accurate they
> need UT1.

It depends.  I described several telescopes for Future of UTC.
paper 678 at
http://hanksville.org/futureofutc/2011/preprints/index.html

Optical telescopes have to be able to find a target where atmospheric
refraction amounts to several arc minutes, and unpredictable
variations of that can amount to many arc seconds.  So in many cases
one second of time is plenty good.

Our robotic telescope with small FOV on the guider does better if it
is given UT1 to 0.1 second.  That telescope grabs the USNO predictions
of EOP every week to update the pointing.

--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] UT1 via NTP

[Hal Murray]

I haven't seen any comments from astronomers with info on how accurate they 
need UT1.



-- 
These are my opinions.  I hate spam.



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Hal Murray]

Gary said:
> It would be simple to mod an NTP client to download and apply that
> correction.  No need for a new protocol.

The question is how many users are there.  If there are only a few, then they 
should all just download the official IERS version or one of the clones.

If there are enough users so that the downloads would be a serious load, then 
a lightweight protocol like NTP makes sense.  But NTP isn't very accurate 
unless there is a good network connection which usually means close 
geographically.  Thus, if you want good UT1, you either need lots of servers 
so most users can find one nearby or we need a new protocol that just 
distributes the offset.


-- 
These are my opinions.  I hate spam.



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Martin Burnicki]

Hi Gary,

> Yo Warner!
> 
> On Mon, 19 Mar 2018 14:12:40 -0600 Warner Losh 
> wrote:
> 
>>> Looks to me about a kinda sort maybe 1 micro second per day
>>> shift.
>>> 
>> 
>> Should be closer to 1ms/day. And it is: the above is 4.6ms in 6
>> days or 770us/day.
> 
> Yup, I read it wrong, you read it right.
> 
> Bulletin D, what is broadcast over WWV, is here:
> 
> https://datacenter.iers.org/eop/-/somos/5Rgv/latest/17

If I understand this correctly then the UT1-UTC number in Bulletin A
should better be used, which provides a prediction for the near future:
https://datacenter.iers.org/eop/-/somos/5Rgv/latest/6

Martin
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Martin Burnicki]

Rob Seaman wrote:
> One uses the tools as designed for diverse purposes. NTP in a pool
> environment is accurate to a few milliseconds. With our local GNSS
> references something better than a millisecond. With an IRIG shared
> memory reference maybe an order of magnitude better. Hardware time
> capture for our Meinberg IRIG PCIe cards is spec'ed and measured to 5
> microseconds. The PTP versions of those cards quotes something better
> than 1 microsecond. Hardware time capture to OCXO in the Meinberg M1000
> should be precise / accurate to 100 nanoseconds. All of these are
> commercially available with only ordinary attention to metrology, e.g.,
> like understanding the calibration of a precision balance in a lab.
> Meinberg has an excellent monitoring tool built in to their reference
> clocks.
> 
> "Customers" (internal or external) for astronomical timekeeping (but
> should be applicable to other fields) may require TAI, GPS, UTC, UT1, or
> more esoteric things like TT. I can set the Meinberg references to
> deliver all of these except UT1. All the rest would follow. I'd be happy
> to hear about support from other vendors. Needless to say, commercial
> timekeeping vendors should also be expected to implement conforming leap
> second support for their internet attached devices.

ntpd has already built-in support for leap second smearing. This means,
it anyway reads a leap second file as provided by NIST or IERS, checks
automatically if a new file version is available, and then optionally
applies a smearing offset to the time sent to its clients, if configured
to do so. The internal system time would still be UTC, though.

Similarly, it shouldn't be too hard to add some support to read a DUT1
file, and apply the DUT1 offset to the time sent to clients. So you
could easily set up your own UT1 server.

However, similar to the leapsecond file, it has to be made sure that the
DUT1 file is updated as necessary. This could be done automatically by
scripts / wget / curl, similar as it's done with the leap second file.

Of course it would be possible to set up an extra DUT1 server, as Hal
has suggested, but then each client had to get UTC from one source, the
DUT1 offset from another source, and put things together.

A manual or automatic feed of the DUT1 numbers would be required in both
cases, so which approach is to be preferred depends on the accuracy and
other requirements of the tasks that have to be solved.

Martin
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Gary E. Miller]

Yo Warner!

On Mon, 19 Mar 2018 14:12:40 -0600
Warner Losh  wrote:

> > Looks to me about a kinda sort maybe 1 micro second per day shift.
> >  
> 
> Should be closer to 1ms/day. And it is: the above is 4.6ms in 6 days
> or 770us/day.

Yup, I read it wrong, you read it right.

Bulletin D, what is broadcast over WWV, is here:

https://datacenter.iers.org/eop/-/somos/5Rgv/latest/17

"From the 15 March 2018, 0h UTC until further notice, the value of DUT1
to be disseminated with the time signals will be DUT1 = +0.1 s"

It would be simple to mod an NTP client to download and apply that
correction.  No need for a new protocol.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpC2iOTcQnGq.pgp
Description: OpenPGP digital signature
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Warner Losh]

On Mon, Mar 19, 2018 at 2:02 PM, Gary E. Miller  wrote:

> Yo Hal!
>
> On Mon, 19 Mar 2018 12:41:46 -0700
> Hal Murray  wrote:
>
> > Perhaps we should setup a simple UDP server that responds with the
> > UT1-UTC offset.  The idea is that you can get a good UTC via GPS or
> > good local NTP servers.
>
> How about the client just downloads the daily UT1 to UTC correction
> data, then adjusts UTC(GPS)?
>
> http://maia.usno.navy.mil/ser7/ser7.dat
>
> Here is a sample of this week's report:
>
>   IERS Rapid Service
>   MJD  xerror yerror   UT1-UTC   error
>"  "   "  "ss
>18  3  9  58186 0.00803 .9 0.36036 .9  0.157823 0.11
>18  3 10  58187 0.00857 .9 0.36159 .9  0.157100 0.06
>18  3 11  58188 0.00974 .9 0.36269 .9  0.156399 0.04
>18  3 12  58189 0.01137 .9 0.36401 .9  0.155694 0.03
>18  3 13  58190 0.01283 .9 0.36560 .9  0.154949 0.65
>18  3 14  58191 0.01385 .9 0.36737 .9  0.154118 0.65
>18  3 15  58192 0.01450 .9 0.36927 .9  0.153196 0.55
>
> Looks to me about a kinda sort maybe 1 micro second per day shift.
>

Should be closer to 1ms/day. And it is: the above is 4.6ms in 6 days or
770us/day.

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Rob Seaman]

One uses the tools as designed for diverse purposes. NTP in a pool
environment is accurate to a few milliseconds. With our local GNSS
references something better than a millisecond. With an IRIG shared
memory reference maybe an order of magnitude better. Hardware time
capture for our Meinberg IRIG PCIe cards is spec'ed and measured to 5
microseconds. The PTP versions of those cards quotes something better
than 1 microsecond. Hardware time capture to OCXO in the Meinberg M1000
should be precise / accurate to 100 nanoseconds. All of these are
commercially available with only ordinary attention to metrology, e.g.,
like understanding the calibration of a precision balance in a lab.
Meinberg has an excellent monitoring tool built in to their reference
clocks.

"Customers" (internal or external) for astronomical timekeeping (but
should be applicable to other fields) may require TAI, GPS, UTC, UT1, or
more esoteric things like TT. I can set the Meinberg references to
deliver all of these except UT1. All the rest would follow. I'd be happy
to hear about support from other vendors. Needless to say, commercial
timekeeping vendors should also be expected to implement conforming leap
second support for their internet attached devices.

Rob

--


On 3/19/18 12:41 PM, Hal Murray wrote:
>> The issue has come up now since a colleague asked about best practices for
>> access to UT1. In the mean time he's implemented yet another internet
>> retrieval of Bulletin A. Perhaps it needs to be stressed again, astronomers
>> require access to both Universal Time and Atomic Time. 
> What level of accuracy are you interested in?
>
> NTP is unlikely to provide good results if there is only one server and there 
> isn't a good network connection to it.
>
> Perhaps we should setup a simple UDP server that responds with the UT1-UTC 
> offset.  The idea is that you can get a good UTC via GPS or good local NTP 
> servers.
>
>

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] UT1 via NTP

[Gary E. Miller]

Yo Hal!

On Mon, 19 Mar 2018 12:41:46 -0700
Hal Murray  wrote:

> Perhaps we should setup a simple UDP server that responds with the
> UT1-UTC offset.  The idea is that you can get a good UTC via GPS or
> good local NTP servers.

How about the client just downloads the daily UT1 to UTC correction
data, then adjusts UTC(GPS)?

http://maia.usno.navy.mil/ser7/ser7.dat

Here is a sample of this week's report:

  IERS Rapid Service   
  MJD  xerror yerror   UT1-UTC   error 
   "  "   "  "ss   
   18  3  9  58186 0.00803 .9 0.36036 .9  0.157823 0.11  
   18  3 10  58187 0.00857 .9 0.36159 .9  0.157100 0.06  
   18  3 11  58188 0.00974 .9 0.36269 .9  0.156399 0.04  
   18  3 12  58189 0.01137 .9 0.36401 .9  0.155694 0.03  
   18  3 13  58190 0.01283 .9 0.36560 .9  0.154949 0.65  
   18  3 14  58191 0.01385 .9 0.36737 .9  0.154118 0.65  
   18  3 15  58192 0.01450 .9 0.36927 .9  0.153196 0.55  

Looks to me about a kinda sort maybe 1 micro second per day shift.


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpV7_xf6MvMR.pgp
Description: OpenPGP digital signature
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs