From seaman at noao.edu  Fri Jun 13 17:04:45 2008
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 13 Jun 2008 14:04:45 -0700
Subject: [LEAPSECS] events?  (was Fwd: TICTOC questionnaire)
References: <F8A877DCF6D56E4685A323771D106974F34473@naeamillez01.nadsusea.nads.navy.mil>
Message-ID: <74D83C5E-B28E-4E7B-B1F9-D5BEF63D9E80@noao.edu>

Hi,

This questionnaire has been going around in support of the TICTOC  
effort.  I was taken by the very first question regarding the new  
protocol:

> PROTCOL DETAILS (those who do not feel we should develop a new  
> protocol may skip)
> *  What needs to be present in timing distribution packets ?
>   Only timestamp(s) ?
>   Internal algorithm parameters to improve accuracy ?
>   Events (leap seconds, etc)

First, one has to ponder whether any time distribution protocol  
actually transports timestamps, per se.  Rather a local clock is  
synchronized to remote clock(s), but the timestamps originate from the  
local clock.

But it struck me that we have often used language, as here, that  
treats a leap second as a physical "event".  This is not correct.   
(And I say this as chair of an international working group to describe  
astrophysical events, see http://voevent.org.)

An event implies a measurable quantity - a simple or complex data  
structure representing one or more empirically determined parameters.   
That is, the report of an event conveys dependent variable(s)  
expressed on a grid of independent variable(s), typically time.

As we have discussed long since, however, a leap second is purely a  
representational artifact superimposed on an underlying monotonic  
timescale.  Nothing "happens" at a leap second - at least, nothing  
that isn't introduced (rightly or wrongly) by our systems themselves.

Intercalary scheduling may provoke state transitions in our systems.   
These state transitions may employ some event driven design paradigm.   
But these are choices made by an architect, not requirements implicit  
in the system.

Rob Seaman
National Optical Astronomy Observatory
--

Begin forwarded message:

> From: "Odonoghue, Karen F CIV NSWCDD, W13" <karen.odonoghue at navy.mil>
> Date: June 13, 2008 8:56:19 AM GMT-07:00
> To: <ntpwg at lists.ntp.org>
> Subject: [ntpwg] FW: [TICTOC] TICTOC questionnaire
>
> Folks,
>
> As you are no doubt aware, there is a newly chartered working group  
> in the
> IETF in the area of time (tictoc). This questionaire is in  
> preparation for
> an interim meeting next week. If you are interested in these types  
> of questions,
> you should probably pay attention to that mailing list.
>
> Regards,
> Karen
>
> -----Original Message-----
> From: tictoc-bounces at ietf.org [mailto:tictoc-bounces at ietf.org] On  
> Behalf
> Of Stewart Bryant
> Sent: Monday, June 09, 2008 5:15
> To: tictoc at ietf.org
> Subject: [TICTOC] TICTOC questionnaire
>
> TICTOC Working Group
>
> The primary goal of the TICTOC meeting next week will be to generate  
> the
> TICTOC protocol requirements.
> We know that applications requirements drive protocol requirements,  
> and
> we will be looking for application based evidence to back up the
> protocol requirements, but we will not be using the application  
> network
> system tutorial approach that we have seen at the last three TICTOC
> meeings. We need to walk away from this meeting with the  
> fundamentals of
> the protocol agreed in principle.
>
> With that in mind we have compiled a set of questions that we think
> drive the protocol requirements. We request that you fill in as much  
> of
> the questionnaire  as  you are able before the start of the UK day on
> Friday 13th June, and we will summarize the responses ready for the
> meeting. That way we can start the meeting with some common
> understanding of what we agree on and what we need to resolve.
>
> Regards
>
> Yaakov and Stewart
>
>
> GENERAL
>
> * Name
>
> * Are you going to attend the upcoming interim meeting
>   A) in person
>   B) via dial-in
>
> * Relevant applications that interest you -
>
>   cellular backhauling
>
>   instrumentation / measurement
>
>   industrial
>
>   networking (e.g. instrumenting the net, or making
>   it work better/different)
>
>   time of day over the general purpose Internet
>
>   legal time
>
>   other
>
> * Which of the following best describes what you feel
>   TICTOC should do ?
>
>     1) define minor extensions to NTPv4
>     2) define 1588 profiles
>     3) define a new TLV-based protocol
>     4) define a new protocol with backwards compatibility
>        to NTP
>
> * What type of time do we need to distribute (multiple
>  answers are possible) ?
>
>  UTC?  Local time ?   TAI ?  arbitrary phase ?  others ?
>
>  What is the best format ?
>
>  Please address how other needed types of time are to be
>  derived (e.g. local time from UTC, leap-seconds, etc)
>
>
> * Should a separate "frequency-only" service be defined ?
>
>   What about a special "time when frequency is locked"
>   service ?
>
> * Should we divide the application space into categories
>   from stringent to undemanding ?
>
>  If so, how may categories and where are the dividing lines ?
>  Please consider
>      accuracy
>      resolution
>      aquisition time
>      Jitter
>      Wander
>
>  Are there other characteristics that would cause us to
>  consider the creation of an unique timing class?
>
> * It is proposed to separate protocols (standards-track)
>  from algorithms (informational). Do you agree ?
>
> * It is proposed that TICTOC exploit on-path support when
>   available, but be able to function (with reduced
>   performance) when it is not. Do you agree ?
>
> * It is proposed that TICTOC exploit special hardware in
>  server and clients, but be able to function (with
>  reduced performance) when it is not.  Do you agree ?
>
> * What scalability constraints do you envisage ?
>
>   Number of clients per server -
>   Number of servers on network -
>   Number of hops / maximum propagation time -
>
>
> * Is it acceptable for the time server to save state
>   of clients ?
>
>   How much memory and for how long ?
>
> * Which modes are required ?
>
>   broadcast
>   multicast
>   unicast
>   anycast
>
>
> * We need to support transport over (multiple answers
>   are possible) -
>
>   TCP/IP
>   UDP/IP
>   RTP/UDP/IP
>   DCCP/IP
>   Ethernet
>   MPLS
>   other
>   multiple domains with multiple protocols
>
>
> * How should client time be updated by TICTOC ?
>
>   by setting time to best estimate
>   by setting time but maintaining monotonicity
>   by slewing frequency
>
> * How are multiple sources of clock to be handled ?
>
>  Best clock selected by rating in packet
>  Best clock determined by calculation
>  combination of information from multiple clocks
>  completely distributed method
>
>
> PROTCOL DETAILS (those who do not feel we should develop a new  
> protocol
> may skip)
>
>
> *  What needs to be present in timing distribution packets ?
>
>   Only timestamp(s) ?
>
>   Internal algorithm parameters to improve accuracy ?
>
>   Events (leap seconds, etc)
>
>
> * It is proposed that time resolution of TICTOC
>   protocols be 1 picosecond.
>
>   Do you agree ?  If not - what resolution do you propose ?
>
>
> * It is proposed that the time be divided into two parts,
>   with 1 second being the dividing line.
>
>  The higher part is to be treated as data to be transported.
>
>  The dividing line is constrained by the ambiguity introduced by
> network propagation times.
>
>  Do you agree to the division ?  Do you agree to the
>  dividing line ?
>
>  What format should the fine granularity part be
>  (1/10, 1/2, other), and why?
>
>
> * What are the maximum and minimum update rates needed
>   to be supported ?
>
> * Is a profiling mechanism required ?
>
> * Are "follow-up" messages required ?
>
>
>
> NETWORKING ISSUES
>
> *  How should potential clients determine where to find
>    a time server ?
>
>    DNS ? DHCP ? new protocol ?
>
>
> *  How are on-path support elements discovered ?
>
>    How is an optimal path that exploits these elements
>    to be determined ?
>
> *  Should we distinguish between time delivered within an
>    AS and time delivered outside it?
>
>
>
> SECURITY
>
> * Which of the following authentication mechanisms is required ?
>
>   of server by client
>   of client by server
>   of middleboxes
>
> * What time source traceability is needed?
>
>
> * Is encryption of timing packets needed ?
>
> END
>
>
>
>
> _______________________________________________
> TICTOC mailing list
> TICTOC at ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20080613/08a995b5/attachment.html>

From ch at murgatroid.com  Fri Jun 13 20:50:39 2008
From: ch at murgatroid.com (christopher hoover)
Date: Fri, 13 Jun 2008 17:50:39 -0700
Subject: [LEAPSECS] events?  (was Fwd: TICTOC questionnaire)
In-Reply-To: <74D83C5E-B28E-4E7B-B1F9-D5BEF63D9E80@noao.edu>
References: <F8A877DCF6D56E4685A323771D106974F34473@naeamillez01.nadsusea.nads.navy.mil>
	<74D83C5E-B28E-4E7B-B1F9-D5BEF63D9E80@noao.edu>
Message-ID: <00ab01c8cdb8$aa89c010$ff9d4030$@com>

 

 

An event implies a measurable quantity - a simple or complex data structure
representing one or more empirically determined parameters.  That is, the
report of an event conveys dependent variable(s) expressed on a grid of
independent variable(s), typically time.

 

I'm not defending the wording, but surely they are using the term "event" as
it is sometimes used in computer science, i.e., notification of something of
interest that could be acted upon.  This may be sloppy usage, but it is
commonplace.

 

-ch

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20080613/ca778245/attachment.html>

From seaman at noao.edu  Thu Jun 19 14:48:34 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 19 Jun 2008 11:48:34 -0700
Subject: [LEAPSECS] [ntpwg] Further to the timestamping issue
In-Reply-To: <20080619181128.GA4383@ucolick.org>
References: <6182EADD-BEE1-492F-8247-BD31935D9C23@noao.edu>
	<5CD5936A-CDD2-4A17-ACFE-8149C2DC0BE8@noao.edu>
	<008e01c8d236$2b455490$0200a8c0@tsg1>
	<4FE9B021-10E7-476F-9462-F866DD71ED78@noao.edu>
	<20080619181128.GA4383@ucolick.org>
Message-ID: <CCA66A30-7FE8-4BCF-97C7-AD27AF33F81D@noao.edu>

> This discussion should go to LEAPSECS and leave NTPWG.

I'm copying it over there.  Please remove ntpwg from further replies.

> POSIX specs for zoneinfo already require enough complexity to handle  
> the leap seconds, and the mechanisms for updating the zoneinfo files  
> are well tested.  All that's needed is to rename the time scale used  
> in broadcasts, NTP, and POSIX time_t.

Just to be clear, the realization of UTC would then occur locally via  
zoneinfo mediated leap seconds.  This is quite different from the  
notion of letting the timezones slosh around.

> All of the missing bits would be much easier to solve by putting  
> leap seconds in zoneinfo than by messing with NTP.

If we could escape from the artificial crisis generated from the  
relentless ITU shenanigans, we would have time to focus on  
characterizing the problem before suggesting solutions.

Rob


From seaman at noao.edu  Thu Jun 19 19:17:35 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 19 Jun 2008 16:17:35 -0700
Subject: [LEAPSECS] [ntpwg] Further to the timestamping issue
In-Reply-To: <DB373248-9FCF-4F40-B50B-6EE5957279EB@multicasttech.com>
References: <18990.1213618608@critter.freebsd.dk><485679D6.3010407@udel.edu>	<6182EADD-BEE1-492F-8247-BD31935D9C23@noao.edu>	DEFANGED[780]:DEFANGED[82670]:<85B1F3DC-65D8-4F13-B6BE-44F1A469FCA9@noao.edu><CB2FE9A5-C507-46B2-8A62-F2E4CA75FB3C@noao.edu><4857221B.7080003@udel.edu><ACAE74E1-335B-40F7-B9D7-BC2E80DA929E@noao.edu><002401c8d21
	" " f$479cd9e0$0200a " "
	8c0@tsg1>	<5CD5936A-CDD2-4A17-ACFE-8149C2DC0BE8@noao.edu>	<008e01c8d236$2b455490$0200a8c0@tsg1>
	<4FE9B021-10E7-476F-9462-F866DD71ED78@noao.edu>
	<485AA717.9070301@udel.edu>
	<DB373248-9FCF-4F40-B50B-6EE5957279EB@multicasttech.com>
Message-ID: <5D8129C9-57CE-4EAB-810D-51AFE39C218A@noao.edu>

Replies to leapsecs.

On Jun 19, 2008, at 1:33 PM, Marshall Eubanks wrote:

> Leapseconds are driven by torques at the core mantle boundary, which  
> we cannot see directly
> and basically have information about only through UT1 and LOD  
> measurements. In practice, leap seconds cannot be predicted much  
> more than 6 months to a year in advance because of that.

Modeling of Earth rotation has become exquisitely good.  (Don't  
neglect information from seismology.)  Discussions on LEAPSECS suggest  
that useful predictions are possible several years in advance.  The  
horizon can be lengthened further by loosening the amplitude of DUT1 a  
skosh.  A consensus appears likely around a set of parameters allowing  
for about a decade lookahead.

Note that the related science of helioseismology has progressed to the  
point that sunspots can be "seen" on the far side of the Sun.  Hidden  
engines are studied quite productively throughout the sciences.

> AND, keep in mind that in the "jerk" seen around 1905 would have  
> meant several _negative_ leap seconds in one year, which would I am  
> sure be a fun experience if repeated today.

We don't have leap seconds due to current variations, but due to  
integrating the already accumulated LOD offset of a few milliseconds.   
As the tidal offset grows quadratically, it has become virtually  
impossible for a negative leap second to occur, since such a jerk as  
you describe would have to persist long enough to overcome the  
accumulated temporal moment arm.  The effective LOD zero point is in  
the nineteenth century, not the 1970's.

Rob Seaman
NOAO


From sla at ucolick.org  Tue Jun 24 11:25:22 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 24 Jun 2008 08:25:22 -0700
Subject: [LEAPSECS] precision timing in the news
Message-ID: <20080624152522.GA19671@ucolick.org>

Including mentions of NTP and leap seconds

http://www.gcn.com/print/27_15/46509-1.html

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m