Time and Date drifting

[WizardStan]

I can suggest it.

 

[porg]

But before upgrading anything into the firmware, the issue needs to be fully resolved first:

3) In the unmodified state of op_power.sh the TZ loss happens not at wake-from-standby but after-bootup! I dunno the init process on the Pandora. Some-one who knows, please investigate where the HW clock looses its UTC zone association and changes to local.

 

 

[WizardStan]

The bootup is completely different from the wakeup process.

 

[porg]

The bootup is completely different from the wakeup process.

Someone, who knows the bootup process, please investigate where the TZ loss happens in this process.

Or how TZ are even supposed to work by design on the hw/sw-clock of the Pandora.

 

[Trip]

Open the file "/usr/pandora/scripts/op_power.sh" with your preferred editor as super user (ie, "sudo vi ..." or "sudo mousepad ...")


At line 219, insert "hwclock -s", such that it reads


fi
hwclock -s
display_on
Time drift disappears.

This works a treat for me. How come it's not there by default?

 

[bsp]

from what I've witnessed so far the HW clock does not tick on correctly when the system is in suspend.

according to "hwclock" the time is now "Tue Oct 15 12:04:42 2013" while in actual time it is already October the 17th.

I have the Pandora for little more than a month now and the battery never went out of juice.

It was not until ~2 weeks ago (when I learnt about the suspend mode (flick power switch)) that I started to experience time drift (before that I simply closed the lid .. bad idea for battery life).

"hwclock -s" is no solution here since that one simply sets the system time to the hardware clock.

possible workaround: synchronize the clock to an NTP server and add some code to op_wifi.sh (=> as soon as inet connection is available, do the NTP sync)

I do not use any over or underclocking and have rebooted the system countless times during the past month.

 

[Trip]

from what I've witnessed so far the HW clock does not tick on correctly when the system is in suspend.


according to "hwclock" the time is now "Tue Oct 15 12:04:42 2013" while in actual time it is already October the 17th.


I have the Pandora for little more than a month now and the battery never went out of juice.


It was not until ~2 weeks ago (when I learnt about the suspend mode (flick power switch)) that I started to experience time drift (before that I simply closed the lid .. bad idea for battery life).


"hwclock -s" is no solution here since that one simply sets the system time to the hardware clock.

Ah I see.

I had the same problem when my clock was out of sync before. Both the hardware clock and the system clock were an hour behind even though I hadn't run out of juice or turned my Pandora off since I got it.

This is a bit of a pain if you want to use bittorrent sync as it wont sync folders if both computers times aren't the same

 

[WizardStan]

according to "hwclock" the time is now "Tue Oct 15 12:04:42 2013" while in actual time it is already October the 17th.

Are you sure you haven't rebooted? This is the problem I've had numerous times: when it goes through a reboot for any reason, the hardware clock is set to the system time. The system clock tends to drift when suspended, and then if a reboot happens that drifted time gets set to the hardware clock. Hence why I added the "hwclock -s" which ensures the hardware clock (which I've never seen drift on its own) gets pushed to the system clock. Trip and I aren't the only two who have solved our drift problems with the hwclock fix, either; you're the first person to say it doesn't work for them.

 

[porg]

I did intensive test on this issue, and published my findings in #15.

In the successive posts I also discussed the effects of possible fixes, and what must be done to fix this for the OS.

But I am not sure if a dev ever picked that up.

 

[bsp]

when it goes through a reboot for any reason, the hardware clock is set to the system time

interesting, I'd have expected that during reboot, the system time is set to the hw clock !?

I just got home, the Pandora was in suspend during the night and the office hours.

Here's how the clock changed:

systime: 12:06 oct 15th, actual time  0:40 october 18th


systime:  1:56 oct 16th, actual time 14:22 october 18th  (systime delta=13:30h, actual delta=13:42h)

(when I said October 17th yesterday I meant 18th btw)

After the first 3 days with my Pandora, I noticed that the clock had drifted ~10 minutes (I rebooted everyday since I did not know about the suspend feature).

The system clock tends to drift when suspended, and then if a reboot happens that drifted time gets set to the hardware clock

ok, that might explain it then. During the past month I rebooted quite a lot of times (often involuntarily)

EDIT: Just found this thread http://boards.openpandora.org/index.php/topic/4613-solved-who-has-clock-issues/

In that thread, CatPhoenix said

Just a random aside. I've noticed that if I ever have to do a hard reset of the pandora (pandora button and flip the power switch or remove the pandora battery) when the pandora is in some sort of state that is locked or something similar, that the current date & time will be set back to when the pandora was first turned on in that session.

So, if you had to do anything like that, that will though the time way off.

had to do that a couple of times. along with what WizardStan said, this probably explains the "extreme" time drift on my Pandora.

 

[notaz]

I think I saw some messing with clocks in some boot script, I can remove that if it helps.

About time drifting in suspend (if it happens), I don't really have many ideas how to debug or fix that.

 

[WizardStan]

The simplest fix is to load the hardware clock back to system when it resumes, optionally saving the system clock to the hardware clock when it goes into suspend.

It is a difficult thing to debug. In my own experiments it only happens when suspended for more than 24 hours. Since this requires 24 hours of downtime between tests it's pretty difficult to actually perform a lot of them.

 

[bsp]

I think I saw some messing with clocks in some boot script, I can remove that if it helps.

I just took a quick look -- the bootscripts seem to be ok.

The system clock is restored from the hwclock during boot (see "/etc/rcS.d/S55bootmisc.sh" which calls "/etc/init.d/hwclock.sh start").

During shutdown the system clock is written to the hwclock. This might be a problem because of the suspend drift. Maybe the proper solution would be to remove this and instead update the hwclock immediately after the date/time is set via "Settings->Date and Time" in XFCE ?

Now I wonder why hard resetting the Pandora would skew the system time ..? (I have not verified that, it was another user's theory).

Regarding the suspend drift: I had the Pandora in suspend for the past 4 hours and the system clock drifted by 4 seconds (verified via "date" and "hwclock" immediately after resume). Interestingly, running date/hwclock again a few minutes later only showed a 2 seconds drift. Another few minutes later it's just 1 second so it somehow fixes itself ?!

hmm..well, who has the time to fix these things.. (personally I'll probably just run "ntpdate  -b pool.ntp.org && hwclock -w" every now and then..maybe every 'nth' time op_wifi.sh connects to wlan/inet)

The simplest fix is to load the hardware clock back to system when it resumes, optionally saving the system clock to the hardware clock when it goes into suspend.

that's probably not a bad idea. I'll try that (added a new line "hwclock -s" after line 278 in op_power.sh, let's see how that works out)

ah, on the topic of time (in general): I recently wondered whether there is any way to make the Pandora auto-resume at a certain alarm time. I'd like to use it as a glorified alarm clock

 

[WizardStan]

ah, on the topic of time (in general): I recently wondered whether there is any way to make the Pandora auto-resume at a certain alarm time. I'd like to use it as a glorified alarm clock

Yes, actually. The TWL chip (which is responsible for the charging, the clock, the power control, bunch of other stuff) has a wake-on-alarm feature: when set it will trigger the same interrupt it gets when you flip the power switch or insert the power cable: ie, it will turn on Check /sys/class/rtc/rtc0/wakealarm

I believe you need to echo a unix timestamp into that file, but I can't remember exactly, it's been a long time since I researched it. Let me check... yup, exactly that.

sudo su
echo 1382025600 > /sys/class/rtc/rtc0/wakealarm
*power off*
*Turns on at 16:00*

This should work from both suspend as well as completely off. Noting, of course, that powering on will go through the full boot process.

 

[bsp]

thanks, that was very helpful.

bad news is that it does not work on my Pandora (*sniff*)

(I followed your exact instructions, except for the timestamp, of course, then I wrote the test_alarm script)

I tried both the original SZ1.55 and the (slightly modified) c64_tools 3.2.45 kernel (on an 1Ghz Pandora).

test_alarm.sh:


NOW=`date +%s`

THEN=`expr $NOW + 30`

echo " NOW=$NOW"
echo "THEN=$THEN"

echo $THEN > /sys/class/rtc/rtc0/wakealarm

#/usr/pandora/scripts/op_power.sh suspend_real
/usr/pandora/scripts/op_power.sh 2

run with:

. ./test_alarm.sh

 

[FBnil]

Same here


cat /proc/driver/rtc

shows no pending alarms....

edit, sources: https://www.linux.com/learn/docs/672849-wake-up-linux-with-an-rtc-alarm-clock

and to get a good epoch:

LATER=`date --date="2013-10-18 00:22:00" +%s`

LATER=`date -d '+ 3 minutes' +%s`

Also tried rtcwake, as described in: http://ubuntuforums.org/showthread.php?t=1780299 

 

[WizardStan]

Is your hwclock in UTC or local time? I have mine synced to local time for some reason, so that may have made a difference. If yours is in UTC then you'll need to account for time zone.

 

[notaz]

In the mean time I've put the op_power.sh modification to main firmware (due to numerous success reports), also changed the init script. Would be nice if someone ras OS update and tested if I got it all right.

 

[bsp]

@WizardStan: I tried setting it to UTC ("hwclock -wu") but to no avail

@notaz: you mean the "hwclock -s" line that WizardStan suggested ? seems to work fine here, too.

@FBnil: exactly, no pending alarms :/

modified the test script:


NOW=`date -u +%s`
THEN=`expr $NOW + 30`

echo " NOW=$NOW"
echo "THEN=$THEN"

echo 0 > /sys/class/rtc/rtc0/wakealarm

sleep 1

#echo `date '+%s' -d '+15 seconds'` > /sys/class/rtc/rtc0/wakealarm

echo $THEN > /sys/class/rtc/rtc0/wakealarm

cat /proc/driver/rtc

echo "alarm scheduled at:"
cat /sys/class/rtc/rtc0/wakealarm
echo "."

#sleep 2

#/usr/pandora/scripts/op_power.sh suspend_real
#/usr/pandora/scripts/op_power.sh 2

output is:


pandora:/home/bsp# . ./test_alarm.sh
NOW=1382052546
THEN=1382052576
rtc_time : 01:29:07
rtc_date : 2013-10-18
alrm_time : 01:34:07
alrm_date : 2013-10-18
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
alarm scheduled at:
.

according to the article (https://www.linux.com/learn/docs/672849-wake-up-linux-with-an-rtc-alarm-clock) "cat wakealarm" should return sth.

it also makes no difference what alarm time is set, it's always 5 minutes into the future

p.s.:

alarm_IRQ : no
alrm_pending : no

does not sound so good ?!

 

[WizardStan]

That's what happens when you set a time that has already passed.

My output looks like this:

$ hwclock && date
Thu Oct 17 20:07:55 2013 0.000000 seconds
Thu Oct 17 20:07:55 EDT 2013
So when I set an alarm of 1382040600, 20:10, it turns on when expected.If your dates are different by timezone you need to account for that.

@notaz, I'm pretty sure it should be "hwclock -su", I think I messed with stuff and made this change at some point in time that isn't standard. I've been saying I need to reflash to stock for months because of all the stuff I've mashed up in here making it hard to know what's working like it should or not.