Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
NTP and Leap Second testing (update)
Skip to first unread message
Phil Fisher
May 23, 2012, 4:10:31 PM5/23/12
to
NTP gurus
(and especially Dave Hart who was kind enough to correspond previously)
Have been doing (finally) some testing with the aid of VM systems. I took DH advice and used one at ntp 4.2.6 (not the most recent admittedly) as the server and the client based on our RHEL 4.3 + odd bits that has ntpd 4.2...@1.1190-r on it.
I used the leap-seconds file from the usual place to "prime" the server and set the local date and time to 30 June 2012 2350 UTC on both systems. At this point NTP was off.
Having enabled ntpd I watched the usual traffic and start up and was able to see the LI being passed to the client. However, since it took about 8 or so minutes for the client to sync up, it did not note the need to insert a leap second until past midnight. Meanwhile the server issued the leap second inserted message as expected at 0000 UTC.
What was puzzling was that when the time reached 0000 1 July 2012, on the client the leap second was inserted as seen from the following line in syslog:
Jul 2 00:59:59 lsntpclient kernel: Clock: inserting leap second 23:59:60 UTC
Now, having looked at the kernel code, I understand why this can occur (the kernel code in 2.6.9 only checks for end of day) but I am more concerned about why it is propagated into the second day at all. Why is the LI from ntpd not cleared once the insertion time is passed?
I have some extra info and logs if that is of interest from ntptime, ntpdc -c kerninfo and ntpq -c readvar should that be of interest.
Phil.
--
Phil Fisher| BSC Platform Engineer (Linux)
This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately.
ip.access Ltd, registration number 3400157, Building 2020,
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
(and especially Dave Hart who was kind enough to correspond previously)
Have been doing (finally) some testing with the aid of VM systems. I took DH advice and used one at ntp 4.2.6 (not the most recent admittedly) as the server and the client based on our RHEL 4.3 + odd bits that has ntpd 4.2...@1.1190-r on it.
I used the leap-seconds file from the usual place to "prime" the server and set the local date and time to 30 June 2012 2350 UTC on both systems. At this point NTP was off.
Having enabled ntpd I watched the usual traffic and start up and was able to see the LI being passed to the client. However, since it took about 8 or so minutes for the client to sync up, it did not note the need to insert a leap second until past midnight. Meanwhile the server issued the leap second inserted message as expected at 0000 UTC.
What was puzzling was that when the time reached 0000 1 July 2012, on the client the leap second was inserted as seen from the following line in syslog:
Jul 2 00:59:59 lsntpclient kernel: Clock: inserting leap second 23:59:60 UTC
Now, having looked at the kernel code, I understand why this can occur (the kernel code in 2.6.9 only checks for end of day) but I am more concerned about why it is propagated into the second day at all. Why is the LI from ntpd not cleared once the insertion time is passed?
I have some extra info and logs if that is of interest from ntptime, ntpdc -c kerninfo and ntpq -c readvar should that be of interest.
Phil.
--
Phil Fisher| BSC Platform Engineer (Linux)
This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately.
ip.access Ltd, registration number 3400157, Building 2020,
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
E-Mail Sent to this address will be added to the BlackLists
May 23, 2012, 5:30:38 PM5/23/12
to
Phil Fisher wrote:
> ntp 4.2.6 ... on our RHEL 4.3 + odd bits
RHEL6 ? kernel 3.4 ? ntp 4.2.7p276 ?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
> ntp 4.2.6 ... on our RHEL 4.3 + odd bits
>
> Now, having looked at the kernel code,
> I understand why this can occur (the kernel code in 2.6.9
> only checks for end of day)
Does the issue still occur with,
> Now, having looked at the kernel code,
> I understand why this can occur (the kernel code in 2.6.9
> only checks for end of day)
RHEL6 ? kernel 3.4 ? ntp 4.2.7p276 ?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Dave Hart
May 23, 2012, 6:01:51 PM5/23/12
to
On Wed, May 23, 2012 at 8:10 PM, Phil Fisher <Phil....@ipaccess.com> wrote:
> Now, having looked at the kernel code, I understand why this can occur
> Now, having looked at the kernel code, I understand why this can occur
> concerned about why it is propagated into the second day at all. Why is
> the LI from ntpd not cleared once the insertion time is passed?
Based on your earlier testing, where we saw that once you manually
> the LI from ntpd not cleared once the insertion time is passed?
forced on the kernel leap bit, it was not cleared by subsequent
updates from ntpd via adjtimex/ntp_adjtime, I'm guessing the kernel in
question is failing to clear the leap indication despite ntpd having
done so.
If this reproduces with 4.2.6p5 or the latest 4.2.7, I'd love to fix
it. There may be a need to specially handle the case where upstream
LI is seen but UTC midnight has passed since the sample in question.
Cheers,
Dave Hart
0 new messages