Bug 3744 - APMD losing time
APMD losing time
Status: CLOSED DUPLICATE of bug 6052
Product: Red Hat Linux
Classification: Retired
Component: apmd (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-26 12:20 EDT by Piet E Barber
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-10-18 10:27:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Piet E Barber 1999-06-26 12:20:02 EDT
I realize that there was already an errata notice
about APMd losing time.

I syncronized my clock using NTP.

I then left the computer for a while.

I came back, and the clock was off by 30 minutes.

[root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu
26 Jun 09:44:38 ntpdate[1108]: step time server 131.216.18.4
offset -76.758548 sec
[root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu
26 Jun 09:44:41 ntpdate[1109]: adjust time server
131.216.18.4 offset 0.006088 sec
[root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu
26 Jun 09:44:44 ntpdate[1110]: adjust time server
131.216.18.4 offset 0.003191 sec
[root@slacker pietb]# date
Sat Jun 26 09:49:10 EDT 1999

[went out to breakfast, came back]

[root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu
26 Jun 12:11:52 ntpdate[1198]: step time server 131.216.18.4
offset 2040.635256 sec
[root@slacker pietb]#

[root@slacker rc3.d]# rpm -q apmd
apmd-3.0beta5-8

Here's /var/log/messages


Jun 26 09:02:33 slacker syslogd 1.3-3: restart.
Jun 26 06:46:09 slacker apmd[128]: Resume after
4294967292:4294967295:4294967239 (-1% unknown)
Jun 26 07:30:23 slacker apmd[128]: Resume after 00:44:14
(-1% unknown)
Jun 26 11:30:23 slacker apmd[128]: Resume after 04:00:00
(-1% unknown)
Jun 26 11:31:08 slacker PAM_pwdb[1171]: (su) session opened
for user root by pietb(uid=500)


I haven't verified that the clock isn't busted, but I don't
get the time warp in Windows.
Comment 1 Jeff Johnson 1999-06-26 22:38:59 EDT
You can't expect xntpd -- a program that requires a running cpu
to keep track of time -- if you run another program apmd that stops
the cpu from running.

You don't get the time warp in Windows because Windows just
reads the battery backed up hardware clock and uses that as
the system time. You also don't get a system time on windows that
is usually within 10 ms of a primary reference clock on windows
either; that's the funxtion that xntpd performs that requires a
running cpu.
Comment 2 Piet E Barber 1999-06-27 22:50:59 EDT
Umm.  Perhaps you misunderstood.

After screen blanks out from APMd, I lose an half an hour!  More than
once!!  With striking regularity!

The ntpdate shows how much drift is being caused by the apm daemon.
The example I showed had 2000 seconds.   THAT'S SIGNIFICANT!

The clock isn't busted, I just spent hours in 95, and no time drift.

it apmd.

I know it.

I'm re-opening the bug.
Comment 3 Piet E Barber 1999-06-27 22:51:59 EDT
Umm.  Perhaps you misunderstood.

After screen blanks out from APMd, I lose an half an hour!  More than
once!!  With striking regularity!

The ntpdate shows how much drift is being caused by the apm daemon.
The example I showed had 2000 seconds.   THAT'S SIGNIFICANT!

The clock isn't busted, I just spent hours in 95, and no time drift.

it apmd.

I know it.

I'm re-opening the bug.
Comment 4 Yaron Minsky 1999-08-28 12:53:59 EDT
I have similar APMD problems, and I'm not running xntpd.

Here's what I've found.  Sometimes, when my laptop wakes up, the time
is set wrong.  Not reliably, tough.  I store my time in real time (not
UTC), and there seems to be some problems with that.  The following is
the output of repeated executions of "date" when I put the machine to
sleep and then wake it up.

snapdragon: init.d $ while true; sleep 1; do date; done
Sat Aug 28 12:46:38 PM EDT
Sat Aug 28 12:46:39 PM EDT
Sat Aug 28 12:46:40 PM EDT
Sat Aug 28 12:46:41 PM EDT
Sat Aug 28 12:46:42 PM EDT
Sat Aug 28 12:46:43 PM EDT
Sat Aug 28 12:46:44 PM EDT
Sat Aug 28  8:47:16 AM EDT
Sat Aug 28  8:47:18 AM EDT
Sat Aug 28 12:47:18 PM EDT
Sat Aug 28 12:47:19 PM EDT


In other words, when it wakes up, it temporarily restores the time as
if it was stored in UTC, and then immediatly (within 2 seconds)
switches it back.  THis is the "good" outcome, since the date finally
reaches the right value.  But it's still weird.  And sometimes, I'm
not sure why or when, I leave it for a while and find it set on the
wrong time, that is, set to the time it would be if I stored the date
in UTC.

This is really a bit weird.  I fixed a similar problem on my desktop
some time ago by changing /etc/sysconfig/clock so that instead of
reading:

UTC="yes"
ARC=false

it read:

UTC=true
ARC=false

That fixed some problems, but I did the same thing on my laptop to no
avail.

I'm running Linux on a Dell Solo 2500.  (lovely machine, btw.;)
Comment 5 Jeff Johnson 1999-08-28 17:47:59 EDT
Running APM and xntp makes no sense since the xntpd requires
periodic time stamps every 1-60 seconds while apmd turns off
the cpu. Run ntpdate every 5 mins from cron to synchronize with a
server if you wish to work around the problem.
Comment 6 Yaron Minsky 1999-08-29 10:28:59 EDT
I'm not sure if the above response from jbj@redhat is to my post, but
let me reiterate: I am NOT using xntpd.  I find similar problems even
so.  So whether or not it's a good idea to use xntpd on a laptop is
irrelevant.

------- Additional Comments From   08/30/99 10:01 -------
After reading recent comments, I went in and recompiled my kernel --
I set the setting that time is local instead of UTC (it's in the Power
Management settings section), and now every time the apm daemon
launches, I don't lose 4 hours anymore.

That was it, you see.  When apm started, I would be losing around
14,400 seconds -- about 4 hours. It never made much sense to me as to
why I was losing about the same amount of time with each apm suspend.

The apm daemon *should* be able to figure out the difference between
which mode the system is in, without requiring a recompilation of the
kernel.
Comment 7 Bill Nottingham 1999-10-18 10:27:59 EDT
*** This bug has been marked as a duplicate of 6052 ***

Note You need to log in before you can comment on or make changes to this bug.