Porteus clock. How it works.

[brokenman]

Some people, quite reasonably, can't quite understand how the clock works in Porteus. It is not such a simple topic. I will attempt to explain it as best I can so people with any questions can be directed here.

There are two clocks. Let's refer to them as the hardware clock and the software clock. The hardware clock is the machine clock. The one built into the motherboard. The other is a software clock. This is the clock shown on the panel in your desktop environment.

The hardware clock is dumb. It has no concept of time zones or the natural drift in time that all clocks suffer. It just holds a number. If you boot Porteus with no cheatcodes and no timezone changes then Porteus will simply show this hardware clock time in your software clock. This means that if windows set your hardware clock the last time it shut down, then Porteus will show it as windows left it. I repeat. By default Porteus DOES NOT touch your hardware clock.

If you use a timezone cheatcode then Porteus will:
1) create a symlink at /etc/localtime that points to your timezone in /usr/share/zoneinfo
2) change the time standard to utc if 'utc' cheatcode is present. It does this by editing the file /etc/hardwareclock.
3) sync the clock online (if available) using the command: ntpdate pool.ntp.org
4) store the current system time to the hardware clock based on your preference in /etc/hardwareclock (utc or localtime)

So, if you use a timezone cheatcode then Porteus will alter the hardware clock time. If you are booting multiple operating systems on the same machine then each one will probably want to write to the hardware clock. In this situation you may have problems with the incorrect time showing. You can avoid these problems by:
a) Making sure you set the correct standard in /etc/hardwareclock (localtime or UTC) and not using a timezone cheatcode.
b) Setting your hardware clock to UTC and then using the correct timezone cheatcode for your area.

NB: Older version of Porteus used a different technique, however there were many complaints that the time was frequently incorrect (due to the above concepts) and so a new more reliable technique is now used.

[brokenman]

If you currently have an incorrect clock then consider the following techniques to correct it.

If you dual boot with windows.

Make a symbolic link at /etc/localtime that points to your preferred time zone in /usr/shre/zoneinfo.
This may be something like:

Code: Select all

ln -sf /usr/share/zoneinfo/America/Phoenix /etc/localtime
ntpdate pool.ntp.org
hwclock -w --localtime

Now you won't need to boot with any time related cheatcodes.

If you dual boot with other linux like operating systems or perhaps MAC then use this:

Code: Select all

ln -sf /usr/share/zoneinfo/America/Phoenix /etc/localtime
ntpdate pool.ntp.org
hwclock -w --utc

You can now boot using your cheatcode or preserve the above symlink in your changes.

[jssouza]

Thank you for the detailed explaination brokenman. Thank you also for answering my question from the other thread:

Does the hardware clock also set the timezone?

The hardware clock is dumb. It has no concept of time zones or the natural drift in time that all clocks suffer. It just holds a number.

I was a little surprised, because the output of hwclock --show also had a timezone displayed. Hence the question that maybe some RTCs do save zoneinfo also. I have played with the DS1307 RTC in the past and that doesn't.
This would mean the current operating system running that hardware needs its system configuration files to finally interpret the system time. And this is where I feel porteus should not write to the hardware clock (when timezone= cheatcode is provided).

[jssouza]

A few months back, at work we needed a Linux environment. So, I used porteus on a mac book pro which already had OSX and Windows on it. Although system time was shown wrong on porteus, this was not an issue until clock skew was detected while compiling software. So, I did the logical thing: used the timezone= cheatcode, all the while thinking that this is a live system, so should be fine. Porteus immediately got the correct time (from ntp) and the clock skew problem was solved. The problems started a few days later when somone noticed OSX showing wrong time. Windows showed some other wrong time!
Solution (for me on porteus) was simple: Comment off writing to hardware clock in rc.S and then use timezone=cheatcode whenever I find a wrong system time on any computer that I run this stick on. Recently, when I flew back home (on another continent), I only had to use the correct timezone= cheatcode and got the correct time, without worry that a hardware clock change may make the resident OS come up with a wrong system time on the family computer.

This is my humble opinion:
A computer will have resident operating systems with its configuration files to correctly interpret the hardware clock and show the correct system time. When a live OS writes to the hardware clock, it has its own set of configuration files, but these are not part of the computer, instead are part of the live medium. On the other hand, a resident OS, even a Linux, would have the configuration files also residing on that computer - so it should have the right to update the hardware clock.
The only time a live OS should write to the hardware clock is if it is part of that computer (installed as a resident OS), which then helps to also correct the clock drift once synced with ntp.
This would also work fine on systems that do not have an RTC - without any error that a hardware clock was not found while trying to write to it.

When a live system user sees a wrong system time, he attempts to correct his system time. As soon as he uses ntp, he gets the correct system time. The problem is solved. So why should in addition the hardware clock also updated if the problem is already solved?

[brokenman]

I see your point. You are saying that Porteus should not EVER write to the hardware clock. Just set the timezone and have ntp make sure the time is good.

So why should in addition the hardware clock also updated if the problem is already solved?
What about cases where a user doesn't have an outside internet connection?

All I can really do is remove the write to the hardware clock and wait for feedback.

[Ed_P]

All I can really do is remove the write to the hardware clock and wait for feedback.

Can't it be a user selectable option? Via gui, command line or cheatcode?

[jssouza]

What about cases where a user doesn't have an outside internet connection?

He should still have correct time, since hardware clock would still be read, correct zoneinfo and how to interpret the read hardware clock value (local/utc) are still done with the timezone= cheatcode. Only issue is if the user only uses porteus, and hardware clock has never had a chance to be written to by resident OSes. Then there would be a drift in the clock. But, this would also be true if the user never uses the changes= cheatcode. Since porteus does not write to the hardware clock by default, then too the clock would drift if only porteus was used.

Another interesting case would be if the user uses the timezone= cheatcode, but he can have internet connectivity only after 10 seconds (Maybe wireless authentication is done manually after complete bootup). In this case too ntp would fail. But this is independent of whether hardware clock is written or not.
As Ed_P mentioned, this case maybe handled with a user selectable option - manually run ntpdate after proper internet connection with an option to write to hardware clock for synchronization.

[brokenman]

Can't it be a user selectable option?

Possibly. For advanced users this would be great. For most people, even having the choice is not enough. They still need to understand how it works or else the differences between OSs wills crew them up. IMHO it would require a dedicated GUI just to explain how it works. There is already a GUI in some desktops to set time and ntp etc.

What would you suggest as defaults? No writing to hardware clock? localtime or utc?

[Ed_P]

For most people, even having the choice is not enough. They still need to understand how it works or else the differences between OSs wills crew them up. IMHO it would require a dedicated GUI just to explain how it works.

I don't agree. IMHO The choice should be simple, and easy to do, with a warning that it may effect the clocks on other systems. IMO Most new users are people with Windows on their pc who are trying a Linux system, not converting to it. If they don't understand something or it doesn't work they will reboot back to their Windows system. If the Windows system is screwed up somehow they never use the Linux system again.

A window containing something like:


Update the pc's hardware clock: yes no

Note: Updating the pc's hardware clock may impact other systems that run on the pc.
For more information see this webpage: http://forum.porteus.org/viewtopic.php?f=39&t=6369

What would you suggest as defaults? No writing to hardware clock? localtime ir utc?

No writing to hardware clock. And when the option is selected write localtime because that's the time the new user sees and that's Windows default. If a more advanced user wants the clock set to utc time a command line option should be available.

Basically it depends on who you are designing Porteus for. New to Linux users; home pc users, student pc users, grandparent pc users or Linux techs, Linux users from other versions, system repair techs.

[jssouza]

Ooh! Found this interesting script. Seems rc.S is not the only place where hardware clock is written to.

Code: Select all

cat /usr/lib64/pm-utils/sleep.d/90clock

Would this script be executed upon hibernate/suspend?
EDIT: The comment at the top of this file says modern kernels handle this correctly, so does the kernel write to the hardware clock on suspend?

[brokenman]

I just tested a suspend through the xfce4 menu and the script is not run.

[Evan]

<removed>

[jssouza]

Sometimes a 10 seconds timeout is not enough to call the background process in ntpdate.
On a PC, it is hard to know if ntpdate has executed or not, but on a system having no RTC, it is easier to find out, since whenever the date shows epoch (1 jan 1970) it certainly means that ntpdate has failed.
This may be because the wifi had not yet been connected to the internet while ntpdate was called. Changing the timeout to 15 seconds helped here.

[jssouza]

In /etc/rc.d/rc.S, the checks to see if an rtc driver is present would always fail.

Code: Select all

grep -wq rtc /proc/ioports || CLOCK_OPT="--directisa"

Reason being:

Code: Select all

[root:~]# grep -wq rtc /proc/ioports && echo "RTC present" || echo "Direct Access"
Direct Access
[root:~]# grep -q rtc /proc/ioports && echo "RTC present" || echo "Direct Access"
RTC present

Code: Select all

[root:~]# grep rtc /proc/ioports
  0070-0077 : rtc0