Re: [ntp:questions] NTP Servers in virtual machines

[Rob]

William Unruh  wrote:
> You canrun ntp on the machine that runs the virtual hardware, and tell
> the virutal machines to get their time from the real system.

This is not possible on "real" virtual machine systems.

You can do it on your Linux box at home where you virtualize some systems
for testing, but not on a VMware ESXi host, for example.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Miroslav Lichvar]

On Mon, Jun 23, 2014 at 11:45:16PM -0500, Mike S wrote:
> On 6/16/2014 6:05 AM, Jochen Bern wrote:
> 
> >There are four official slots - two primary, two secondary - over the
> >course of the year to insert leap seconds,
> 
> Those are only preferences. Leap seconds may be inserted at any month
> boundary.
> 
> "A positive or negative leap-second should be the last second of a UTC
> month, but first preference should be given to the end of December and June,
> and second preference to the end of March and September." - ITU-R TF.460-6

Sooner or later, not even 12 leap seconds per year will be enough to
keep UTC close to UT1. Hopefully they will be abolished long before
that.

Practically speaking, beside having to make more than two corrections
per year (which is not expected to happen in the next few decades),
could there be any reason to do it in other months than June and
December? Older ntpd versions (< 4.2.5p53) used to check the month
before setting the leap flag and I'm wondering if it still can used to
detect spurious leap seconds.

FWIW, the IERS announcements say "Leap seconds can be introduced in
UTC at the end of the months of December or June, depending on the
evolution of UT1-TAI."

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Jochen Bern]

On -10.01.-28163 20:59, Miroslav Lichvar wrote:
> On Mon, Jun 23, 2014 at 11:45:16PM -0500, Mike S wrote:
>> On 6/16/2014 6:05 AM, Jochen Bern wrote:
>>> There are four official slots - two primary, two secondary - over the
>>> course of the year to insert leap seconds,
>> Those are only preferences. Leap seconds may be inserted at any month
>> boundary.

I'm positive that I've *seen* ntpd do the poll-interval-reduce on a
*quarterly* base a couple years back.

As Miroslav mentioned, the IERS - the guys who *schedule* leap seconds -
currently *use* only the primaries, while still *mentioning* the
secondaries as well:

"Leap seconds can be introduced in UTC at the end of the months of
December or June, depending on the evolution of UT1-TAI. [...] According
to the CCIR Recommendation, first preference is given to the
opportunities at the end of December and June, and second preference to
those at the end of March and September."
--
http://www.iers.org/nn_10828/IERS/EN/Publications/Bulletins/directLinks/bulletin__C__MD.html

Of course the number of leap seconds required in recent years helped
sticking with only the primaries, so it's a bit unclear to me which of
all those choices are "for the moment" and which are long-term ...

> Sooner or later, not even 12 leap seconds per year will be enough to
> keep UTC close to UT1. Hopefully they will be abolished long before
> that.

I do not wish to see that day, regardless of whether you're referring to
a couple millennia of Earth-Moon tide-locking or a major off-center
impact giving the crust a new spin. :-S

> Practically speaking, beside having to make more than two corrections
> per year (which is not expected to happen in the next few decades),
> could there be any reason to do it in other months than June and
> December?

I've browsed the results of the infamous poll and most of the people
voting "abolish leap seconds" apparently didn't mean to actually
*abolish* them (as in, decouple UT1 and UTC, or whatever their
successors might be called), but to have them *rearranged* into fewer
and larger leaps. Of course, one can imagine that to go the other way -
i.e., smaller but more frequent leaps.

In general, I consider the entire procedure to first and foremost
reflect a couple *external* facts - namely, a) the time necessary to
propagate the decision on leap [whatever] scheduling to wherever it has
to be carried out (NTP is *not* the critical path there, I'd guess) and
b) the (ever-improving) quality of *prediction* of Earth's rotation.

If those two restrictions were to be removed (assume a giant tooth fairy
if you must ;-), I don't see a reason why the current UT1-UTC delta
could not be communicated through an "NTP-ng" in the same way today's
NTP shoves server-client deltas around and corrects for them - piecemeal
with every poll.

(Returning to your question as phrased, and circumstances as of today:
IIUC the quality of prediction *would* already suffice to attempt
scheduling leap seconds so as to aim for min-sum-of-squares, rather than
predefined schedule slots.)

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Servers in virtual machines

[William Unruh]

On 2014-06-24, Rob  wrote:
> William Unruh  wrote:
>> You canrun ntp on the machine that runs the virtual hardware, and tell
>> the virutal machines to get their time from the real system.
>
> This is not possible on "real" virtual machine systems.
>
> You can do it on your Linux box at home where you virtualize some systems
> for testing, but not on a VMware ESXi host, for example.

"NOt possible" meaning that the writers have not included this
possibility I assume you mean, not that it is impossible.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Miroslav Lichvar]

On Tue, Jun 24, 2014 at 12:08:10PM +0200, Jochen Bern wrote:
> I've browsed the results of the infamous poll and most of the people
> voting "abolish leap seconds" apparently didn't mean to actually
> *abolish* them (as in, decouple UT1 and UTC, or whatever their
> successors might be called), but to have them *rearranged* into fewer
> and larger leaps. Of course, one can imagine that to go the other way -
> i.e., smaller but more frequent leaps.

As someone who implemented support for leap seconds in several
applications, I'd really like to see them gone. Fixing all software
where time is critical to handle them correctly may not be possible
and from what I've heard a common solution is just to turn it off and
wait until it passes.

Making smaller but more frequent corrections would probably only make
it worse.

To me, it seems the reasonable thing to do would be to decouple UTC and
UT1 completely and make the adjustment at a higher level like
timezones if necessary. Countries adjust their timezones all the time,
we can handle that better.

> (Returning to your question as phrased, and circumstances as of today:
> IIUC the quality of prediction *would* already suffice to attempt
> scheduling leap seconds so as to aim for min-sum-of-squares, rather than
> predefined schedule slots.)

Good point. The question is if they will ever choose to do that.

Thanks,

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

Re: [ntp:questions] NTP Servers in virtual machines

[Rob]

William Unruh  wrote:
> On 2014-06-24, Rob  wrote:
>> William Unruh  wrote:
>>> You canrun ntp on the machine that runs the virtual hardware, and tell
>>> the virutal machines to get their time from the real system.
>>
>> This is not possible on "real" virtual machine systems.
>>
>> You can do it on your Linux box at home where you virtualize some systems
>> for testing, but not on a VMware ESXi host, for example.
>
> "NOt possible" meaning that the writers have not included this
> possibility I assume you mean, not that it is impossible.

It is not possible to run programs on the bare hardware.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[John Hasler]

Jochen Bern writes:
> If those two restrictions were to be removed (assume a giant tooth
> fairy if you must ;-), I don't see a reason why the current UT1-UTC
> delta could not be communicated through an "NTP-ng" in the same way
> today's NTP shoves server-client deltas around and corrects for them -
> piecemeal with every poll.

And have UTC jump around as erratically as does the Earth's rotation?
Why?  Might as well set up a tranit and set your clock by the sun.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] NTP Servers in virtual machines

[Dave Holland]

Rob   wrote:
>William Unruh  wrote:
>> You canrun ntp on the machine that runs the virtual hardware, and tell
>> the virutal machines to get their time from the real system.
>
>This is not possible on "real" virtual machine systems.
>You can do it on your Linux box at home where you virtualize some systems
>for testing, but not on a VMware ESXi host, for example.

VMware's documentation disagrees:

http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vmtools.install.doc%2FGUID-C0D8326A-B6E7-4E61-8470-6C173FDDF656.html

Cheers,
Dave

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

Re: [ntp:questions] NTP Servers in virtual machines

[William Unruh]

On 2014-06-24, Rob  wrote:
> William Unruh  wrote:
>> On 2014-06-24, Rob  wrote:
>>> William Unruh  wrote:
 You canrun ntp on the machine that runs the virtual hardware, and tell
 the virutal machines to get their time from the real system.
>>>
>>> This is not possible on "real" virtual machine systems.
>>>
>>> You can do it on your Linux box at home where you virtualize some systems
>>> for testing, but not on a VMware ESXi host, for example.
>>
>> "NOt possible" meaning that the writers have not included this
>> possibility I assume you mean, not that it is impossible.
>
> It is not possible to run programs on the bare hardware.

Since the whole VM is a set of programs running on the bare hardware,
this is clearly wrong. 
Anyway, the people running the bre hardware should be running ntpd or
chrony or whatever to discipline the background clock. They should also
have some ioctls which allow the reading of that background clock, and
time requests onthe VMshould be coming from there. 
Now, should and do are different words, and it is entirely possible that
the writers of the VM sogtware were incompetent. 

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Jochen Bern]

On -10.01.-28163 20:59, Miroslav Lichvar wrote:
> As someone who implemented support for leap seconds in several
> applications, I'd really like to see them gone. Fixing all software
> where time is critical to handle them correctly may not be possible

So your POV is that of someone managing computers who sees the attempts
to sync a technical notion of time to the movement of the planet
somewhere under your feet as breaking features like monotonicity and
continuity of the computers' genuine clocks.

While I may have started from the same setting, I *did* try to put
myself into the shoes of astronomers and people operating satellite
systems (which, ironically, includes the popular stratum 0 of GPS).
There's not much you can do about the fact that users tend to be mostly
friction locked to the surface of the planet while satellites and
celestial bodies are not, short of outright denial and perpetual
puzzlement why your models refuse to work properly.

Personally, I'd say that if a computer's clock's best suited to run on
TAI (or equivalent) and all data needs to be converted from it to $TZ
for the users, anyway, then having it run on TAI and disseminating and
handling a TAI-UTC delta along with the sync and timezone deltas seems
like the proper approach. But that wish doesn't change gettimeofday()
implementations all over the globe with a snap of my fingers, does it.

> Making smaller but more frequent corrections would probably only make
> it worse.

That depends on your definition of "worse". "Results in lower max
offsets" (that mechanisms like NTP will silently take care of) seems to
be a quite popular definition of "better", FWIW.

> To me, it seems the reasonable thing to do would be to decouple UTC and
> UT1 completely and make the adjustment at a higher level like
> timezones if necessary. Countries adjust their timezones all the time,
> we can handle that better.

I've seen enough platforms allowed access to a (local) NTP server but
not updates, enough such platforms being considered secure(d into a
world of their own) enough not to be updated, enough devices whose
owners never thought of firmware updates to even *exist*, yadda yadda to
assert that the "better" mechanism of making that data part of regular
but fundamentally *optional* OS updates (instead of a well-defined,
verifiably secure or at least harmless, dedicated on-demand
communication protocol) is downright *nonfunctional* often enough.

Too many people expect their devices to usually tell them "the" right
time (:= as per local timezone) with naught but an occasional "setting
it right" (:= manually inserting a single delta with no understanding of
the background mechanisms involved) to make "you should have updated
every now and then" an accepted excuse for those devices giving
themselves airs of being "computers" instead (caution, irony).

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Servers in virtual machines

[Paul]

On Tue, Jun 24, 2014 at 8:32 AM, Dave Holland  wrote:
> Rob   wrote:
>>This is not possible on "real" virtual machine systems.
> VMware's documentation disagrees:

You've inverted the conceit*.

If you *define* a "real" virtual machine hypervisor as one that
doesn't run any applications then you're done.  Of course this ignores
the correctness of the discipline process.  Is an analysis of the
output of a disciplined virtual clock indistinguishable from an
analysis of a well-mannered non-virtual clock?  From a practical point
of view is a disciplined virtual clock good enough to contribute?


*Rob is referring to a hypervison like ESXi, the page you reference is
about the guest OS.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Servers in virtual machines

[Paul]

On Tue, Jun 24, 2014 at 9:34 AM, William Unruh  wrote:
> On 2014-06-24, Rob  wrote:
>> It is not possible to run programs on the bare hardware.
>
> Since the whole VM is a set of programs running on the bare hardware,
> this is clearly wrong

Yes but ... sometimes we don't type what we mean to type.

To speak to something I'm more familiar with:  The objects formerly
known as Solaris Logical Domains (LDoms) are set up by the system
monitor (Openboot).  That in-ROM supervisor cannot run NTP.  The
so-called primary LDom can run NTP and in fact controls the (only)
hardware clock for all other LDoms.  Similarly I believe the ESXi
hypervisor microkernel is closer to GRUB than an OS.  But I have no
direct experience -- hence hand-waving.

Rob has defined things so they match his world view.  While not
actually wrong I think this could be misleading.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Miroslav Lichvar]

On Tue, Jun 24, 2014 at 03:46:15PM +0200, Jochen Bern wrote:
> While I may have started from the same setting, I *did* try to put
> myself into the shoes of astronomers and people operating satellite
> systems (which, ironically, includes the popular stratum 0 of GPS).

Do these people work just with UTC? I'd think it's not accurate enough
for their purposes and they need to include the current UTC-UT1
offset anyway.

> Personally, I'd say that if a computer's clock's best suited to run on
> TAI (or equivalent) and all data needs to be converted from it to $TZ
> for the users, anyway, then having it run on TAI and disseminating and
> handling a TAI-UTC delta along with the sync and timezone deltas seems
> like the proper approach. But that wish doesn't change gettimeofday()
> implementations all over the globe with a snap of my fingers, does it.

Agreed, but wouldn't switching to TAI everywhere be much more
difficult than stopping messing with UTC and keep it a fixed offset
from TAI?

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

Re: [ntp:questions] NTP Servers in virtual machines

[Rob]

Paul  wrote:
> On Tue, Jun 24, 2014 at 9:34 AM, William Unruh  wrote:
>> On 2014-06-24, Rob  wrote:
>>> It is not possible to run programs on the bare hardware.
>>
>> Since the whole VM is a set of programs running on the bare hardware,
>> this is clearly wrong
>
> Yes but ... sometimes we don't type what we mean to type.
>
> To speak to something I'm more familiar with:  The objects formerly
> known as Solaris Logical Domains (LDoms) are set up by the system
> monitor (Openboot).  That in-ROM supervisor cannot run NTP.  The
> so-called primary LDom can run NTP and in fact controls the (only)
> hardware clock for all other LDoms.  Similarly I believe the ESXi
> hypervisor microkernel is closer to GRUB than an OS.  But I have no
> direct experience -- hence hand-waving.

In ESXi there appears to be a simple Linux-like environment where
you can run things like ntpd, but this is in fact a virtual machine
just like all the others.  The ntpd that is running there is subject
to the same scheduling and virutalization issues as a user VM.
So that is different from the situation where you run a full-fledged OS
on the hardware and then run VMs under that (like when installing VMware
on Linux).

That said, it works quite well in VMware, better than some people here
are claiming.   A VM running Linux under VMware ESXi has timekeeping
at least an order of magnitude better than a Windows machine on bare
hardware, maybe even two orders.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Rob]

Jochen Bern  wrote:
> While I may have started from the same setting, I *did* try to put
> myself into the shoes of astronomers and people operating satellite
> systems (which, ironically, includes the popular stratum 0 of GPS).

Note that while those people would like to keep UTC in sync with sun
time, they already have to live with the fact that it isn't.
Or do you think that the insertion of a leap second now and then
gives them sufficient accuracy at any moment?
They already have to work with the difference between UTC and sun time
and that it steps by a second every few years.  When this stepping
would end and the difference would accumulate, that would not make
the situation more difficult for them than it already is.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Jochen Bern]

On -10.01.-28163 20:59, John Hasler wrote:
> Jochen Bern writes:
>> If those two restrictions were to be removed (assume a giant tooth
>> fairy if you must ;-), I don't see a reason why the current UT1-UTC
>> delta could not be communicated through an "NTP-ng" in the same way
>> today's NTP shoves server-client deltas around and corrects for them -
>> piecemeal with every poll.
> 
> And have UTC jump around as erratically as does the Earth's rotation?
> Why?  Might as well set up a tranit and set your clock by the sun.

The premise of this statement was to describe a scenario where the
UT1-UTC offset as "known" by random devices would be updated as often as
imaginable. Whether your local clock should then attempt to approximate
UTC, some variant of UTC with different (upstream) leap [whatever]
decisions, actual infinitesimal (and locally-known-only) leaps a.k.a.
UT1, or a "leapful" time based on that latter and rules how to quantize
the drift into a (again locally-known-only) "sufficiently small" leap,
is a *somewhat* separate question.

I don't know of any telecopes, satellite dishes, ... with an aperture /
beam so narrow as to being forced to have the tracking mechanism based
on UT1 instead of UTC, but that doesn't mean that there *are no* cases
where you need a better realtime approximation of UT1 (preferably
*without* setting up your own transit observation gear), and possibly
*still* having UTC as well (say, for logging).

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Jochen Bern]

On -10.01.-28163 20:59, Miroslav Lichvar wrote:
> On Tue, Jun 24, 2014 at 03:46:15PM +0200, Jochen Bern wrote:
>> While I may have started from the same setting, I *did* try to put
>> myself into the shoes of astronomers and people operating satellite
>> systems (which, ironically, includes the popular stratum 0 of GPS).
> 
> Do these people work just with UTC? I'd think it's not accurate enough
> for their purposes and they need to include the current UTC-UT1
> offset anyway.

I'm pretty sure that you cannot operate a system like GPS without having
a better idea of UT1 than UTC, even if (IIRC) the satellites' downlinks
do not disseminate that data to the terminal units. No idea whether
looking at the USNO data once a week or day does suffice. All I can say
is that transit measurements are, by definition, not available as often
as one might like.

I don't think that anyone dealing with communication satellites (i.e.,
in orbit around Earth) or a telescope smaller than a house needs to
bother with UT1-UTC beyond the max offset guarantees currently in
effect, though.

>> Personally, I'd say that if a computer's clock's best suited to run on
>> TAI (or equivalent) and all data needs to be converted from it to $TZ
>> for the users, anyway, then having it run on TAI and disseminating and
>> handling a TAI-UTC delta along with the sync and timezone deltas seems
>> like the proper approach. But that wish doesn't change gettimeofday()
>> implementations all over the globe with a snap of my fingers, does it.
> 
> Agreed, but wouldn't switching to TAI everywhere be much more
> difficult than stopping messing with UTC and keep it a fixed offset
> from TAI?

Having computer clocks run on UTC(frozen) instead of TAI makes the
adaptation easier today, more difficult tomorrow ("do we *really* need
to work on that for (n<3) seconds of an offset!?"), and no less
necessary in the long run (when UT1-TAI has grown much larger than
UT1-UTC(frozen), and changes much faster as well). I prefer to have the
slope right where the ball needs to get rolling. ;-)

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[John Hasler]

Miroslav writes:
> Do these people work just with UTC? I'd think it's not accurate enough
> for their purposes and they need to include the current UTC-UT1 offset
> anyway.

I believe that astronomers use Terrestrial Time, which is defined in
terms of TAI.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[John Hasler]

Jochen Bern writes:
> I don't know of any telecopes, satellite dishes, ... with an aperture
> / beam so narrow as to being forced to have the tracking mechanism
> based on UT1 instead of UTC, but that doesn't mean that there *are no*
> cases where you need a better realtime approximation of UT1
> (preferably *without* setting up your own transit observation gear),
> and possibly *still* having UTC as well (say, for logging).

Astronomers use TT for logging.  I believe that they see such things as
variations in the Earth's rotation as systematic errors to be corrected
and have a system for distributing the relevant data.  They certainly
need detailed knowledge of the motion of the Earth but I don't think
that they consider it the definition of correct time.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Rob]

Jochen Bern  wrote:
> While I may have started from the same setting, I *did* try to put
> myself into the shoes of astronomers and people operating satellite
> systems (which, ironically, includes the popular stratum 0 of GPS).

Note that the GPS system does not use UTC.

GPS has its own clock and broadcasts the current offset of UTC relative
to that clock.  This offset changes every time the silly leap second
thingy is done.  The GPS clock keeps ticking as before.

Maybe computers should just use GPS time.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[John Hasler]

Jochen Bern writes:
> Having computer clocks run on UTC(frozen) instead of TAI makes the
> adaptation easier today, more difficult tomorrow

How?  You just start distributing the leap second corrections in the
zone files.  Much simpler and no more need for flag days.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Jochen Bern]

On -10.01.-28163 20:59, John Hasler wrote:
> Jochen Bern writes:
>> Having computer clocks run on UTC(frozen) instead of TAI makes the
>> adaptation easier today, more difficult tomorrow
> 
> How?

In exactly the way I alluded to on the remainder of the line you quoted.

> You just start distributing the leap second corrections in the
> zone files.  Much simpler and no more need for flag days.

No, if you start with the current UTC (delta between UTC(frozen) and
UTC(leaps-as-before) = 0), you're telling the world that they can just
as well do that job (*) tomorrow. And tomorrow you'll ask them to do the
work for a delta that most people wouldn't even *notice* their clocks
having (as it is within wristwatch-and-eyeball precision). Etcetera.
Having a delta of 35s right from square one not only avoids introducing
*yet another* fancy name for a never-changing TAI offset, but also
speaks "fix this, now!" loud and clear.

(*) Where "that job" is not only to provide the corresponding updates,
but also having people the world over *install them*, at the cost of
buying new hardware if the old one is EOLed already.

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[David Woolley]

On 24/06/14 17:25, Jochen Bern wrote:

I'm pretty sure that you cannot operate a system like GPS without having
a better idea of UT1 than UTC, even if (IIRC) the satellites' downlinks
do not disseminate that data to the terminal units. No idea whether


I assume the DUT1 information is implicit in the ephemeris data.

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

Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is

[Mike S]

On 6/24/2014 5:59 AM, Miroslav Lichvar wrote:

To me, it seems the reasonable thing to do would be to decouple UTC and
UT1 completely and make the adjustment at a higher level like
timezones if necessary.


You're doing it wrong. If you don't want leap seconds, use a timescale 
which doesn't have them (e.g. TAI, GPS). UTC was created to closely 
track Sol. Decoupling that breaks its purpose, and the promise made when 
it took over from GMT.

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