Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: LANMonkey on January 23, 2009, 06:28:55 PM
-
I have tried using 0.north-america.pool.ntp.org, pool.ntp.org and setting the time manually and it doesn't matter. I go back to look what time it says and it is always eight hours off. If it is January 12, 2009 9:26 AM, it will read January 12, 2009 1:26 AM. It seems to have the time zone set correctly to America/Los Angeles. I am in the Sacramento, CA area.
What is going on and how do I fix it?
-
What is going on and how do I fix it?
Your best bet is the bugracker.
-
The problem seems to have cleared up using a remote time server. I have yet to see if the problem persists when set manually, but apparently it just took a little while for the time to set against a remote server.
-
The problem seems to have cleared up using a remote time server. I have yet to see if the problem persists when set manually, but apparently it just took a little while for the time to set against a remote server.
if you setup your SME with a wrong date/time, time sync with remote server will fail if the difference is more than... well, I don't remember..
in this case, you should adjust your date/time manually an then change to sync to a time server.
Anyway, if you find something that does not work out-of-the-box, you should open a bug
Ciao
Stefano
-
Very strange. Now the problem is showing up in the BIOS settings. I have the BIOS set up to start the machine up once a day at a certain time. It was working and now that the SME settings are working, the BIOS clock is off by the same time.
-
Very strange. Now the problem is showing up in the BIOS settings. I have the BIOS set up to start the machine up once a day at a certain time. It was working and now that the SME settings are working, the BIOS clock is off by the same time.
What timezone did you configure for your machine and how did you configure the system clock to run GMT perhaps?
-
The BIOS clock does not have a time zone setting. I have never seen a time zone setting in the BIOS clock setting. The operating system clock has a correct time zone setting (PST for Central Northern California) and the time is correct too. Again, I am using a network time server for the operating system.
I have tried setting the BIOS clock one more time. Let's give it another 24 hours.
Still ... why would the BIOS clock change?
-
SME is not installed on a Virtual Machine by chance?
-
No, I certainly would have pointed that out.
:lol: I still don't have a clue about virtual machines. Sounds like an operating system for operating systems. :???:
The hardware is an old OptiPlex from Dell.
-
I thought it surely didn't pay to ask but the bios clock change sounded like something that can happen in that configuration.
The puzzling thing here is that it is always exactly 8hrs. This would indicate a time zone problem between the bios clock and the Software clock. As near as I can understant Linux does not ever write the software time back to the BIOS time. (I could be wrong on this) And it only checks the BIOS time at startup.
Windows on the other hand always writes the Software time back to the BIOS clock.
If the time was erratic and just lost time or gained time I would suspect a dying CMOS battery as you indicate this is an older system. The fact that the time is exactly 8 hours off indicates that this is not the problem.
-
Yes, I was hoping it was a battery problem. The thing that I worry about is a potential relationship between the BIOS and the software running on the computer which is bound to be way over my head. I'm a little disturbed to hear that software can write back to the BIOS, although I'm comfortable that some BIOS's have anti-virus protection. But, I haven't seen that for a while.
-
I am sure you have read this: http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter13#Set_date_and_time
and I see you have done what it suggests (setting the time manually to the correct time and timezone and then turning on NTP.)
Can you set the time manually, log out of server-manager, Log back into server-manger and see that your change has held?
Is this an old install that has been working fine up until now or is it a new install that has never worked correctly?
-
Yes, I've been in and out of the Server Manager many times only to see the time is correct now that I use a time server.
Come to think of it, it is not until I changed to use the time server that it would hold the correct time. Ever since I installed it, the problem was the same. The installation is at least a month old.
-
....
I have tried setting the BIOS clock one more time. Let's give it another 24 hours.
Still ... why would the BIOS clock change?
It's off again. There is no question about it. The software is changing the BIOS setting.
-
It's off again. There is no question about it. The software is changing the BIOS setting.
What is the time now on your server and what should it be? In other words what is the difference? Is it constant?
datehwclock
What is the output ofls -la /etc/localtime
Did you perhaps say that your system clock uses UTC during installation and is your localtime perhaps differing 8 hours from UTC (http://en.wikipedia.org/wiki/List_of_time_zones)?
-
Did you perhaps say that your system clock uses UTC during installation and is your localtime perhaps differing 8 hours from UTC (http://en.wikipedia.org/wiki/List_of_time_zones)?
SME server assumes without asking that time is set to UTC. It's also designed to run 24x7, so the BIOS should rarely run.
I have the BIOS set up to start the machine up once a day at a certain time.
That's an unusual thing to do with SME server. Nevertheless if you wish to do that, you should set your "certain time" to a "certain time UTC".
-
This is correct as I pull it out:
Date: Sat Feb 7 11:23:01 PST 2009
And this is also correct:
hwclock: Sat 07 Feb 2009 11:24:10 AM PST -0.191442 seconds
This is the result of ls -la /etc/localtime
lrwxrwxrwx 1 root root 41 Jan 11 02:31 /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles
...
Did you perhaps say that your system clock uses UTC during installation and is your localtime perhaps differing 8 hours from UTC (http://en.wikipedia.org/wiki/List_of_time_zones)?
I don't recall one way or the other whether I selected any option for UTC or whether the option existed at all.
-
SME server assumes without asking that time is set to UTC. It's also designed to run 24x7, so the BIOS should rarely run.
That's an unusual thing to do with SME server. Nevertheless if you wish to do that, you should set your "certain time" to a "certain time UTC".
I'm quite certain that the BIOS does not have the option to set the time for UTC. I'll look again, but in all the many BIOS's I've seen I don't think I've ever seen that.
-
I'm quite certain that the BIOS does not have the option to set the time for UTC. I'll look again, but in all the many BIOS's I've seen I don't think I've ever seen that.
I wasn't suggesting there was such a thing. If you wish to persist in setting a wake-up time, set the wake-up time to the time in London, UK you want the system to wake up, not Californian time.
-
OK, but do I understand correctly that this is a workaround and not the expected functionality of SME?
-
OK, but do I understand correctly that this is a workaround and not the expected functionality of SME?
It's expected functionality of SME that the hardware clock will be set to UTC.
It's also expected that SME will run 24x7, and not be started/stopped at various times during the day.
-
OK, understood. Problem solved.
-
Goto >> Date and time configuration and Disable Network Time Server.
Then enter your info and re-enable the time server.
hth
-
Goto >> Date and time configuration and Disable Network Time Server.
Then enter your info and re-enable the time server.
hth
Why would I do this?
-
I think electroman00 is pointing out the correct way to set the time zone before you turn on NTP. He is quoting from the manual.
You have hit on an interesting hardware/software time relationship that just has not come up before because "nobody??" else is using the bios settings to reboot their server.
If I understand correctly from the posts above, the system clock should be set to UTC/GMT which is PST/Los Angeles +8hrs. (the correct way to say this is that PST = UTC -8). This means that any Bios reboots will have to be calculated by taking the local time you want the system to reboot +8.
As you understand, you do not set which timezone the system is in on the hardware clock. Instead you set the hardware clock to the current UTC/GMT time. When you then set the timezone in SME, on bootup SME calculates the difference from UTC and sets the SOFTWARE clock to the correct LOCAL time. (in this case PST)
-
OK. As far as I am concerned, no other discussion is necessary. Until some new demand or observation be made regarding my system by me that comes up against the system clock, Problem Solved.
-
Seem to be some confusion here.
I think electroman00 is pointing out the correct way to set the time zone before you turn on NTP. He is quoting from the manual.
It's in the manual but not in the wiki, which could lend itself to this type of issue expressed by the OP.
You have hit on an interesting hardware/software time relationship that just has not come up before because "nobody??" else is using the bios settings to reboot their server.
Rebooting is irrelevant to the issue here, correcting the date/time configuration solves the issue here and OP can reboot every minute if he wants.
Although it may not be wise to reboot every minute or every day for that matter, to each his own.
If I understand correctly from the posts above, the system clock should be set to UTC/GMT which is PST/Los Angeles +8hrs. (the correct way to say this is that PST = UTC -8).
The system clock will always be set to UTC and a software +/- offset based on your time zone to display to the user, the system clock is always maintained UTC on virtually all computer systems, thus the term Coordinated Universal Time UTC.
This means that any Bios reboots will have to be calculated by taking the local time you want the system to reboot +8.
When the time is updated the bios (hardware clock) will be updated to your time zone, not UTC, the bios clock knows nothing of time zones, never has and never will, it's superfluous code that isn't needed in the bios.
Most all time sync software will update the OS system clock (software clock) to UTC and the bios (hardware clock) to your time zone, sometimes the bios update is optional/configurable.
All NTP servers are UTC, thus your OS system clock (software clock) is updated to UTC as Charlie stated, then any software that displays the time must know the time zone your in to display it correctly.
Thus....
OS system clock (software clock) updated to UTC
and
Bios (hardware clock) updated to your time zone via the +/- TZ offset
To test the bios clock is updated, simply set the bios time incorrectly and run any time sync software, recheck the bios clock.
When you manually enter the bios time you should enter your time zone time, not UTC time.
But you really don't have to set it if your using a good time sync app.
As you understand, you do not set which timezone the system is in on the hardware clock. Instead you set the hardware clock to the current UTC/GMT time.
First read...http://en.wikipedia.org/wiki/Coordinated_Universal_Time (http://en.wikipedia.org/wiki/Coordinated_Universal_Time)
Incorrect....you set bios clock (hardware) to your time zone, since the bios doesn't know about TZ's and cannot adjust for them.
In fact you don't have to set the bios (hardware) clock, it will be updated by NTP service and set to your time zone via the closest UTC time server you choose, which may then be reported/displayed via some software app to the user as UTC adjusted for the user Time Zone.
Setting and Reading the OS system software clock are two different methods, always referenced to UTC.
When you then set the timezone in SME, on bootup SME calculates the difference from UTC and sets the SOFTWARE clock to the correct LOCAL time. (in this case PST)
OS system clock is always UTC and software app adjusted for time zone for display.
If it doesn't then there is likely a bug, hardware or software or last but not least a incorrect configuration, which is what we have here in the thread.
Computer systems don't care what time zone their in, so all time sensitive systems are synced to UTC so no time zone adjustment needs to be done to maintain/improve accuracy.
If systems needed to TZ calc then the time it takes to calc would need to be employed in the final time calc as a correction and each system runs at different speeds so their corrections would be different adding to inaccuracy.
Humans do care what time zone their in, so systems will usually always adjust for TZ via software, no big deal if it's off by a few milliseconds.
The entire GPS system for example uses UTC, synced from Atomic Clocks and corrected for many issues that occur within the system.
One example of a correction is the time it takes for the radio signal to travel 12,500 miles from earth to the satellite.
A millisecond error in the GPS world is thousands of feet of error in the final position calc.
The GPS system is time accuracy and measurement to the MAX and simple geometry.
Fortunately we don't have to get involved with such time accuracy with our systems.
Since most were asleep in geometry, we don't have to worry about that either, simply buy a GSP and you might know where you are.
Or for that matter where your going. :P
Go here http://www.n2yo.com/?k=20 (http://www.n2yo.com/?k=20) and select a GPS satellite, make note of the altitude and speed and try to imagine the time accuracy you need to calc a 3 axis position within a few feet from 12,500 miles away.
Yup....you also get altitude above MSL (mean sea level).
Why is it only above MSL and not below MSL, radio signals do not traverse water (H2O).
So GPS is no help to a submerged submarine, they have to nav the old fashioned way, when submerged.
Thus a basic example for the use of UTC and the level of accuracy that may be needed within a system.
OK. As far as I am concerned, no other discussion is necessary. Until some new demand or observation be made regarding my system by me that comes up against the system clock, Problem Solved.
If it works for you it works for me, however it is the solution to your problem and misunderstanding.
And your welcome anyway, even if it won't help you, it may help others.
hth
-
@LANMonkey,
I am sorry for using your thread for this discussion, however, It looks like I put two and two together and came up with six.
@electroman00,
Thanks for explaining my incorrect assumptions. I "think" I understand the relationship of hardware and software clocks now. I will do some more research.
-
Your more then welcome, were all here to help each other.
Fortunately for you all two capacitors blew up on the video card that is in the system I was using to write the post, had to shut things down rather quickly, else the post might have gone on for days. :P
Yup....looks like ole faithful just got demoted.
Now I'm on the search in the shop to find two stinking caps, in a short period of time.
Were back to time again. :P
Days to find them in the shop and five minutes to solder them in, what a concept. :P