[ntpwg] Further to the timestamping issue

[TSG]

Rob (in the best spirits - my response is below :-)

Todd

----- Original Message ----- 
From: "Rob Seaman" <seaman at noao.edu>
To: "NTP Working Group" <ntpwg at lists.ntp.org>
Sent: Thursday, June 19, 2008 7:38 AM
Subject: Re: [ntpwg] Further to the timestamping issue


> On Jun 19, 2008, at 8:04 AM, TSG wrote:
>
>>> My fundamental point is that UTC permits much more flexible leap
>>> second scheduling than has been demonstrated to date.  NTP might have
>>> to adapt to this in the future.
>>
>> Not if its used in proper auditing of IT operations. Leap Seconds
>> are a nightmare for logging systems because they require special
>> handling and integration across an entire entitie's operations.
>
> I don't discount auditing requirements, although it isn't clear that
> NTP's requirements are the same as your company's.

Ahahhah - NTPs requirement's are for a trusted system to deploy time-of-day 
calibration services to distributed computer's.

The question here is whether those are what NTP.ISC.ORG is up to or it has 
some other agenda...


> That the Earth
> orbits the Sun and has a large nearby Moon are a bit more fundamental
> than either.  We can disagree about the implications of all sorts of
> requirements.  Basing a discussion on requirements is generally more
> productive, however, than jumping directly into each other's nightmares.
>
> NTP already provides special handling and integration for the case of
> leap seconds.

Sort of...

> That being the case, it certainly would be appropriate
> to update the system should the underlying UTC leap second
> implementation ever change.

So then you are saying that it is more important to add a new security risk 
that to live within how it operates now? Yeah right... :-)

> This is not imminent,

My point exactly.

>but seems
> ultimately more likely than the current fad for advocating the
> elimination of leap seconds in a fruitless attempt to abandon mean
> solar time.

Unfortunately it doesn't talk about the precision or performance of NTP in a 
loaded system. Or what the interrupt processesing latency or overhead would 
be in the bigger picture. So we have no idea how a NTP Server is supposed to 
respond, whether it can sit there and cache all the requests to serve them 
all at once or otherwise. Or whether it can be paged into la-la land while 
other higher priority processes use those same compute resources which NTP 
needs to keep its TOD accurate.

>
> In any event, NTP either supports UTC or it doesn't.

Ah yes - but it really doesnt support UTC anyway. Currently NTP supports a 
"TAI+" type scale with some external clock source - otherwise the timescale 
NTP supports in that of its own  ("TAI+" means Last UTC Setting + TAI Ticks 
since then). The real question is whether NTP should autocorrect and add 
leap-seconds  automatically or not and the answer is NO WAY.

Leap Second's are a nightmare for correlating actual TOD through. The 
mapping of that to UTC happens once a month when the BIPM does the 
Circular-T thingee and proclaims UTC to be what it is for that month.

Besides since its computed after the fact, UTC is not a time-scale that 
ANYONE can keep a beating clock to. They can keep it to TAI + Last(UTC 
Fixing) and that is it. Poof - end of statement.

> This is also a
> requirement, whatever complications that causes elsewhere.  Required
> complexity is another name for "design".

The problem is that NTP(SW) [NTP's Software Only Timescale] is not a 
reliable time scale nor can it be relied on in an evidentiary standard for 
anything IMHO since you cannot specifiy what else that compuer was doing at 
the time it was supposed to be answering the NTP Query.

>
> In short, UTC *already* permits multiple leap seconds to be announced
> in advance.

Do you have any idea of the cost of implementing a log management practice 
that will address multiple Leap Second's being added???

Considering also that Leap Second's are never added such that there would be 
more than one per month added, the accidental adding of a leap second 
(assuming NTP automatically tracks them) could cause billions or trillions 
of dollars of damage and skewing to our commerce systems that support their 
automatic induction.

> with an arbitrarily longer horizon than six months.  NTP
> systems *already* fail to implement the full complexity implicit in UTC.

And for good reasons too.

>
> Rob Seaman
> NOAO
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg