Hello,

if one of the leap indicator bits is set in the time server's sntp
response, how do I handle this leap condition correctly?

I assume, if it is set, then it is set for the whole day?

As I am new here, is there a faq on sntp?

Thank you,
 Friedel
=20

An SNTP server should not ordinarily be telling ANYBODY what time it is.

H

In article <ywn9psutvr5k.fsf@ntp1.isc.org>,
Harlan Stenn <stenn@ntp1.isc.org> wrote:

> An SNTP server should not ordinarily be telling ANYBODY what time it is.

An SNTP server that isn't telling someone the time is a total waste of
resources.  Telling clients the time is the only reason for an SNTP
server to exist!

Are you possibly trying to say that an SNTP client should not also act
as a server?  Whilst true, this is only a SHOULD NOT, not a MUST NOT,
and Windows violates this rule anyway, which means it has become 
unenforceable (ignoring that Windows has more serious protocol violations).
(SHOULD NOTs are things that shouldn't normally be done but are permitted
in exceptional circumstances.)

In any case, the original article seems to have meant the server response
to an SNTP client request, not really that the server had to be an SNTP
server. Even if it were an SNTP server, there is nothing to indicate
that it isn't directly connected to a proper reference clock.

I would say that the answer was that an SNTP client isn't normally expected
to maintain the clock that well that it can't just ignore the leap warning
(it shouldn't ignore the alarm state) and just respond to the step in time
when it occurs.  However, if it did want to honour it, it would refrain 
from asking the time in the immediate vicinity of the two times a year
that leap seconds may be implemented, and should adjust its internal idea
of UTC time (which may or may not be able to represent second 59 minutes
and 60 seconds) at the nominal time at which leap seconds are allowed, and
in the direction indicated.  If it cannot represent 60 seconds, it may have
to compromise this to maintain monotonicity, if that is important.

The reason I suggest not asking the time, is that and SNTP implementation is
unlikely to have good filtering of outlyers, so may undo its automatic
adjustment when it gets a response that indicates that the time hasn't quite
passed, and then re-apply on the next sample.

>> An SNTP server should not ordinarily be telling ANYBODY what time it is.

> An SNTP server that isn't telling someone the time is a total waste of
> resources.  Telling clients the time is the only reason for an SNTP
> server to exist!

I pretty much agree with you.  In most cases, there is no reason to run
SNTP as a server, and doing so is a waste of resources.

Telling clients the time is the job of an NTP-based server, not an
SNTP-based server.  Usually.

> Are you possibly trying to say that an SNTP client should not also act
> as a server?

Yes.

> Whilst true, this is only a SHOULD NOT, not a MUST NOT,
> and Windows violates this rule anyway, which means it has become 
> unenforceable (ignoring that Windows has more serious protocol
> violations).

And there are more cockroaches on the planet than people, but that does not
make them a higher life form.

> In any case, the original article seems to have meant the server response
> to an SNTP client request, not really that the server had to be an SNTP
> server.

The operative word there is "seems".

> Even if it were an SNTP server, there is nothing to indicate
> that it isn't directly connected to a proper reference clock.

Yes, and there is nothing to indicate that if it is an SNTP-based server
that it *is* connected to a proper refclock, either, or that the time from
the refclock is "sane".

We basically need more information, including knowing exactly what is
expected as far as accurate timekeeping is concerned.

H

Thank you for your reply.
 Friedel

Harlan,

An SNTP server connected to a reference clock is entirely within spec. 
There are dozens of NTP products integrated with a GPS receiver. I think 
what you mean is that a SNTP server not connected to a reference clock 
is out of spec and that's a correct statement.

Dave

Harlan Stenn wrote:

> An SNTP server should not ordinarily be telling ANYBODY what time it is.
> 
> H

David,

SNTP implementations are not required to discipline the clock frequency 
and can in principle step the clock, have huge sawtooth errors and 
believe falsetickers. If the implementation operates with a reference 
clock, it is expected to be well behaved. If it operates with one or 
more upstream servers, it could misbehave and create downstream chaos.

For instance, a SNTP server with 100 PPM frequency error and updating 
once per day would have a sawtooth error of over eight seconds. A 
downstream NTP client would not work at all. A downstream SNTP client 
might not care very much, but then I wouldn't consider those clocks 
synchronized.

Dave

David Woolley wrote:

> In article <ywn9psutvr5k.fsf@ntp1.isc.org>,
> Harlan Stenn <stenn@ntp1.isc.org> wrote:
> 
> 
>>An SNTP server should not ordinarily be telling ANYBODY what time it is.
> 
> 
> An SNTP server that isn't telling someone the time is a total waste of
> resources.  Telling clients the time is the only reason for an SNTP
> server to exist!
> 
> Are you possibly trying to say that an SNTP client should not also act
> as a server?  Whilst true, this is only a SHOULD NOT, not a MUST NOT,
> and Windows violates this rule anyway, which means it has become 
> unenforceable (ignoring that Windows has more serious protocol violations).
> (SHOULD NOTs are things that shouldn't normally be done but are permitted
> in exceptional circumstances.)
> 
> In any case, the original article seems to have meant the server response
> to an SNTP client request, not really that the server had to be an SNTP
> server. Even if it were an SNTP server, there is nothing to indicate
> that it isn't directly connected to a proper reference clock.
> 
> I would say that the answer was that an SNTP client isn't normally expected
> to maintain the clock that well that it can't just ignore the leap warning
> (it shouldn't ignore the alarm state) and just respond to the step in time
> when it occurs.  However, if it did want to honour it, it would refrain 
> from asking the time in the immediate vicinity of the two times a year
> that leap seconds may be implemented, and should adjust its internal idea
> of UTC time (which may or may not be able to represent second 59 minutes
> and 60 seconds) at the nominal time at which leap seconds are allowed, and
> in the direction indicated.  If it cannot represent 60 seconds, it may have
> to compromise this to maintain monotonicity, if that is important.
> 
> The reason I suggest not asking the time, is that and SNTP implementation is
> unlikely to have good filtering of outlyers, so may undo its automatic
> adjustment when it gets a response that indicates that the time hasn't quite
> passed, and then re-apply on the next sample.

Lemme try part of this again.

> Are you possibly trying to say that an SNTP client should not also act
> as a server?

Yes, and I will change that to MUST NOT.

> Whilst true, this is only a SHOULD NOT, not a MUST NOT,
> and Windows violates this rule anyway, which means it has become 
> unenforceable (ignoring that Windows has more serious protocol
> violations).

By my read of the spec, SNTP is allowed 2 modes of operation:

- at the "leaf" level with no direct refclock connection
- at stratum 1 with a direct refclock connection

sntp is incredibly lightweight and will believe the first answer it
receives.

The spec also says that one "side" cannot (is unable to) determine if
the other side is SNTP or NTP.

Therefore, if one has an sntp leaf node, I believe that leaf node should?
must? advertise itself at stratum 15.

I also believe that the SNTP (draft) RFCs need some work in this area, as
we are having this discussion.

H

Dave,

> An SNTP server connected to a reference clock is entirely within
> spec. There are dozens of NTP products integrated with a GPS receiver. I
> think what you mean is that a SNTP server not connected to a reference
> clock is out of spec and that's a correct statement.

Exactly what I meant. Thanks for the better explanation.

H

Harlan,

See page 10 of the draft RFC. It clearly states the stratum in the 
client packet should be set to zero, not fifteen. Reivew rfc1305 for the 
mapping between packet stratum and the internal value used in the NTP 
reference implementations.

I was very careful in stating the expectations for servers and clients. 
If you have trouble with the text, please honk.

Dave

Harlan Stenn wrote:

> Lemme try part of this again.
> 
> 
>>Are you possibly trying to say that an SNTP client should not also act
>>as a server?
> 
> 
> Yes, and I will change that to MUST NOT.
> 
> 
>>Whilst true, this is only a SHOULD NOT, not a MUST NOT,
>>and Windows violates this rule anyway, which means it has become 
>>unenforceable (ignoring that Windows has more serious protocol
>>violations).
> 
> 
> By my read of the spec, SNTP is allowed 2 modes of operation:
> 
> - at the "leaf" level with no direct refclock connection
> - at stratum 1 with a direct refclock connection
> 
> sntp is incredibly lightweight and will believe the first answer it
> receives.
> 
> The spec also says that one "side" cannot (is unable to) determine if
> the other side is SNTP or NTP.
> 
> Therefore, if one has an sntp leaf node, I believe that leaf node should?
> must? advertise itself at stratum 15.
> 
> I also believe that the SNTP (draft) RFCs need some work in this area, as
> we are having this discussion.
> 
> H

Dave,

Neat, I missed that in my previous reads (as did the open(s)ntp folks).

H

Dave,

I just re-read the draft 2030 spec and it says that the legal values for
stratum on a reply are 1-14.

0 is a KOD reply.  If an SNTP implementation is not sync'd to a refclock
I see no clear statement in the draft RCF that it should return a KOD reply.

I also do not understand why 15 is not listed as an allowed value in a
stratum response.  I would expect 15 to be returned from a sender at stratum
14.

Also, the draft SNTP RFC says:

 Stratum: This is a eight-bit unsigned integer indicating the stratum of the
 server or client, with values defined as follows:

   Stratum  Meaning
   ----------------------------------------------
   0        kiss-o'-death message (see below)
   1        primary reference (e.g., synchronized by radio clock)
   2-15     secondary reference (synchronized by NTP or SNTP)
   16-255   reserved

The following seems better to me:

   Stratum  Meaning
   ----------------------------------------------
   0        kiss-o'-death message (including SNTP client.  See below)
   1        primary reference (NTP or SNTP, synchronized, e.g., by radio clock)
   2-15     secondary reference (synchronized by NTP)
   16-255   reserved

I gather the IETF WG is the place to go over this stuff.

H

In article <ywn9d5qs9vil.fsf@ntp1.isc.org>,
Harlan Stenn <stenn@ntp.isc.org> wrote:

> I just re-read the draft 2030 spec and it says that the legal values for

RFC 2030 is released.  It can't be a draft.  Any replacement will have
a new RFC number.  It will either obsolete RFC 2030 or define a new version
of the protocol.  (For example, the NTP v4 RFC, when it arrives, will not
obsolete RFC 1305.)

> Also, the draft SNTP RFC says:

Except for KOD, this is the same as RFC 2030.

>    2-15     secondary reference (synchronized by NTP or SNTP)

Although RFC 2030 doesn't use the proper SHOULD NOT style language, it is
clear to me that the only reasonable interpretation of the following is
SHOULD NOT, so the above is valid; an RFC 2030 server MAY operate at
stratum's higher than one and MAY exist.

   It is strongly recommended that SNTP be used only at the extremities
   of the synchronization subnet. SNTP clients should operate only at
   the leaves (highest stratum) of the subnet and in configurations
   where no NTP or SNTP client is dependent on another SNTP client for
   synchronization. SNTP servers should operate only at the root
   (stratum 1) of the subnet and then only in configurations where no
   other source of synchronization other than a reliable radio or modem
   time service is available. The full degree of reliability ordinarily


(Note that Windows always claims stratum 2, when synchronised, so is 
broken in its use of this field.)

>   1        primary reference (NTP or SNTP, synchronized, e.g., by radio clock)

A stratum one server is, by definition, never synchronised using NTP or SNTP;
you are confusing the wire protocol with the server implementation (something
that the NTP/SNTP distinction does, to some extent, itself).  Defining by
example is not good enough for a precise specification.

You may be proposing a new RFC.  In that case, I doubt that you can change
a SHOULD NOT into a MUST NOT without creating a new version of the protocol,
as I very much doubt that IETF likes retrospective legislation.  To get
your desired effect in a new version of the protocol, you would need to 
have something like:

   1        primary reference (this value SHALL only be used by
            <definition that doesn't depend on the use of "e.g.">)
   2-15     secondary reference (these values SHALL only be used by
            a server fully implementing NTP (RFCxxxx))

I'd note, though, that some significant aspects of NTP V3 are only
specified as an appendix, and are therefore probably non-normative,
so compliance with the NTP RFC is not the same as equivalence with xntpd.

Note that the above doesn't properly cover the increasingly standard use
of an unsynchronised local clock as a reference.  In particular, it forces
it to be configured as stratum 0.  As to even allowing the use of such
references, this has to be an area where SHOULD NOT has to be used.  Using
MUST NOT will just result in lots of non-compliant implementations without
making much real difference to the number of people actually doing it.

A better approach to local clocks (and SNTP) would be to have extra
protocol fields that signal that the server is not in a strict NTP mode.
I'd suggest it be bit coded, with one bit for not synchronised to UTC,
and one for other factors (including local reference clock or not the full
NTP algorithms).  The last part might be better decomposed with separate
bits for SNTP, local reference clock, and other.  Such bits would be
set in any transmitted packet traceable to an input one with them set.

This feature would probably be commercially unacceptable, though, and
probably wouldn't be too widely implemented, as it would cause apparent
failures when the customer felt they were in the right, and when other
implementations didn't fail.  In a world of people who demand solutions
and not counselling, implementing such restrictions can be commercial
suicide.

This is especially true of SNTP.  Any attempt to change SHOULD NOT to
MUST NOT will be ignored, because SNTP is generally only used for reasons
of commercial expediency, and in such context, inconvenient rules will
always be ignored.

David Woolley wrote:

>In article <ywn9d5qs9vil.fsf@ntp1.isc.org>,
>Harlan Stenn <stenn@ntp.isc.org> wrote:
>
>  
>
>>I just re-read the draft 2030 spec and it says that the legal values for
>>    
>>
>
>RFC 2030 is released.  It can't be a draft.  Any replacement will have
>a new RFC number.  It will either obsolete RFC 2030 or define a new version
>of the protocol.  (For example, the NTP v4 RFC, when it arrives, will not
>obsolete RFC 1305.)
>
>  
>
> <snip>
>
>
>You may be proposing a new RFC.  In that case, I doubt that you can change
>a SHOULD NOT into a MUST NOT without creating a new version of the protocol,
>as I very much doubt that IETF likes retrospective legislation.  To get
>your desired effect in a new version of the protocol, you would need to 
>have something like:
>
>   1        primary reference (this value SHALL only be used by
>            <definition that doesn't depend on the use of "e.g.">)
>   2-15     secondary reference (these values SHALL only be used by
>            a server fully implementing NTP (RFCxxxx))
>  
>
That seems to me to be entirely too many strata!   Since each stratum 
degrades the quality of time; sometimes significantly, stratum 14 would 
likely be no better than your great grandfather's tall case clock 
(commonly called a grandfather clock).

Stratum ten is "conventional" for an unsynchronized local clock because 
nobody is likely to listen to or believe a server claiming stratum ten 
if there is any other choice.

Is anybody synchronizing anything to a stratum higher than five or six?  
(other than servers running unsynchronized local clocks?)

I've read elsewhere that stratum is an eight bit field.  It seems to me 
that five of those bits might be dedicated to some more useful purpose; 
e.g. indicating a sever using SNTP, a server using an unsynchronized 
local clock, a secondary server with fewer than four upstream sources, etc.

Some of the bits might be used to indicate the type of reference clock 
since some are much more desirable than others; e.g. a server 
synchronized to GPS at stratum 1 is more desirable than a server 
synchronized to an HF radio clock at stratum one.

Harlan,

The legal values for stratum in rfc-1305 are 1-255 (see page 10). 
Stratum 0 is intended as unknown or invalid. Strata 15 or 16 have no 
particular interpretation other than as convention in the reference 
implementation.  However, if a count-to-infinity hazard exists, use of 
strata greater than a "small" number could be dangerous. That's why I 
suggested strata 1-14 in rfc2030 for primary and secondary with 15-255 
as reserved. The value 14 should be 15 to match the reference 
implementation, but any choice is arbitrary. The point is that some 
choice of "infinity" is necessary with the expectation that, should the 
stratum equal or exceed infinity be mapped to zero.

Any distinction between NTP and SNTP with regard the on-wire protocol is 
  misguided. They use the same protocol. My suggestion of default values 
was intended to simplify the operation while preserving the same 
timestamp calculations.

Dave

Harlan Stenn wrote:
> Dave,
> 
> I just re-read the draft 2030 spec and it says that the legal values for
> stratum on a reply are 1-14.
> 
> 0 is a KOD reply.  If an SNTP implementation is not sync'd to a refclock
> I see no clear statement in the draft RCF that it should return a KOD reply.
> 
> I also do not understand why 15 is not listed as an allowed value in a
> stratum response.  I would expect 15 to be returned from a sender at stratum
> 14.
> 
> Also, the draft SNTP RFC says:
> 
>  Stratum: This is a eight-bit unsigned integer indicating the stratum of the
>  server or client, with values defined as follows:
> 
>    Stratum  Meaning
>    ----------------------------------------------
>    0        kiss-o'-death message (see below)
>    1        primary reference (e.g., synchronized by radio clock)
>    2-15     secondary reference (synchronized by NTP or SNTP)
>    16-255   reserved
> 
> The following seems better to me:
> 
>    Stratum  Meaning
>    ----------------------------------------------
>    0        kiss-o'-death message (including SNTP client.  See below)
>    1        primary reference (NTP or SNTP, synchronized, e.g., by radio clock)
>    2-15     secondary reference (synchronized by NTP)
>    16-255   reserved
> 
> I gather the IETF WG is the place to go over this stuff.
> 
> H

Richard,

Good comments. As you know, a primary server operating at stratum 1 
displays the source in the reference ID field, with the expectation that 
an unsynchronized local clock shows something like LOCL. The problem is 
how to detect this condition with a higher local clock stratum 
assignment. An obvious way to do this is to require that the reference 
ID be the local clock driver itself. This makes it easy for the 
immediate upstratum client to discover the local clock, but disguises it 
for its own upstratum clients.

I am a little concerned about the overuse of local clock "subnets" with 
multiple local clocks arranged in a fallback configuration. There have 
been reports where some failure or other resulted in nasty timing loops 
and counting to infinity behavior.

If the local clock is intended as fallback when all synchronized sources 
are lost, the best response in most configurations is for all clients 
simply to coast with no sources. With the ACTS driver and a poll 
interval of 36 hours, the residual offset rarely exceeds 20 ms. So why 
bother with a local clock if the MTTR is less than a day? Let the 
dependents coast until the synchronized sources are found again.

If the local clock is by design the only source in the subnet and there 
is no opportunity to find synchronized sources, then operate the local 
clock server at stratum 1 and be done with it.

Dave

Richard B. Gilbert wrote:

> David Woolley wrote:
> 
>> In article <ywn9d5qs9vil.fsf@ntp1.isc.org>,
>> Harlan Stenn <stenn@ntp.isc.org> wrote:
>>
>>  
>>
>>> I just re-read the draft 2030 spec and it says that the legal values for
>>>   
>>
>>
>> RFC 2030 is released.  It can't be a draft.  Any replacement will have
>> a new RFC number.  It will either obsolete RFC 2030 or define a new 
>> version
>> of the protocol.  (For example, the NTP v4 RFC, when it arrives, will not
>> obsolete RFC 1305.)
>>
>>  
>>
>> <snip>
>>
>>
>> You may be proposing a new RFC.  In that case, I doubt that you can 
>> change
>> a SHOULD NOT into a MUST NOT without creating a new version of the 
>> protocol,
>> as I very much doubt that IETF likes retrospective legislation.  To get
>> your desired effect in a new version of the protocol, you would need 
>> to have something like:
>>
>>   1        primary reference (this value SHALL only be used by
>>            <definition that doesn't depend on the use of "e.g.">)
>>   2-15     secondary reference (these values SHALL only be used by
>>            a server fully implementing NTP (RFCxxxx))
>>  
>>
> That seems to me to be entirely too many strata!   Since each stratum 
> degrades the quality of time; sometimes significantly, stratum 14 would 
> likely be no better than your great grandfather's tall case clock 
> (commonly called a grandfather clock).
> 
> Stratum ten is "conventional" for an unsynchronized local clock because 
> nobody is likely to listen to or believe a server claiming stratum ten 
> if there is any other choice.
> 
> Is anybody synchronizing anything to a stratum higher than five or six?  
> (other than servers running unsynchronized local clocks?)
> 
> I've read elsewhere that stratum is an eight bit field.  It seems to me 
> that five of those bits might be dedicated to some more useful purpose; 
> e.g. indicating a sever using SNTP, a server using an unsynchronized 
> local clock, a secondary server with fewer than four upstream sources, etc.
> 
> Some of the bits might be used to indicate the type of reference clock 
> since some are much more desirable than others; e.g. a server 
> synchronized to GPS at stratum 1 is more desirable than a server 
> synchronized to an HF radio clock at stratum one.

Good stuff.

I was talking about what I believe is the proposed "next" thing after 2030,
which I found at http://ntp.isc.org/Support/NTPRelatedRFCs .

I would hope that people interested in seeing improvement in the specs
and protocols would participate in the IETF WG, which is "organized" and
traking progress at http://ntp.isc.org/IETF/WebHome .

Finally, the LOCL clock stuff is interesting and seems to me to boil down to
tradeoffs with money (should we get time from the network or get at least
one refclock; should we get some sort of PPS or atomic clock?).  This is all
done in the name of "increasing the number of 9s".

The amount of thought and flexibility/robustness of the use of LOCL is again
all about "increasing the number of 9s".

As usual, I want to see sufficient mechanism to allow folks to implement
their local policy choices to get their desired "number of 9s".  Not too
much mechanism, and not too little.

H

Dave,

I thought you said in a recent previous posting that you wrote the follow-on
to the 2030 spec to state that an SNTP implementation that does not have an
attached refclock should advertise itself as stratum 0.

However, in this latest post you said:

 The legal values for stratum in rfc-1305 are 1-255 (see page
 10). Stratum 0 is intended as unknown or invalid.

It is not clear to me exactly what you mean.

I just reread that spec again and I do not see that you intend the stratum
discussion in 2030++ as a simplification of what is described in 1305.  As
written, the document communicates that the stuff described is what 1305
says and:

- if somebody reads 1305 as well they could well be confused
- if they do not read 1305 the will be confused

I suspect this is exactly the sort of thing that will be cleaned up in the
IETF process.

H

David L. Mills wrote:

> Richard,
>
> Good comments. As you know, a primary server operating at stratum 1 
> displays the source in the reference ID field, with the expectation 
> that an unsynchronized local clock shows something like LOCL. The 
> problem is how to detect this condition with a higher local clock 
> stratum assignment. An obvious way to do this is to require that the 
> reference ID be the local clock driver itself. This makes it easy for 
> the immediate upstratum client to discover the local clock, but 
> disguises it for its own upstratum clients.
>
> I am a little concerned about the overuse of local clock "subnets" 
> with multiple local clocks arranged in a fallback configuration. There 
> have been reports where some failure or other resulted in nasty timing 
> loops and counting to infinity behavior.
>
> If the local clock is intended as fallback when all synchronized 
> sources are lost, the best response in most configurations is for all 
> clients simply to coast with no sources. With the ACTS driver and a 
> poll interval of 36 hours, the residual offset rarely exceeds 20 ms. 
> So why bother with a local clock if the MTTR is less than a day? Let 
> the dependents coast until the synchronized sources are found again.
>
> If the local clock is by design the only source in the subnet and 
> there is no opportunity to find synchronized sources, then operate the 
> local clock server at stratum 1 and be done with it.
>
> Dave
>
> Richard B. Gilbert wrote:
>
>> David Woolley wrote:
>>
>>> In article <ywn9d5qs9vil.fsf@ntp1.isc.org>,
>>> Harlan Stenn <stenn@ntp.isc.org> wrote:
>>>
>>>  
>>>
>>>> I just re-read the draft 2030 spec and it says that the legal 
>>>> values for
>>>>   
>>>
>>>
>>>
<snip>

I thought that the concern with unsynchronized local clocks on an 
isolated net operating at a low stratum was that the isolation might not 
be preserved!

A high stratum should be plenty of warning if such a system did get 
connected to the internet.

Some subnets are isolated because there is no internet connection 
available, some because a connection to the internet is forbidden for 
security reasons and perhaps there might be other reasons.  I think that 
all of the above are subject to change with varying probabilities of 
such a change.

I think that any new RFC for NTP should specify a safe way (for the rest 
of the world) to set up such an isolated net.  It should, of course, 
include appropriate warnings about the limitations of such a setup and 
the suggestion the NTP might be the wrong tool for the job.  (All right, 
it IS the wrong tool but people want  their clocks synchronized and 
don't really care what time it is and NTP is there. . . .    There's no 
point in fighting a battle already lost.)

Hello,

as David Wooley wrote on 11. June,=20
my original article had meant the server response
to an SNTP client request, not really that the server had to be an
SNTP server. I am simply sending a datagram as described in rfc2030 to
a public time server and use the reply to set the system time on
standalone PCs.

May I ask 2 additional questions, please?

1. From my OP:
Is the leap second flag bit in the server's reply set only during the
leap second or on the whole day of the condition?

2. Are the passed leap seconds of the last years to be counted in the
timestamp, or is it correct to multiply simply (as I did)
PassedDaysCount * SecondsPerDay ?

Excuse me for the naive questions,
 Friedel

In article <avova1p95kdfooh9ukr8iir2eevi9v4kga@4ax.com>,
Friedel Jantzen <nospam_plz@freenet.de> wrote:

> Is the leap second flag bit in the server's reply set only during the
> leap second or on the whole day of the condition?

RFC 1305 Page 10:  The bits are set before 23:59 on the day of the
insertion and reset after 00:00 on the following day.... In the case
of primary servers, the bits are set by operator intervention, while in
the case of secondary servers the bits are set by the protocol. .....

Which means that they can be set for an extended period around the
leap second.  (I think this definition is unsafe, because poll intervals
are normally more than 60 seconds; they really need to be set at least
quite a few maximum poll intervals before the nominal leap second.)

> 2. Are the passed leap seconds of the last years to be counted in the
> timestamp, or is it correct to multiply simply (as I did)
> PassedDaysCount * SecondsPerDay ?

RFC 1305 Page 78:  Thus when a leap second is inserted in UTC and subsequently
in NTP, knowledge of all previous leap seconds is lost.

   Another was to describe this is to say there are as many NTP
timescales as historic leap seconds.  In effect, a new timescale is
established after each new leap second.  .....

So your simple multiplication is correct.

Thank you for the detailled information, David.
 Friedel