Time drift after hibernate-ram

[miroR]

Initial title: Time drift after hibernate-ram
---
After resuming from:

Code: Select all

# hibernate-ram

I noticed that the clock in that system was running fast.

I decided to measure how fast.

I set it to correct time:

Code: Select all

# date -s '10/06/15 13:07'

and compared it to the system which clock runs correctly (they are clones of each other, as per:

Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-9 ... ml#7613044

)
First, this system which runs correctly is:

Code: Select all

# uptime
 13:28:29 up 2 days,  4:44,  2 users,  load average: 0.01, 0.03, 0.05
#

and has not been hibernated in any fashion since I booted it from unplugged-from-mains turned-off state.

So, both the systems were exact (almost) to the second at:

Code: Select all

10/06/15 13:07

I waited 1000 seconds, and the time on the correct clock system was now:

Code: Select all

10/06/15 13:23:22

while the time on the speedy system was:

Code: Select all

10/06/15 13:23:46

Give or take a second or two in the name of the margin of error, not more.

Before I post this, I want to restart the machine, and see how its clock will behave. Postponing that, the machine is busy for a little longer.

Later. For some reason, upon reboot, without starting the X (prior to startx, I have kind of minimal no-poetterware installation:

Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-t-992146.html

)

, the difference is:

Code: Select all

10/06/15 14:04:02 # correct system clock

versus

Code: Select all

10/06/15 13:20:35 # the previously show to be fast system clock

It could be some functionality in my MBO going wry, but the problems that I reported on:

Syslog-ng from Delay Logging to BrokenPipe/no Logging
https://forums.gentoo.org/viewtopic-t-1001994.html

were also reported by other users:

app-admin/syslog-ng-3.6.2: scary time stamp jumps
https://bugs.gentoo.org/show_bug.cgi?id=533328

Kernel log message time drift #121
https://github.com/balabit/syslog-ng/issues/121

So I'll simply adjust the clock to the correcly timed system.

Code: Select all

# date -s '10/06/15 14:10'

The clocks on both machines now, after 1000 seconds, show the same time (with the 1-2 seconds margin of error, not more; it's a human starting the date command to see the time: myself; haven't yet turned into a flawless cyborg, would take a few more centuries, and I don't have that much time ).

However, remember that I said: "upon reboot, without starting the X".

I will now execute startx as user, and see if the clock start misbehaving again.

Not at first. At first means after maybe one minute, give or take (I haven't
found time to learn to save rxvt-unicode sessions, and have to arrange the
windows every time; anyone knows a quick tutorial on how to do that, but
quick, I'm busy on other issues?).

Measuring again to see the possible time discrepancy btwn the two systems
after 1000 seconds.

Both the systems clock ended the 1000 seconds period at exactly the same time.
Let me paste it over:

Code: Select all

------------------------------------------------------------
1000 of 1000 at 1s int.
Tue  6 Oct 14:52:25 CEST 2015

, and also paste over the script from my /usr/local/bin :

Code: Select all

#!/bin/bash

LIMIT=$1

for ((i=1; i<=LIMIT; i++))
do

echo $i of $LIMIT at $2s int.
$3
sleep $2
echo " "

echo " "
echo "------------------------------------------------------------"

done

exit=0

that I use for periodic execution of (mostly) simple commands. I called that script with:

Code: Select all

# run_CMD.sh 1000 1 date

at the same (as humanly possible) time on both the machines.

So, could the issue be with the hibernate scripts?

I use:

Code: Select all

# equery b /usr/sbin/hibernate
 * Searching for /usr/sbin/hibernate ... 
sys-power/hibernate-script-2.0-r6 (/usr/sbin/hibernate)
#

(no I wouldn't remeber by heart what I use, failing oldman's memory).

I didn't notice this issue previously. I did notice it the first time on another machine (another clone of the same kind) maybe a week ago.

Does anyone else have this kind of issue with the clock?

[miroR]

Unbelievably, but on yet a third system, a clone like the others, resume from hibernate-ram did not result in any time drift whatsoever. The time kept correct.

Sure, it is more complicated, the troubleshooting what is wrong here, can be some peripheral component attached on the time-drift-after-hibernate system, or can be some component, some functionality, in the hardware of the failing system, failing, or...

...Or it, still, because, look up again if you didn't take notice, of what other users have reported in the Gentoo Bugzilla and in the Syslog-ng's Github... [or it , still] could be somewhere something wrong in the kernel timing mechanisma or anywhere else down from there.

Regards!

[miroR]

I think I found what the reason was for the time drift.

Impoverished as I am (

WARNING: a techno-political digression away from this topic, skip to WARNING END if not interested
see:
Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-999436.html
if you want to see how regime treats honeland-living dissidents like me, no!, not so very much there, esp. because it's getting even worse, unless we don't unseat the idiots currently in power at the upcoming Parliamentary elections...
[Not so very much there] but you can glean a few facts, and I mean undeniable facts on their censorship, unless that is, they take down www.CroatiaFidelis.hr, my NGO's website, which I hope will not, but don't know that it will not happen...
at that page you can go straight at where you find some of the literal text:

Code: Select all

JunkMail rejected - 147-226.dsl.iskon.hr

(try single of those substrings separately if you don't get the entire string promptly, due to text wrapping)
and then only read around if you find it interesting.
WARNING END

Impoverished as I am, I have been using some 5-6 yrs old hard disks via USB2, poorly put together by some masking Freecom firm, but they are Seagate drives....

Masked-manufacturer it was, because in the first year or so, the smartmontools's smartctl command reported them as Freecom, but only later figured out it was Seagate drives actually...

And you can't really update the firmware of those drives, not easily that is... let alone automatically...

And to the system to which that perifery was attached, at boot time (

I think only at boot time, and I haven't checked, but it might be that if I attach them later, no time drift issue will occur, will report if it does

), the time drift occurs. If, that hardware is not attached, no time drift issue occurs.

Cheers!

[miroR]

This issue is hard to get the right idea of it.

Sometimes it appeared to me like I explained so far in this topic that you are reading (Time drift after hibernate-ram).

And recently, and I do not know if it is some of the changes (I update my Gentoo one to three times a month) that I made in the meantime.

Anyhow, I have to eat my words, because, it just went very fast, and after hibernate-ram.

It even appears that it adds speed after successive hibernate-ram's (never do I send it to standby too often, mostly once a day, and it appeared to be faster by adding what it speeded up the day before).

And! And: after I restarted the system, the clock is running fine.

No old external USB hardware was attached to that system during all the time when the said speedup happened, or did not happened these days, as I just explained in this post.

Just so readers would not get too easily to, sadly, any false conclusions from my reports, as unfortunately I was not able to get to any firm conclusions...

That system is running:

Code: Select all

# uname -r
4.2.4-hardened
#

And, over in my original timedrift topic, new stuff. Read there:

Syslog-ng from Delay Logging to BrokenPipe/no Logging
https://forums.gentoo.org/viewtopic-t-1 ... ml#7838704

Regards!