Re: clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

On 2015-07-03 15:38:02 +0200, Michael Biebl wrote:
> In short, your ntp client should ensure that the clock is synced to RTC
> (google for "ntp 11 min mode sync" if you want to know more). For that
> we enable timesyncd by default in systemd.

Thanks for the information, but the documentation shouldn't be in the
official documentation (man pages...), not on the web.

> If you choose to disable timesyncd and/or use another NTP client, then
> this is not a bug in systemd.

The clock was inaccurate before I installed another NTP client.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150703143550.ga8...@ypig.lip.ens-lyon.fr

Re: clock losing time after a reboot with HP ZBook G2

[Lisi Reisz]

On Friday 03 July 2015 14:38:02 Michael Biebl wrote:
> Am 03.07.2015 um 15:18 schrieb Arno Schuring:
> >> Date: Fri, 3 Jul 2015 15:07:34 +0200
> >> From: vinc...@vinc17.net
> >>
> >> When I run "hwclock --systohc" manually before the reboot, the clock
> >> is OK after reboot. So, this seems to be a systemd bug. I've reported:
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974
> >
> > Michael, since I've seen you reply on this list as well, could you
> > please provide a little more rationale than "we intentionally broke
> > your system" when closing a bug?
>
> I didn't say we intentionally broke your system, I said we intentionally
> removed the hwclock-save units. That's a difference.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755722 if you want
> some background.
>
> In short, your ntp client should ensure that the clock is synced to RTC
> (google for "ntp 11 min mode sync" if you want to know more). For that
> we enable timesyncd by default in systemd.
> If you choose to disable timesyncd and/or use another NTP client, then
> this is not a bug in systemd.
>
> Thanks.

So the answer to my question is that the clock is synced to UTC at start-up, 
so it doesn't need to remember where it was at shut-down.  Is that correct?

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201507031457.16081.lisi.re...@gmail.com

RE: clock losing time after a reboot with HP ZBook G2

[Arno Schuring]

> Date: Fri, 3 Jul 2015 15:38:02 +0200
> From: bi...@debian.org
>
> Am 03.07.2015 um 15:18 schrieb Arno Schuring:
>>
>>> Date: Fri, 3 Jul 2015 15:07:34 +0200
>>> From: vinc...@vinc17.net
>>>
>>> When I run "hwclock --systohc" manually before the reboot, the clock
>>> is OK after reboot. So, this seems to be a systemd bug. I've reported:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974
>>
>> Michael, since I've seen you reply on this list as well, could you
>> please provide a little more rationale than "we intentionally broke
>> your system" when closing a bug?
>
> I didn't say we intentionally broke your system, I said we intentionally
> removed the hwclock-save units. That's a difference.

Without further explanation, there is no difference to the casual
observer. Thank you for the pointer to the rationale. I just wish you
would have included that link in your closing message.


Regards,
Arno

  

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/dub124-w35e610d6fef357015ddf1b8...@phx.gbl

Re: clock losing time after a reboot with HP ZBook G2

[Michael Biebl]

Am 03.07.2015 um 15:18 schrieb Arno Schuring:
> 
>> Date: Fri, 3 Jul 2015 15:07:34 +0200
>> From: vinc...@vinc17.net
>>
>> When I run "hwclock --systohc" manually before the reboot, the clock
>> is OK after reboot. So, this seems to be a systemd bug. I've reported:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974
> 
> Michael, since I've seen you reply on this list as well, could you
> please provide a little more rationale than "we intentionally broke
> your system" when closing a bug?

I didn't say we intentionally broke your system, I said we intentionally
removed the hwclock-save units. That's a difference.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755722 if you want
some background.

In short, your ntp client should ensure that the clock is synced to RTC
(google for "ntp 11 min mode sync" if you want to know more). For that
we enable timesyncd by default in systemd.
If you choose to disable timesyncd and/or use another NTP client, then
this is not a bug in systemd.

Thanks.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: clock losing time after a reboot with HP ZBook G2

[Lisi Reisz]

On Friday 03 July 2015 14:18:50 Arno Schuring wrote:
> > Date: Fri, 3 Jul 2015 15:07:34 +0200
> > From: vinc...@vinc17.net
> >
> > When I run "hwclock --systohc" manually before the reboot, the clock
> > is OK after reboot. So, this seems to be a systemd bug. I've reported:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974
>
> Michael, since I've seen you reply on this list as well, could you
> please provide a little more rationale than "we intentionally broke
> your system" when closing a bug?


That's intentional. We removed the hwclock-save units.


Why???

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201507031435.59708.lisi.re...@gmail.com

RE: clock losing time after a reboot with HP ZBook G2

[Arno Schuring]

> Date: Fri, 3 Jul 2015 15:07:34 +0200
> From: vinc...@vinc17.net
>
> When I run "hwclock --systohc" manually before the reboot, the clock
> is OK after reboot. So, this seems to be a systemd bug. I've reported:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974

Michael, since I've seen you reply on this list as well, could you
please provide a little more rationale than "we intentionally broke
your system" when closing a bug?


Regards,
Arno

  

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/dub124-w162461707e12e0b2036d5fb8...@phx.gbl

Re: clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

On 2015-07-01 02:24:14 +0200, Vincent Lefevre wrote:
> On 2015-06-30 18:15:18 -0400, Gary Dale wrote:
> > Is your cmos battery still providing power?
> 
> The machine is new, so it should. The machine was also constantly on
> AC power.
> 
> > Either that or your hardware clock could be broken or very
> > inaccurate.
> 
> If it loses 15 seconds just the time of a reboot, it's more than an
> inaccuracy.

When I run "hwclock --systohc" manually before the reboot, the clock
is OK after reboot. So, this seems to be a systemd bug. I've reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790974

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150703130734.ga31...@ypig.lip.ens-lyon.fr

Re: clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

On 2015-06-30 18:15:18 -0400, Gary Dale wrote:
> Is your cmos battery still providing power?

The machine is new, so it should. The machine was also constantly on
AC power.

> Either that or your hardware clock could be broken or very
> inaccurate.

If it loses 15 seconds just the time of a reboot, it's more than an
inaccuracy.

> The NTP daemon keeps the system time in sync with whatever time
> source you are using but the hardware clock only gets set when you
> shut down unless you run something to set it more often.

Could there be a bug here?

Note that I do not get always "ntp engine exiting" / "Terminating"
messages in the log. So, there may something broken in the shutdown
procedure. What do you think?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150701002414.ga17...@xvii.vinc17.org

Re: clock losing time after a reboot with HP ZBook G2

[Gary Dale]

On 30/06/15 05:52 PM, Vincent Lefevre wrote:

I've noticed that with my new HP ZBook G2, the clock loses time after
a reboot. Below is the openntpd log without the "peer" messages ("ntp
engine ready" means that this is just after a reboot). What is the
cause? Which part of the software is responsible to sync the RTC?

Jun 29 17:25:43 zira ntpd[846]: ntp engine ready
Jun 29 17:25:43 zira kernel: [   36.730060] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:27:04 zira ntpd[837]: adjusting local clock by 13.466645s
Jun 29 17:29:18 zira ntpd[837]: adjusting local clock by 13.399644s
Jun 29 17:33:04 zira ntpd[837]: adjusting local clock by 13.286723s
Jun 29 17:36:48 zira ntpd[837]: adjusting local clock by 13.174479s
Jun 29 17:37:21 zira ntpd[837]: adjusting local clock by 13.157979s
Jun 29 17:39:55 zira ntpd[837]: adjusting local clock by 13.080871s
Jun 29 17:44:07 zira ntpd[837]: adjusting local clock by 12.954863s
Jun 29 17:46:49 zira ntpd[837]: adjusting local clock by 12.873868s
Jun 29 17:46:51 zira ntpd[846]: ntp engine exiting
Jun 29 17:46:51 zira ntpd[837]: Terminating
Jun 29 17:47:38 zira ntpd[871]: constraint certificate verification turned off
Jun 29 17:47:38 zira ntpd[871]: ntp engine ready
Jun 29 17:47:38 zira kernel: [   31.495426] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:48:57 zira ntpd[846]: adjusting local clock by 13.645922s
Jun 29 17:52:05 zira ntpd[846]: adjusting local clock by 13.551856s
Jun 29 17:54:48 zira ntpd[846]: adjusting local clock by 13.470787s
Jun 29 17:57:32 zira ntpd[846]: adjusting local clock by 13.388841s
Jun 29 17:59:40 zira ntpd[846]: adjusting local clock by 13.324690s
Jun 29 18:01:13 zira ntpd[846]: adjusting local clock by 13.277861s
Jun 29 18:05:35 zira ntpd[846]: adjusting local clock by 13.146952s
Jun 29 18:09:56 zira ntpd[846]: adjusting local clock by 13.016189s
Jun 29 18:12:04 zira ntpd[846]: adjusting local clock by 12.952223s
Jun 29 18:13:11 zira ntpd[846]: adjusting local clock by 12.918980s
[...]
Jun 30 01:17:06 zira ntpd[846]: adjusting local clock by 0.198699s
Jun 30 01:21:28 zira ntpd[846]: adjusting local clock by 0.067428s
Jun 30 01:22:00 zira ntpd[846]: adjusting local clock by 0.051427s
Jun 30 01:22:31 zira ntpd[846]: adjusting local clock by 0.035614s
Jun 30 01:25:14 zira ntpd[871]: clock is now synced
Jun 30 01:48:24 zira ntpd[846]: adjusting clock frequency by -0.050992 to 
-21.227978ppm
Jun 30 02:09:09 zira ntpd[846]: adjusting clock frequency by -0.269145 to 
-21.497112ppm
Jun 30 02:25:43 zira ntpd[846]: adjusting clock frequency by -0.635475 to 
-22.132576ppm
Jun 30 10:52:13 zira ntpd[846]: adjusting clock frequency by 0.833955 to 
-21.298614ppm
Jun 30 14:12:02 zira ntpd[871]: ntp engine exiting
Jun 30 14:12:02 zira ntpd[846]: Terminating
Jun 30 14:12:35 zira ntpd[801]: constraint certificate verification turned off
Jun 30 14:12:35 zira ntpd[801]: ntp engine ready
Jun 30 14:12:35 zira kernel: [   35.718822] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:12:35 zira ntpd[801]: reply from 37.187.56.220: not synced (alarm), 
next query 3166s
Jun 30 14:13:54 zira ntpd[790]: adjusting local clock by 15.278347s
Jun 30 14:15:00 zira ntpd[790]: adjusting local clock by 15.245347s
Jun 30 14:15:25 zira ntpd[801]: ntp engine exiting
Jun 30 14:15:25 zira ntpd[790]: Terminating
Jun 30 14:16:06 zira ntpd[862]: constraint certificate verification turned off
Jun 30 14:16:06 zira ntpd[862]: ntp engine ready
Jun 30 14:16:06 zira kernel: [   28.588667] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:16:06 zira ntpd[862]: reply from 37.187.56.220: not synced (alarm), 
next query 3234s
Jun 30 14:17:28 zira ntpd[845]: adjusting local clock by 15.567251s
Jun 30 14:21:45 zira ntpd[845]: adjusting local clock by 15.439340s
Jun 30 14:22:36 zira ntpd[845]: adjusting local clock by 15.413840s
Jun 30 14:24:12 zira ntpd[845]: adjusting local clock by 15.365855s
Jun 30 14:26:53 zira ntpd[845]: adjusting local clock by 15.285121s
Jun 30 14:29:00 zira ntpd[845]: adjusting local clock by 15.221573s
Jun 30 14:31:42 zira ntpd[845]: adjusting local clock by 15.140805s
Jun 30 14:32:49 zira ntpd[845]: adjusting local clock by 15.106892s
Jun 30 14:36:57 zira ntpd[845]: adjusting local clock by 14.982979s
Jun 30 14:38:36 zira ntpd[845]: adjusting local clock by 14.933478s
Jun 30 14:42:16 zira ntpd[845]: adjusting local clock by 14.823588s
Jun 30 14:46:31 zira ntpd[845]: adjusting local clock by 14.695910s
Jun 30 14:50:12 zira ntpd[845]: adjusting local clock by 14.585502s
Jun 30 14:54:01 zira ntpd[845]: adjusting local clock by 14.470910s
Jun 30 14:55:33 zira ntpd[845]: adjusting local clock by 14.425103s
Jun 30 14:58:44 zira ntpd[845]: adjusting local clock by 14.329479s
Jun 30 15:00:54 zira ntpd[845]: adjusting local clock by 14.264600s
Jun 30 15:01:28 zira ntpd[845]: adjusting local clock by 14.247518s
Jun 30 15:02:38 zir

clock losing time after a reboot with HP ZBook G2

[Vincent Lefevre]

I've noticed that with my new HP ZBook G2, the clock loses time after
a reboot. Below is the openntpd log without the "peer" messages ("ntp
engine ready" means that this is just after a reboot). What is the
cause? Which part of the software is responsible to sync the RTC?

Jun 29 17:25:43 zira ntpd[846]: ntp engine ready
Jun 29 17:25:43 zira kernel: [   36.730060] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:27:04 zira ntpd[837]: adjusting local clock by 13.466645s
Jun 29 17:29:18 zira ntpd[837]: adjusting local clock by 13.399644s
Jun 29 17:33:04 zira ntpd[837]: adjusting local clock by 13.286723s
Jun 29 17:36:48 zira ntpd[837]: adjusting local clock by 13.174479s
Jun 29 17:37:21 zira ntpd[837]: adjusting local clock by 13.157979s
Jun 29 17:39:55 zira ntpd[837]: adjusting local clock by 13.080871s
Jun 29 17:44:07 zira ntpd[837]: adjusting local clock by 12.954863s
Jun 29 17:46:49 zira ntpd[837]: adjusting local clock by 12.873868s
Jun 29 17:46:51 zira ntpd[846]: ntp engine exiting
Jun 29 17:46:51 zira ntpd[837]: Terminating
Jun 29 17:47:38 zira ntpd[871]: constraint certificate verification turned off
Jun 29 17:47:38 zira ntpd[871]: ntp engine ready
Jun 29 17:47:38 zira kernel: [   31.495426] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 29 17:48:57 zira ntpd[846]: adjusting local clock by 13.645922s
Jun 29 17:52:05 zira ntpd[846]: adjusting local clock by 13.551856s
Jun 29 17:54:48 zira ntpd[846]: adjusting local clock by 13.470787s
Jun 29 17:57:32 zira ntpd[846]: adjusting local clock by 13.388841s
Jun 29 17:59:40 zira ntpd[846]: adjusting local clock by 13.324690s
Jun 29 18:01:13 zira ntpd[846]: adjusting local clock by 13.277861s
Jun 29 18:05:35 zira ntpd[846]: adjusting local clock by 13.146952s
Jun 29 18:09:56 zira ntpd[846]: adjusting local clock by 13.016189s
Jun 29 18:12:04 zira ntpd[846]: adjusting local clock by 12.952223s
Jun 29 18:13:11 zira ntpd[846]: adjusting local clock by 12.918980s
[...]
Jun 30 01:17:06 zira ntpd[846]: adjusting local clock by 0.198699s
Jun 30 01:21:28 zira ntpd[846]: adjusting local clock by 0.067428s
Jun 30 01:22:00 zira ntpd[846]: adjusting local clock by 0.051427s
Jun 30 01:22:31 zira ntpd[846]: adjusting local clock by 0.035614s
Jun 30 01:25:14 zira ntpd[871]: clock is now synced
Jun 30 01:48:24 zira ntpd[846]: adjusting clock frequency by -0.050992 to 
-21.227978ppm
Jun 30 02:09:09 zira ntpd[846]: adjusting clock frequency by -0.269145 to 
-21.497112ppm
Jun 30 02:25:43 zira ntpd[846]: adjusting clock frequency by -0.635475 to 
-22.132576ppm
Jun 30 10:52:13 zira ntpd[846]: adjusting clock frequency by 0.833955 to 
-21.298614ppm
Jun 30 14:12:02 zira ntpd[871]: ntp engine exiting
Jun 30 14:12:02 zira ntpd[846]: Terminating
Jun 30 14:12:35 zira ntpd[801]: constraint certificate verification turned off
Jun 30 14:12:35 zira ntpd[801]: ntp engine ready
Jun 30 14:12:35 zira kernel: [   35.718822] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:12:35 zira ntpd[801]: reply from 37.187.56.220: not synced (alarm), 
next query 3166s
Jun 30 14:13:54 zira ntpd[790]: adjusting local clock by 15.278347s
Jun 30 14:15:00 zira ntpd[790]: adjusting local clock by 15.245347s
Jun 30 14:15:25 zira ntpd[801]: ntp engine exiting
Jun 30 14:15:25 zira ntpd[790]: Terminating
Jun 30 14:16:06 zira ntpd[862]: constraint certificate verification turned off
Jun 30 14:16:06 zira ntpd[862]: ntp engine ready
Jun 30 14:16:06 zira kernel: [   28.588667] warning: process `ntpd' used the 
deprecated sysctl system call with 1.40.6.
Jun 30 14:16:06 zira ntpd[862]: reply from 37.187.56.220: not synced (alarm), 
next query 3234s
Jun 30 14:17:28 zira ntpd[845]: adjusting local clock by 15.567251s
Jun 30 14:21:45 zira ntpd[845]: adjusting local clock by 15.439340s
Jun 30 14:22:36 zira ntpd[845]: adjusting local clock by 15.413840s
Jun 30 14:24:12 zira ntpd[845]: adjusting local clock by 15.365855s
Jun 30 14:26:53 zira ntpd[845]: adjusting local clock by 15.285121s
Jun 30 14:29:00 zira ntpd[845]: adjusting local clock by 15.221573s
Jun 30 14:31:42 zira ntpd[845]: adjusting local clock by 15.140805s
Jun 30 14:32:49 zira ntpd[845]: adjusting local clock by 15.106892s
Jun 30 14:36:57 zira ntpd[845]: adjusting local clock by 14.982979s
Jun 30 14:38:36 zira ntpd[845]: adjusting local clock by 14.933478s
Jun 30 14:42:16 zira ntpd[845]: adjusting local clock by 14.823588s
Jun 30 14:46:31 zira ntpd[845]: adjusting local clock by 14.695910s
Jun 30 14:50:12 zira ntpd[845]: adjusting local clock by 14.585502s
Jun 30 14:54:01 zira ntpd[845]: adjusting local clock by 14.470910s
Jun 30 14:55:33 zira ntpd[845]: adjusting local clock by 14.425103s
Jun 30 14:58:44 zira ntpd[845]: adjusting local clock by 14.329479s
Jun 30 15:00:54 zira ntpd[845]: adjusting local clock by 14.264600s
Jun 30 15:01:28 zira ntpd[845]: adjusting local clock by 14.247518s
Jun 30 15:02:38 zira ntpd[862]: constraint certificate verificatio

Re: Losing time !

[Karsten M. Self]

on Sun, Mar 17, 2002, Greg Murphy ([EMAIL PROTECTED]) wrote:
> Greetings,
> 
> My computer for some reason seems to be losing time at a rate of about 20 
> minutes per 10-15 hours. I was under the impression that linux keeps track of 

In addition to the hwclock adjustments, you may want to replace the
mobo battery as this is what *drives* the CPU clock.  This could account
for the time slippage.

Peace.

-- 
Karsten M. Self   http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?  
   Keep software free. Oppose the CBDTPA. Kill S.2048 dead. 
   http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html


pgpIBMg4wzGU4.pgp
Description: PGP signature

Re: Losing time !

[Crispin Wellington]

On Mon, 2002-03-18 at 06:05, Greg Murphy wrote:
> Greetings,
> 
> My computer for some reason seems to be losing time at a rate of about 20 
> minutes per 10-15 hours. I was under the impression that linux keeps track of 
> the time from clock cycles. I have not rebooted my machine in a week, so if 
> that previous assumption is correct, then that would rule out the cmos 
> battery. What could cause this loss of time. The only thing that has been 
> slightly different that I can think that might could cause it is that lately 
> I have been constantly running some intensive tasks reniced to +19. Could 
> something like that cause this problem, or is my problem elsewhere? Any 
> ideas? Thanks.

What kernel are you using? What motherboard?

2.4.18 has time keeping problems on a via chipset motherboard.

Kind Regards
Crispin

Re: Losing time !

[Rob Weir]

On Sun, Mar 17, 2002 at 04:05:55PM -0600, Greg Murphy wrote:
> Greetings,
> 
> My computer for some reason seems to be losing time at a rate of about 20 
> minutes per 10-15 hours. I was under the impression that linux keeps track of 
> the time from clock cycles. I have not rebooted my machine in a week, so if 
> that previous assumption is correct, then that would rule out the cmos 
> battery. What could cause this loss of time. The only thing that has been 
> slightly different that I can think that might could cause it is that lately 
> I have been constantly running some intensive tasks reniced to +19. Could 
> something like that cause this problem, or is my problem elsewhere? Any 
> ideas? Thanks.

Like all the other repliee's (is that a word?) so far, I can't say I
have much idea what's going wrong.  The kernel is supposed to keep
track of the clock by itself, effectively by counting CPU clock
cycles.  The only thing that I can think of is that I once read about
when you have the kernel getting interrupted a lot, the clock doesn't
get updated regularily enough, so the kernel loses time.  Have you
looked into this?  Try running procinfo -n1, and having a look at the irq
listings; maybe one of them will be rising rapidly, indictaing a lot
of interrupts.
Anyhow, it's a though

-rob

-- 
I did not vote for the Australian government.


pgprOMqnq2yel.pgp
Description: PGP signature

Re: Losing time !

[Dave Sherohman]

On Sun, Mar 17, 2002 at 11:03:17PM -0500, Jerome Acks Jr wrote:
> I have no idea about why your computer would be losing time. You could set up 
> a
> Network Time Protocol daemon (for example: nptd)  to syncronize your clock 
> with internet time servers. You probably have to reset your clock first to do
> this.

Note that ntpdate is probably your best option for getting the time
set correctly to start with.

-- 
When we reduce our own liberties to stop terrorism, the terrorists
have already won. - reverius

Innocence is no protection when governments go bad. - Tom Swiss

Re: Losing time !

[Jerome Acks Jr]

On Sun, Mar 17, 2002 at 04:05:55PM -0600, Greg Murphy wrote:
> Greetings,
> 
> My computer for some reason seems to be losing time at a rate of about 20 
> minutes per 10-15 hours. I was under the impression that linux keeps track of 
> the time from clock cycles. I have not rebooted my machine in a week, so if 
> that previous assumption is correct, then that would rule out the cmos 
> battery. What could cause this loss of time. The only thing that has been 
> slightly different that I can think that might could cause it is that lately 
> I have been constantly running some intensive tasks reniced to +19. Could 
> something like that cause this problem, or is my problem elsewhere? Any 
> ideas? Thanks.

I have no idea about why your computer would be losing time. You could set up a
Network Time Protocol daemon (for example: nptd)  to syncronize your clock 
with internet time servers. You probably have to reset your clock first to do
this.

-- 
Jerome


pgpwnpX0OKve7.pgp
Description: PGP signature

Re: Losing time !

[Steffen Evers]

On Sun, Mar 17, 2002 at 16:05, Greg Murphy wrote:
> My computer for some reason seems to be losing time at a rate of about 20 
> minutes per 10-15 hours. I was under the impression that linux keeps track of 
> the time from clock cycles. I have not rebooted my machine in a week, so if 
> that previous assumption is correct, then that would rule out the cmos 
> battery. What could cause this loss of time. The only thing that has been 
> slightly different that I can think that might could cause it is that lately 
> I have been constantly running some intensive tasks reniced to +19. Could 
> something like that cause this problem, or is my problem elsewhere? Any 
> ideas? Thanks.
Maybe you have a bad time adjustment. I had a similar problem once that
was caused by that. Have a look at 'man hwclock' and check /etc/adjtime.

Hope that helps.

Bye, Steffen

Losing time !

[Greg Murphy]

Greetings,

My computer for some reason seems to be losing time at a rate of about 20 
minutes per 10-15 hours. I was under the impression that linux keeps track of 
the time from clock cycles. I have not rebooted my machine in a week, so if 
that previous assumption is correct, then that would rule out the cmos 
battery. What could cause this loss of time. The only thing that has been 
slightly different that I can think that might could cause it is that lately 
I have been constantly running some intensive tasks reniced to +19. Could 
something like that cause this problem, or is my problem elsewhere? Any 
ideas? Thanks.

-Greg Murphy

uptime losing time?

[Matt Emmett]

Hello all,

Does noflushd affect uptime?  I'm a little puzzeled as to why my
uptime says 2:16 when in fact the machine has been on for about 2
weeks.

Any insights?

Thanks,
Matt

RE: Losing Time SOLVED

[Bryan Scaringe]

Opps,
I figured it out. Turns out that I had a lousy
/etc/adjtime file.  This file is used and set by "hwclock"
to track drift (inaccuracy) in the HW clock.  Turns out
that I must have run "hwclock" twice in quick succession
durring a brief peroid of major drift in the clock.
"hwclock" assumed my HW clock always did this, and built
a adjtime file to compensate.  After clearing that file,
doing an "rdate ntp2.usno.navy.mil; hwclock --systohc --utc"
followed by a reboot (to see if this all works) shows
a MUCH more realistic time.

Bryan

Losing Time

[Bryan Scaringe]

This is really odd.
I have a dual boot system.  I set the time by doing:
  rdate ; hwclock --settohc --utc
...where  is one of the naval time servers. I've been
using ntp2.usno.navy.mil.

This seems to work fine.
  rdate -p ; date
show the same time.  the time is set in the CMOS clock.
I checked this during a reboot.  Here's the problem:

If I shutdown, and either turn off the machine, or reboot to
windows, when I come back, the clock will be behind exactly
the amount of time between the shutdown, and the reboot.
That is:  If I shutdown Linux, eat dinner, and come back
1 hour and 17 minutes later and turn on the machine, the clock
will be 1 hour and 17 minutes ahead!, using:
rdate -p ; date

My /etc/timezone is set to US/Eastern.
HW clock is set to UTC.
My /etc/defaults/rcS file has UTC=yes.

Any help would be appreciated!

Bryan