ntpd issue

z662

z662

Greetings,

I seem to have an issue with ntpd and was hoping someone could shed some light on the issue. I hope it is something simple/stupid that is mis-configured (probably is).

I am running FreeBSD 10.0 p12 and have the following in my /etc/rc.conf:
Code: 
ntpd_enable="YES"

I also have the standard contents in /etc/ntp.conf. I will post if necessary but the contents are the defaults I believe:

Code: 
server 0.freebsd.pool.ntp.org iburst
server 1.freebsd.pool.ntp.org iburst
server 2.freebsd.pool.ntp.org iburst

I live in Pennsylvania and the time is currently 11:45PM EST (Friday Nov. 21). However when using the date command via the CLI I get:
Code: 
mercury% date
Sat Nov 22 03:46:00 EST 2014

I also tried to do a real-time ntpdate but get this:
Code: 
mercury% ntpdate
22 Nov 03:47:29 ntpdate[49539]: no servers can be used, exiting

Any help would be greatly appreciated. Thanks!
 
You are dual booting with Windows! Windows is using local time instead of Universal Coordinate Time UTC. For hours is the exact difference between your local time and Greenwich Mean Time, which roughly corresponds to UTC.
 
NTPd refuses to adjust the time on boot up if the time change would be too much (1000 seconds or more to exact). You can change this policy with this setting in rc.conf(5):

Code: 
ntpd_sync_on_start="YES"

If you are dual booting as Oko suggests you'll have wrong time in Windows when you boot to it next time. The proper solution would be to run tzsetup(8) and select the option that tells the system that the hardware clock is in local time and not in UTC.
 
No dual boot, this is a standalone webserver. Perhaps it is my BIOS? The rules about not changing the time too much at a time make sense, I will add that sync setting to my /etc/rc.conf.

Thanks!
 
Set the time to UTC in your BIOS settings then set the correct timezone with tzsetup(8), select "hardware clock in UTC" option. The time should be then correct in your system after a reboot.
 
Do I still need to do that? After setting the sync option and rebooting the issue has been resolved. However if that is the preferred method for future use I will do that too. Just curious.
 
If you are running server as you are saying you should not need to reboot for at least 1-2 years so BIOS should not be something I would worry about. In general it is enough to have only the following in /etc/rc.conf

Code: 
ntpd_enable="YES"

of course and correct time servers listed in /etc/ntp.conf. Clock drifting of more than half second is typically sign of dying hardware. Clock impression of several millisecond is due to Relativistic effects (time needed for light to travel from ntp server to your server). If that is the problem which is in my line of business you have to set up local Time Synchronization Server.
 
I will just set it next time I reboot. I run
Code: 
kern.securelevel=3
so I have to reboot every month or two when patching the OS anyhow.

The hardware is relatively new so my guess is that my BIOS was set incorrectly upon install which may have caused problems with the OS...I hope so at least!
 
getopt said:
Can you elaborate on that, please? I want to learn something. :)
Click to expand...
Well speed of light is finite right which in turn means that signal from the remote server to your computer travels finite speed typically at least few percentages slower than the speed of light. Divide the distance of remote Time server to your computer with the speed of light and you will get few milliseconds which is expected normal clock drifting. Why does the clock drifting occur on the first place? Lets for a moment approach this problem with a mind of mathematician. In my ideal mathematical world I have two clocks. One is in D.C. for example and one is in my house in Pittsburgh. Two clocks are perfectly accurate yet don't show the same time. What is wrong? Well they don't leave in the same inertial coordinate frame:).
 
z662 said:
Do I still need to do that? After setting the sync option and rebooting the issue has been resolved. However if that is the preferred method for future use I will do that too. Just curious.
Click to expand...

Nope, I was just assuming the hardware clock was still set wrong. No need to do that.
 
It's been a while since I messed with it, but I believe there is a sysctl to periodically update the CMOS time. That can reduce the offset caused by the clock running from the CMOS when the system is off.
 
I just set this myself because my Soekris router time is always behind when I reboot. Haven't rebooted to see if it helps just yet but the tunable that wblock@ just mentioned is shown below:
sysctl -d machdep.rtc_save_period
Code: 
machdep.rtc_save_period: Save system time to RTC with this period (in seconds)
 
You must log in or register to reply here.
Back
Top