Hi all,
Since yesterday I saw the leap second Flag set on some servers of
ntp.pool.org. I'am quite surprise because the leap second add to be
set the 31/12/2008 and not the 1/12/2008.
Is it normal????

Michael

michael.froment@gmail.com writes:

>Hi all,
>Since yesterday I saw the leap second Flag set on some servers of
>ntp.pool.org. I'am quite surprise because the leap second add to be
>set the 31/12/2008 and not the 1/12/2008.
>Is it normal????

The leap is announced at the beginning of the month to make sure that all
ntp clients know about it. It always occurs at the end of the month ( I
think ntpd has it hard coded as the end of June or Dec, but in principle it
could be any month)

>Michael

On 2 d=E9c, 20:22, Unruh <unruh-s...@physics.ubc.ca> wrote:
> michael.from...@gmail.com writes:
> >Hi all,
> >Since yesterday I saw the leap second Flag set on some servers of
> >ntp.pool.org. I'am quite surprise because the leap second add to be
> >set the 31/12/2008 and not the 1/12/2008.
> >Is it normal????
>
> The leap is announced at the beginning of the month to make sure that all
> ntp clients know about it. It always occurs at the end of the month ( I
> think ntpd has it hard coded as the end of June or Dec, but in principle =
it
> could be any month)
>
> >Michael

Mmmm
I'm not sure...
Here is an extract of the RFC1035 about NTP V3

Leap Indicator (LI): This is a two-bit code warning of an impending
leap
second to be inserted/deleted in the last minute of the current day,
with bit 0 and bit 1, respectively, coded as follows:


Regards

Michael

morsupil wrote:
> On 2 d�c, 20:22, Unruh <unruh-s...@physics.ubc.ca> wrote:
>> michael.from...@gmail.com writes:
>>> Hi all,
>>> Since yesterday I saw the leap second Flag set on some servers of
>>> ntp.pool.org. I'am quite surprise because the leap second add to be
>>> set the 31/12/2008 and not the 1/12/2008.
>>> Is it normal????
>> The leap is announced at the beginning of the month to make sure that all
>> ntp clients know about it. It always occurs at the end of the month ( I
>> think ntpd has it hard coded as the end of June or Dec, but in principle it
>> could be any month)
>>
>>> Michael
> 
> Mmmm
> I'm not sure...
> Here is an extract of the RFC1035 about NTP V3
> 
> Leap Indicator (LI): This is a two-bit code warning of an impending
> leap
> second to be inserted/deleted in the last minute of the current day,
> with bit 0 and bit 1, respectively, coded as follows:
> 
> 
> Regards
> 
> Michael

NTP V3.x has been obsolete for years!  Current version is 4.something.

At last report, a committee was writing a new RFC for NTP V4.  AFAIK, 
they have been working on it for a couple of years now.  I'm not going 
to hold my breath.

Unruh <unruh-spam@physics.ubc.ca> writes:

>michael.froment@gmail.com writes:

>>Hi all,
>>Since yesterday I saw the leap second Flag set on some servers of
>>ntp.pool.org. I'am quite surprise because the leap second add to be
>>set the 31/12/2008 and not the 1/12/2008.
>>Is it normal????

>The leap is announced at the beginning of the month to make sure that all
>ntp clients know about it. It always occurs at the end of the month ( I
>think ntpd has it hard coded as the end of June or Dec, but in principle it
>could be any month)

Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)

if ((tm->tm_mon + 1 == 6 &&
                tm->tm_mday == 30) || (tm->tm_mon +
                1 == 12 && tm->tm_mday == 31)) {
               if (leap_next & LEAP_ADDSECOND)
                  ntv.status |= STA_INS;
               else if (leap_next &
                   LEAP_DELSECOND)
                  ntv.status |= STA_DEL;

Ie, ntp pays attention to the leap second flag only if it is June 30 or Dec
31. Now, that is not correct since I believe that a leapsecond can occur on
any month, but the tradition is that if there is only one or two a year,
those are the dates chosen. In a century or two, when there are more than 2
per year, then ntpd will run into trouble. (Of course the definition of
time might have changed anyway, or the whole UTC kludge may be scrapped or
a new edition of ntpd not containing that assumption may be published.)
Note that the very existence of ntpd with its assumptions puts huge
pressure on the standards organisation to comply with the assumptions. 

On 3 d=E9c, 00:30, Bill Unruh <un...@physics.ubc.ca> wrote:
> Unruh <unruh-s...@physics.ubc.ca> writes:
> >michael.from...@gmail.com writes:
> >>Hi all,
> >>Since yesterday I saw the leap second Flag set on some servers of
> >>ntp.pool.org. I'am quite surprise because the leap second add to be
> >>set the 31/12/2008 and not the 1/12/2008.
> >>Is it normal????
> >The leap is announced at the beginning of the month to make sure that al=
l
> >ntp clients know about it. It always occurs at the end of the month ( I
> >think ntpd has it hard coded as the end of June or Dec, but in principle=
 it
> >could be any month)
>
> Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)
>
> if ((tm->tm_mon + 1 =3D=3D 6 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tm->tm_mday =3D=3D 30) || (tm->tm_mon +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =3D=3D 12 && tm->tm_mday =3D=3D 31)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (leap_next & LEAP_ADDSECOND)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ntv.status |=3D STA_INS;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (leap_next &
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LEAP_DELSECOND)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ntv.status |=3D STA_DEL;
>
> Ie, ntp pays attention to the leap second flag only if it is June 30 or D=
ec
> 31. Now, that is not correct since I believe that a leapsecond can occur =
on
> any month, but the tradition is that if there is only one or two a year,
> those are the dates chosen. In a century or two, when there are more than=
 2
> per year, then ntpd will run into trouble. (Of course the definition of
> time might have changed anyway, or the whole UTC kludge may be scrapped o=
r
> a new edition of ntpd not containing that assumption may be published.)
> Note that the very existence of ntpd with its assumptions puts huge
> pressure on the standards organisation to comply with the assumptions.

So this could not cause problem if on a pool of servers someone answer
with the LI flag set and another one without the LI flag set????
I'm quite surprise by the fact that ntpd seems to be the standard...
There is many of other client and many of other servers...

morsupil <michael.froment@gmail.com> writes:

>On 3 d=E9c, 00:30, Bill Unruh <un...@physics.ubc.ca> wrote:
>> Unruh <unruh-s...@physics.ubc.ca> writes:
>> >michael.from...@gmail.com writes:
>> >>Hi all,
>> >>Since yesterday I saw the leap second Flag set on some servers of
>> >>ntp.pool.org. I'am quite surprise because the leap second add to be
>> >>set the 31/12/2008 and not the 1/12/2008.
>> >>Is it normal????
>> >The leap is announced at the beginning of the month to make sure that al=
>l
>> >ntp clients know about it. It always occurs at the end of the month ( I
>> >think ntpd has it hard coded as the end of June or Dec, but in principle=
> it
>> >could be any month)
>>
>> Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)
>>
>> if ((tm->tm_mon + 1 =3D=3D 6 &&
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tm->tm_mday =3D=3D 30) || (tm->tm_mon +
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =3D=3D 12 && tm->tm_mday =3D=3D 31)) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (leap_next & LEAP_ADDSECOND)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ntv.status |=3D STA_INS;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (leap_next &
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LEAP_DELSECOND)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ntv.status |=3D STA_DEL;
>>
>> Ie, ntp pays attention to the leap second flag only if it is June 30 or D=
>ec
>> 31. Now, that is not correct since I believe that a leapsecond can occur =
>on
>> any month, but the tradition is that if there is only one or two a year,
>> those are the dates chosen. In a century or two, when there are more than=
> 2
>> per year, then ntpd will run into trouble. (Of course the definition of
>> time might have changed anyway, or the whole UTC kludge may be scrapped o=
>r
>> a new edition of ntpd not containing that assumption may be published.)
>> Note that the very existence of ntpd with its assumptions puts huge
>> pressure on the standards organisation to comply with the assumptions.

>So this could not cause problem if on a pool of servers someone answer
>with the LI flag set and another one without the LI flag set????
>I'm quite surprise by the fact that ntpd seems to be the standard...
>There is many of other client and many of other servers...

ntpd is largely controlled and  part written by Mills, the original developer of
the ntp protocol, and still strongly involed in the development of ntp.
ntpd is the reference inplimentation-- meaning it does ( module bugs)
exactly what an ntp server/client is supposed to do.

From the header of ntp_loopfilter.c

"/*
 * ntp_loopfilter.c - implements the NTP loop filter algorithm
 *
 * ATTENTION: Get approval from Dave Mills on all changes to this file!
 *
 */
"

morsupil <michael.froment@gmail.com> writes:

>On 3 d=E9c, 00:30, Bill Unruh <un...@physics.ubc.ca> wrote:
>> Unruh <unruh-s...@physics.ubc.ca> writes:
>> >michael.from...@gmail.com writes:
>> >>Hi all,
>> >>Since yesterday I saw the leap second Flag set on some servers of
>> >>ntp.pool.org. I'am quite surprise because the leap second add to be
>> >>set the 31/12/2008 and not the 1/12/2008.
>> >>Is it normal????
>> >The leap is announced at the beginning of the month to make sure that al=
>l
>> >ntp clients know about it. It always occurs at the end of the month ( I
>> >think ntpd has it hard coded as the end of June or Dec, but in principle=
> it
>> >could be any month)
>>
>> Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)
>>
>> if ((tm->tm_mon + 1 =3D=3D 6 &&
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tm->tm_mday =3D=3D 30) || (tm->tm_mon +
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =3D=3D 12 && tm->tm_mday =3D=3D 31)) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (leap_next & LEAP_ADDSECOND)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ntv.status |=3D STA_INS;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (leap_next &
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LEAP_DELSECOND)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ntv.status |=3D STA_DEL;
>>
>> Ie, ntp pays attention to the leap second flag only if it is June 30 or D=
>ec
>> 31. Now, that is not correct since I believe that a leapsecond can occur =
>on
>> any month, but the tradition is that if there is only one or two a year,
>> those are the dates chosen. In a century or two, when there are more than=
> 2
>> per year, then ntpd will run into trouble. (Of course the definition of
>> time might have changed anyway, or the whole UTC kludge may be scrapped o=
>r
>> a new edition of ntpd not containing that assumption may be published.)
>> Note that the very existence of ntpd with its assumptions puts huge
>> pressure on the standards organisation to comply with the assumptions.

>So this could not cause problem if on a pool of servers someone answer
>with the LI flag set and another one without the LI flag set????
>I'm quite surprise by the fact that ntpd seems to be the standard...
>There is many of other client and many of other servers...

Just to clarify: the standrds say that Dec 31 and June 30 are the preferred
dates, March 31 and Sep 30 the secondary ones. I assume once we get to the
24th century once we need more than 4 leap sec a year, standards will have
changed.

On Dec 3, 8:10=A0am, Unruh <unruh-s...@physics.ubc.ca> wrote:
> morsupil <michael.from...@gmail.com> writes:
> >On 3 d=3DE9c, 00:30, Bill Unruh <un...@physics.ubc.ca> wrote:
> >> Unruh <unruh-s...@physics.ubc.ca> writes:
> >> >michael.from...@gmail.com writes:
> >> >>Hi all,
> >> >>Since yesterday I saw the leap second Flag set on some servers of
> >> >>ntp.pool.org. I'am quite surprise because the leap second add to be
> >> >>set the 31/12/2008 and not the 1/12/2008.
> >> >>Is it normal????
> >> >The leap is announced at the beginning of the month to make sure that=
 al=3D
> >l
> >> >ntp clients know about it. It always occurs at the end of the month (=
 I
> >> >think ntpd has it hard coded as the end of June or Dec, but in princi=
ple=3D
> > it
> >> >could be any month)
>
> >> Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)
>
> >> if ((tm->tm_mon + 1 =3D3D=3D3D 6 &&
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 tm->tm_mday =3D3D=3D3D=
 30) || (tm->tm_mon +
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 1 =3D3D=3D3D 12 && tm-=
>tm_mday =3D3D=3D3D 31)) {
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0if (leap_next & LEAP_AD=
DSECOND)
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ntv.status |=3D3=
D STA_INS;
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0else if (leap_next &
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0LEAP_DELSEC=
OND)
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ntv.status |=3D3=
D STA_DEL;
>
> >> Ie, ntp pays attention to the leap second flag only if it is June 30 o=
r D=3D
> >ec
> >> 31. Now, that is not correct since I believe that a leapsecond can occ=
ur =3D
> >on
> >> any month, but the tradition is that if there is only one or two a yea=
r,
> >> those are the dates chosen. In a century or two, when there are more t=
han=3D
> > 2
> >> per year, then ntpd will run into trouble. (Of course the definition o=
f
> >> time might have changed anyway, or the whole UTC kludge may be scrappe=
d o=3D
> >r
> >> a new edition of ntpd not containing that assumption may be published.=
)
> >> Note that the very existence of ntpd with its assumptions puts huge
> >> pressure on the standards organisation to comply with the assumptions.
> >So this could not cause problem if on a pool of servers someone answer
> >with the LI flag set and another one without the LI flag set????
> >I'm quite surprise by the fact that ntpd seems to be the standard...
> >There is many of other client and many of other servers...
>
> Just to clarify: the standrds say that Dec 31 and June 30 are the preferr=
ed
> dates, March 31 and Sep 30 the secondary ones. I assume once we get to th=
e
> 24th century once we need more than 4 leap sec a year, standards will hav=
e
> changed.

It seems that since the LI flag is set on some servers, some NTP
clients problems.
Here is a problem reported by a nagios server on some ntp servers:
/usr/local/nagios/libexec/check_ntp -H xxx.xxx.xxx.xxx
NTP CRITICAL: Offset unknown

I also see since 3 day problems on some Set Top Box that doesn't
understand the answer from an ntpd server causing those STB hanging at
boot... The workaround solution for the moment is to shutdown
synchronisation with Public NTP server pool... too bad...

Any Ideas?

morsupil <michael.froment@gmail.com> writes:

>It seems that since the LI flag is set on some servers, some NTP
>clients problems.
>Here is a problem reported by a nagios server on some ntp servers:
>/usr/local/nagios/libexec/check_ntp -H xxx.xxx.xxx.xxx
>NTP CRITICAL: Offset unknown

The first link I see when I search for check_ntp says it is depricated.
Could it be a bug in check_ntp? Are the servers running an unusual ntp
daemon?

>I also see since 3 day problems on some Set Top Box that doesn't
>understand the answer from an ntpd server causing those STB hanging at
>boot... The workaround solution for the moment is to shutdown
>synchronisation with Public NTP server pool... too bad...

You probably need to complain to the STB vendor... Who makes them?
Any idea who did the NTP implementation?

	David.

On Dec 3, 10:09=A0am, dwmal...@maths.tcd.ie (David Malone) wrote:
> morsupil <michael.from...@gmail.com> writes:
> >It seems that since the LI flag is set on some servers, some NTP
> >clients problems.
> >Here is a problem reported by a nagios server on some ntp servers:
> >/usr/local/nagios/libexec/check_ntp -H xxx.xxx.xxx.xxx
> >NTP CRITICAL: Offset unknown
>
> The first link I see when I search for check_ntp says it is depricated.
> Could it be a bug in check_ntp? Are the servers running an unusual ntp
> daemon?
>
> >I also see since 3 day problems on some Set Top Box that doesn't
> >understand the answer from an ntpd server causing those STB hanging at
> >boot... The workaround solution for the moment is to shutdown
> >synchronisation with Public NTP server pool... too bad...
>
> You probably need to complain to the STB vendor... Who makes them?
> Any idea who did the NTP implementation?
>
> =A0 =A0 =A0 =A0 David.

The server is running an usual ntp daemon provide by debian etch.
I think that the check_ntp in nagios is deprecated... I've check with
a newer version and there is no problem...
It is a Sagem STB but I dont know who makes the NTP implementation...

Kind regards

Michael

On 2008-12-03, morsupil <michael.froment@gmail.com> wrote:

> I also see since 3 day problems on some Set Top Box that doesn't
> understand the answer from an ntpd server causing those STB hanging at
> boot... The workaround solution for the moment is to shutdown
> synchronisation with Public NTP server pool... too bad...
>
> Any Ideas?

Use time servers you trust rather than random pool servers.

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

morsupil <michael.froment@gmail.com> writes:

>On Dec 3, 8:10=A0am, Unruh <unruh-s...@physics.ubc.ca> wrote:
>> morsupil <michael.from...@gmail.com> writes:
>> >On 3 d=3DE9c, 00:30, Bill Unruh <un...@physics.ubc.ca> wrote:
>> >> Unruh <unruh-s...@physics.ubc.ca> writes:
>> >> >michael.from...@gmail.com writes:
>> >> >>Hi all,
>> >> >>Since yesterday I saw the leap second Flag set on some servers of
>> >> >>ntp.pool.org. I'am quite surprise because the leap second add to be
>> >> >>set the 31/12/2008 and not the 1/12/2008.
>> >> >>Is it normal????
>> >> >The leap is announced at the beginning of the month to make sure that=
> al=3D
>> >l
>> >> >ntp clients know about it. It always occurs at the end of the month (=
> I
>> >> >think ntpd has it hard coded as the end of June or Dec, but in princi=
>ple=3D
>> > it
>> >> >could be any month)
>>
>> >> Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)
>>
>> >> if ((tm->tm_mon + 1 =3D3D=3D3D 6 &&
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 tm->tm_mday =3D3D=3D3D=
> 30) || (tm->tm_mon +
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 1 =3D3D=3D3D 12 && tm-=
>>tm_mday =3D3D=3D3D 31)) {
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0if (leap_next & LEAP_AD=
>DSECOND)
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ntv.status |=3D3=
>D STA_INS;
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0else if (leap_next &
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0LEAP_DELSEC=
>OND)
>> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ntv.status |=3D3=
>D STA_DEL;
>>
>> >> Ie, ntp pays attention to the leap second flag only if it is June 30 o=
>r D=3D
>> >ec
>> >> 31. Now, that is not correct since I believe that a leapsecond can occ=
>ur =3D
>> >on
>> >> any month, but the tradition is that if there is only one or two a yea=
>r,
>> >> those are the dates chosen. In a century or two, when there are more t=
>han=3D
>> > 2
>> >> per year, then ntpd will run into trouble. (Of course the definition o=
>f
>> >> time might have changed anyway, or the whole UTC kludge may be scrappe=
>d o=3D
>> >r
>> >> a new edition of ntpd not containing that assumption may be published.=
>)
>> >> Note that the very existence of ntpd with its assumptions puts huge
>> >> pressure on the standards organisation to comply with the assumptions.
>> >So this could not cause problem if on a pool of servers someone answer
>> >with the LI flag set and another one without the LI flag set????
>> >I'm quite surprise by the fact that ntpd seems to be the standard...
>> >There is many of other client and many of other servers...
>>
>> Just to clarify: the standrds say that Dec 31 and June 30 are the preferr=
>ed
>> dates, March 31 and Sep 30 the secondary ones. I assume once we get to th=
>e
>> 24th century once we need more than 4 leap sec a year, standards will hav=
>e
>> changed.

>It seems that since the LI flag is set on some servers, some NTP
>clients problems.
>Here is a problem reported by a nagios server on some ntp servers:
>/usr/local/nagios/libexec/check_ntp -H xxx.xxx.xxx.xxx
>NTP CRITICAL: Offset unknown

>I also see since 3 day problems on some Set Top Box that doesn't
>understand the answer from an ntpd server causing those STB hanging at
>boot... The workaround solution for the moment is to shutdown
>synchronisation with Public NTP server pool... too bad...

>Any Ideas?

Get better ntp programs! If an ntp gets it knickers in a twist because
there is a leap second flag in the response, it is a seriously buggy
program. Now some (eg chrony) just ignore the leap second flag. But it
should not go belly up. Of course the problem may be entirely different
from the leap second flag. No idea what "Offset unknown" means.