Re: Consequences of the leap-second

[Sean Murray <murray@tlabs.ac.za>]

Hi

> It seems that all the RHEL6 systems at APS that were running any kind of a JVM
> have been pegging a CPU, and even Firefox is eating up 100% of a CPU on my box
> despite restarting the program.  An OS reboot apparently fixes the problem,
> but if you have any kind of OS support contract you might want to check with
> them first since they might have a less drastic fix available.

Slightly less drastic would be to set the date:
/etc/init.d/ntp stop
date -s "`date`"
/etc/init.d/ntp start

Cheers
Sean

> Time on some of our vxWorks IOCs (those that get their time from our Master
> Timing IOC either through the event system or from the time broadcasts) is
> currently running 1 second ahead of NTP time.  I suspect that this will not
> correct itself until we reboot the Master Timing IOC, and then we'll need to
> be prepared for worse things to happen:
>
> iocrfcavs37> generalTimeReport 2
> Backwards time errors prevented 821232 times.
>
> Current Time Providers:
>      "APS Event Receiver", priority = 70
>          Current Time is 2012-07-02 11:34:02.450920.
>      "APS Time Broadcast", priority = 75
>          Current Time is 2012-07-02 11:34:02.458920.
>      "NTP", priority = 100
>          Current Time is 2012-07-02 11:34:01.446454.
>      "OS Clock", priority = 999
>          Current Time is 2012-07-02 11:34:02.449253.
>
> Event Time Providers:
>      "APS Event Receiver", priority = 70
>
> value = 0 = 0x0
>
> iocvidcentral> generalTimeReport 2
> Backwards time errors prevented 2574916 times.
>
> Current Time Providers:
>      "APS Time Broadcast", priority = 75
>          Current Time is 2012-07-02 11:39:31.579253.
>      "NTP", priority = 100
>          Current Time is 2012-07-02 11:39:30.567739.
>      "OS Clock", priority = 999
>          Current Time is 2012-07-02 11:39:31.580253.
>
> Event Time Providers:
>          No Providers registered.
> value = 0 = 0x0
>
>
> - Andrew