LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 07-26-2012, 05:17 AM   #16
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,268

Original Poster
Rep: Reputation: 49

You noticed the unit ms/s in "slew rate = 0.05ms/s" in your post. This is the magnitud called slew rate. Also notice how 2000s is the inverse of the slew rate times 1ms. If this is of help to you I will be glad. Anyways, here's

http://en.wikipedia.org/wiki/Ntpd

What I do not understand is why the PROCESSOR has to be synchronized with NTP or any time base. What has the CPU to do with any time base save its own clock?

As to my problem, I can say I have just solved it. I inverted the execution bit in /etc/rc.d/rc.ntpd, so it will not execute at boot time. And now I just created a file in /etc/cron.hourly to update the time every hour, the minimum time period during which I use the my machine. Whether this is detrimental to the system I really do not know. I'll wait and see.

Last edited by stf92; 07-26-2012 at 05:33 AM.
 
Old 07-26-2012, 06:33 AM   #17
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
Originally Posted by stf92 View Post
What I do not understand is why the PROCESSOR has to be synchronized with NTP or any time base. What has the CPU to do with any time base save its own clock?
Your running Linux system has 2 clocks.

1. The BIOS clock on the Motherboard which is used to initialize the system clock on boot and is in turn updated from the system clock.

2. The system clock which is actually internal to the kernel and is interrupt driven, and interrupts are handled by ........ the CPU(s)
 
1 members found this post helpful.
Old 07-26-2012, 06:50 AM   #18
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,268

Original Poster
Rep: Reputation: 49
So all this only to maintain the time displayed by the date command and to update the cmos and to create and modify files with a time stamp?
 
Old 07-26-2012, 06:55 AM   #19
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
ssh/ssl requires the time to be in sync as well or they will fall over

file time stamps might not seem to important but plenty of warning messages will get logged if it gets out of hand (ie times modified in the future)
 
Old 07-26-2012, 07:00 AM   #20
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,268

Original Poster
Rep: Reputation: 49
I see. I had ssh activated once and a message arrived every a few seconds. Well, I do not know if I undertand well your post but it seems that all has to do with file time stamps!
 
Old 07-26-2012, 10:06 AM   #21
jamesf
Member
 
Registered: Dec 2004
Location: USA
Distribution: Slackware 12 and higher
Posts: 229

Rep: Reputation: 51
Jumping the time forward or, especially, backward is generally considered detrimental to a running linux system. A program that checks file stamps against the current time can find files that were created days, hours, minutes, or seconds in the future if the time is suddenly jumped backward by setting it to another time server.

This is why the ntp daemon slews the time slowly over a period. If your time is behind then a machine second is a little shorter than a real second until you catch up. If your time is ahead then a machine second is a little longer than a real second until you fall back to the correct time. The time never jumps, it just eases into correctness and file systems and programs get no surprises.

The ntp daemon also monitors your system clock's ticks and compares them to the external time source to build a "drift" factor for your system so that it can keep your system time correct by applying that drift even if you are disconnected from the network. After each boot it starts by finding an external server and then queries it in ever-longer intervals as it determines local clock tick drift, building /etc/ntp/drift to keep the knowledge of that drift between reboots.

Starting ntpdate every hour does none of that _and_ has the added detriment of "jerking" the time forward and backward because your local clock tick drift is never calculated and applied.

Much better, IMHO, to stand on the shoulders of giants than to re-invent the wheel.

All this is my opinion only, your system, configure it as you will! ;v)
 
2 members found this post helpful.
Old 07-26-2012, 10:44 AM   #22
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,268

Original Poster
Rep: Reputation: 49
Your post is very illustrative. As to what I did, I did it because I found the time in my system was far behind my local time.
 
Old 07-26-2012, 01:17 PM   #23
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Without backing up through the technical details described by others, here's the case for using NTP to keep your system clocks synchronized with universal coordinated time (known as UTC, the French abbreviation). The stratum one time servers around the world are referenced to the atomic clocks scattered around the world (and coordinated with one another, thus the name). You PC platform has a notoriously inaccurate clock (really!) along with a second clock embedded in the Linux kernel and it's a Real Good Idea to keep those coordinated with each other and to an external time reference to avoid problems that can crop up otherwise. Running the NTP daemon is the best solution anybody's ever come up with for accomplishing that.

You're in Argentina. NTP Pool (http://www.pool.ntp.org/zone/ar) recommends three pool servers:
Code:
server 3.ar.pool.ntp.org
server 3.south-america.pool.ntp.org
server 0.south-america.pool.ntp.org
You would place those in your /etc/ntp.conf file thus:
Code:
server	127.127.1.0	# local clock
fudge	127.127.1.0 stratum 10	
server 3.ar.pool.ntp.org
server 3.south-america.pool.ntp.org
server 0.south-america.pool.ntp.org
Are the local clock and fudge entries necessary? Yes, they are. If you lose your internet connection NTP will fall back on the local clock and continue running until the internet comes back when it will then synchronize with one of the pool servers listed.

Other entries in /etc/ntp.conf might include these:
Code:
#
# Drift file.
# Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
Should already be in /etc/ntp.conf and uncommented; the file, /etc/drift, should have a numeric value in it after NTP has been running for a while. That number represents the drift of your local clock versus UTC and is used by the NTP daemon to fine-tune your clock to UTC (it's not seconds, it's a scaling value). I have found it useful in a newly installed NTP to insert 0.0 in /etc/ntp/drift -- I don't remember exactly why but it's what I've done for years and it seems to work rather than leaving the file empty to begin with (NTP eventually will write a value in the file either way).
Code:
#
# Log file
#
logconfig=allclock +allpeer +allsys +allsync
logfile /var/log/ntp.log
It can be useful to look at the log file periodically. A normally working NTP will look something like this:
Code:
22 Jul 04:40:03 ntpd[21864]: Listen normally on 6 multicast 224.0.1.1 UDP 123
22 Jul 04:40:03 ntpd[21864]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
22 Jul 04:40:03 ntpd[21864]: LOCAL(0) 8011 81 mobilize assoc 35766
22 Jul 04:40:05 ntpd[21864]: 72.26.198.240 8011 81 mobilize assoc 35767
22 Jul 04:40:08 ntpd[21864]: 74.117.157.170 8011 81 mobilize assoc 35768
22 Jul 04:40:09 ntpd[21864]: 64.73.32.135 8011 81 mobilize assoc 35769
22 Jul 04:40:09 ntpd[21864]: 0.0.0.0 c016 06 restart
22 Jul 04:40:09 ntpd[21864]: 0.0.0.0 c012 02 freq_set kernel 77.276 PPM
22 Jul 04:40:10 ntpd[21864]: LOCAL(0) 8024 84 reachable
22 Jul 04:40:10 ntpd[21864]: LOCAL(0) 963a 8a sys_peer
22 Jul 04:40:10 ntpd[21864]: 0.0.0.0 c515 05 clock_sync
22 Jul 04:40:12 ntpd[21864]: 72.26.198.240 8024 84 reachable
22 Jul 04:40:13 ntpd[21864]: 74.117.157.170 8024 84 reachable
22 Jul 04:40:15 ntpd[21864]: 64.73.32.135 8024 84 reachable
22 Jul 04:44:32 ntpd[21864]: 72.26.198.240 963a 8a sys_peer
Those few lines simply show what a working NTP looks like; if there were problems, those would show up in the same log.

If you're going to use the logging, you may want to add this to /etc/logrotate.d/ntpd:
Code:
cat /etc/logrotate.d/ntpd
/var/log/ntp.log {
  rotate 10
  notifempty
  missingok
  compress
  delaycompress
  sharedscripts
  postrotate
    /etc/rc.d/rc.ntpd restart
  endscript
}
The logs can get large -- I keep 10 compressed logs, a more practical number might be 3. Simply change rotate 10 to rotate 3 in the above.

All you have to do to use the NTP daemon is edit your /etc/ntp.conf file, pretty much leaving it alone except for the server entries (and, maybe, the log file entries) then make /etc/rc.d/rc.ntpd executable (chmod 755 /etc/rc.d/rc.ntpd.

Make sure you've set your system in the correct time zone. Buenos Aires is 3 hours offset from UTC and apparently does not use daylight saving time; if it's 1700 UTC, it's 1400 ART.

Do a one-time set the clock as you have been then start the NTP daemon:
Code:
/etc/rc.d/rc.ntpd start
(you must do all the above as root).

Wait about five minutes then, again as root (or su - or sudo)
Code:
ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l  45h   64    0    0.000    0.000   0.000
+205-196-146-72. 108.76.168.146   2 u  355 1024  377  1615.36   -8.986  52.792
*four10.gac.edu  18.26.4.105      2 u  967 1024  377  1384.06  -56.502  39.132
+framboise.hoopy 209.51.161.238   2 u  925 1024  377  1366.12  -41.546  50.117
You should see something similar to this (you can execute ntpq -p anytime). This indicate that the daemon has synchronized to the host identified with the asterisk (*). Yours will never be the same hosts as shown (these are US pool servers). Note that you can also use ntpq -pn to show the IP addresses of the pool servers rather than the fully qualified name (no DNS look up involved, it's quicker).

Once synchronized, NTP will keep your clocks synchronized to UTC and you don't need to worry about running a cron job every so often to set the clocks, it'll just happen.

Now, all the above assumes that your system(s) run 24/7 and your internet connection is also 24/7; NTP will work if the system has been turned off and your clocks haven't drifted too far during the powered-off period and that the internet connection is available before you boot. If you need to boot your system and manually start your internet connection, just change /etc/rc.d/rc.ntpd to mode 644 (so it won't automatically start), make your connection then start the daemon
Code:
su -    (or sudo)
sh /etc/rc.d/rc.ntpd start
Hope this helps some.

Last edited by tronayne; 07-26-2012 at 01:20 PM.
 
2 members found this post helpful.
Old 07-26-2012, 02:50 PM   #24
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,268

Original Poster
Rep: Reputation: 49
Thanks tronayne. In case you mind, have a look at
Code:
semoi@darkstar:/etc$ cat ntp.conf
# Sample /etc/ntp.conf:  Configuration file for ntpd.
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
#server  pool.ntp.org

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

#
# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keys           /etc/ntp/keys
#trustedkey     65535
#requestkey     65535
#controlkey     65535

# Don't serve time or stats to anyone else by default (more secure)
restrict default noquery nomodify
# Trust ourselves.  :-)
restrict 127.0.0.1

semoi@darkstar:/etc$
You can see the line with server pool.ntp.org has been commented. I think this is why the system clock lags.
 
Old 07-26-2012, 04:07 PM   #25
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
Quote:
Originally Posted by tronayne View Post
[/code]
You would place those in your /etc/ntp.conf file thus:
Code:
server	127.127.1.0	# local clock
fudge	127.127.1.0 stratum 10	
server 3.ar.pool.ntp.org
server 3.south-america.pool.ntp.org
server 0.south-america.pool.ntp.org
Are the local clock and fudge entries necessary? Yes, they are. If you lose your internet connection NTP will fall back on the local clock and continue running until the internet comes back when it will then synchronize with one of the pool servers listed.
Watch out for the local clock entry. it appears to stop the initial time setting from working correctly, both with and without the '-q' option.

Try this on a test system: stop ntpd and set your system clock back a couple of hours using the date command and then with the definitions above in your ntp.conf and rc.ntpd enabled, reboot your system. You'll find that it doesn't correct the time when ntpd starts, and the offsets you'll be left with will be far too large to be corrected through the normal adjustment process. This is true even if the '-g' panicgate option is set..

To work around this you can run the deprecated 'ntpdate' command prior to starting ntpd, but 'ntpd -g -q' suffers the same problem and won't work.

I decided just to remove the local clock reference. Unless you're serving time to other hosts on your network from this ntpd, it doesn't add any value to include the local clock reference as a fall-back, and it avoids the problem I describe above.

edit:
http://fixunix.com/ntp/67764-ntpd-4-...zed-local.html suggests this might be a kernel clocksource issue and can be fixed with "clocksource=acpi_pm" kernel option. I'll go give that a try and see what happens....

Last edited by GazL; 07-26-2012 at 04:35 PM.
 
Old 07-26-2012, 04:42 PM   #26
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Uh, no, the local clock does not do that -- note that it's set to stratum 10 (the fudge line immediately following)? NTP uses a combination of the lowest available stratum value(s) (the st column in the ntpq -p display) and the lowest offset for synchronization. It's there:
Quote:
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available.
Additionally, you do not want to use the prefer keyword with any server entry unless you have a local, rock solid, time source available (an NTP server on your LAN, a GPS clock or some other reference time source).

I should note that my servers have been running this way for about 15 years now, working just fine.

Hope this helps some.

Last edited by tronayne; 07-26-2012 at 04:54 PM.
 
Old 07-26-2012, 04:52 PM   #27
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Quote:
Originally Posted by stf92 View Post
Thanks tronayne. In case you mind, have a look at...
Yup, all you have to do is change that to
Code:
server	127.127.1.0	# local clock
fudge	127.127.1.0 stratum 10	
server 3.ar.pool.ntp.org
server 3.south-america.pool.ntp.org
server 0.south-america.pool.ntp.org
And you'll be good to go.

Hope this helps some.
 
Old 07-26-2012, 04:55 PM   #28
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
it may not be supposed to do that, but I can assure you it does do it.
Here...

Code:
root@ws1:~# cat /etc/ntp.conf

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

server 0.uk.pool.ntp.org iburst
server 1.uk.pool.ntp.org iburst
server 2.uk.pool.ntp.org iburst
server 3.uk.pool.ntp.org iburst

driftfile /etc/ntp/drift

restrict default noquery nomodify
restrict 127.0.0.1

root@ws1:~# ps -ef |grep ntpd
root      2144  2125  0 21:50 pts/0    00:00:00 grep ntpd
root@ws1:~# date
Thu Jul 26 21:50:16 BST 2012
root@ws1:~# date 07261800
Thu Jul 26 18:00:00 BST 2012
root@ws1:~# ntpd -d -n -g -q
ntpd 4.2.6p5@1.2349 Sun Apr  8 01:15:09 UTC 2012 (1)
26 Jul 18:00:44 ntpd[2148]: proto: precision = 0.184 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
26 Jul 18:00:44 ntpd[2148]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
26 Jul 18:00:44 ntpd[2148]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
26 Jul 18:00:44 ntpd[2148]: Listen normally on 1 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
26 Jul 18:00:44 ntpd[2148]: Listen normally on 2 eth0 192.168.1.2 UDP 123
restrict: op 1 addr 192.168.1.2 mask 255.255.255.255 mflags 00003000 flags 00000001
26 Jul 18:00:44 ntpd[2148]: peers refreshed
26 Jul 18:00:44 ntpd[2148]: Listening on routing socket on fd #19 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
peer_clear: at 0 next 1 associd 5504 refid INIT
event at 0 LOCAL(0) 8011 81 mobilize assoc 5504
newpeer: 127.0.0.1->127.127.1.0 mode 3 vers 4 poll 6 6 flags 0x109 0x1 ttl 0 key 00000000
peer_clear: at 0 next 2 associd 5505 refid INIT
event at 0 82.219.4.31 8011 81 mobilize assoc 5505
newpeer: 192.168.1.2->82.219.4.31 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
peer_clear: at 0 next 3 associd 5506 refid INIT
event at 0 146.185.21.74 8011 81 mobilize assoc 5506
newpeer: 192.168.1.2->146.185.21.74 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
peer_clear: at 0 next 4 associd 5507 refid INIT
event at 0 5.2.16.107 8011 81 mobilize assoc 5507
newpeer: 192.168.1.2->5.2.16.107 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
peer_clear: at 0 next 5 associd 5508 refid INIT
event at 0 82.219.4.30 8011 81 mobilize assoc 5508
newpeer: 192.168.1.2->82.219.4.30 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel -68.116 PPM
refclock_transmit: at 1 127.127.1.0
refclock_receive: at 1 127.127.1.0
event at 1 LOCAL(0) 8024 84 reachable
refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000000
clock_filter: n 1 off 0.000000 del 0.000000 dsp 7.937500 jit 0.000000
select: combine offset 0.000000000 jitter 0.000000000
event at 1 LOCAL(0) 903a 8a sys_peer
clock_update: at 1 sample 1 associd 5504
26 Jul 18:00:45 ntpd[2148]: ntpd: time slew +0.000000 s
ntpd: time slew +0.000000s
root@ws1:~# date
Thu Jul 26 18:00:49 BST 2012
root@ws1:~#
then without local
Code:
root@ws1:~# cat /etc/ntp.conf

#server 127.127.1.0     # local clock
#fudge  127.127.1.0 stratum 10

server 0.uk.pool.ntp.org iburst
server 1.uk.pool.ntp.org iburst
server 2.uk.pool.ntp.org iburst
server 3.uk.pool.ntp.org iburst

driftfile /etc/ntp/drift

restrict default noquery nomodify
restrict 127.0.0.1

root@ws1:~# date
Thu Jul 26 18:02:11 BST 2012
root@ws1:~# ntpd -d -n -g -q
ntpd 4.2.6p5@1.2349 Sun Apr  8 01:15:09 UTC 2012 (1)
26 Jul 18:02:22 ntpd[2155]: proto: precision = 0.128 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
26 Jul 18:02:22 ntpd[2155]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
26 Jul 18:02:22 ntpd[2155]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
26 Jul 18:02:22 ntpd[2155]: Listen normally on 1 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
26 Jul 18:02:22 ntpd[2155]: Listen normally on 2 eth0 192.168.1.2 UDP 123
restrict: op 1 addr 192.168.1.2 mask 255.255.255.255 mflags 00003000 flags 00000001
26 Jul 18:02:22 ntpd[2155]: peers refreshed
26 Jul 18:02:22 ntpd[2155]: Listening on routing socket on fd #19 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
peer_clear: at 0 next 1 associd 13069 refid INIT
event at 0 217.114.59.3 8011 81 mobilize assoc 13069
newpeer: 192.168.1.2->217.114.59.3 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
peer_clear: at 0 next 2 associd 13070 refid INIT
event at 0 80.93.163.202 8011 81 mobilize assoc 13070
newpeer: 192.168.1.2->80.93.163.202 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
peer_clear: at 0 next 3 associd 13071 refid INIT
event at 0 109.74.206.120 8011 81 mobilize assoc 13071
newpeer: 192.168.1.2->109.74.206.120 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
peer_clear: at 0 next 4 associd 13072 refid INIT
event at 0 194.238.48.2 8011 81 mobilize assoc 13072
newpeer: 192.168.1.2->194.238.48.2 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel -68.116 PPM
transmit: at 1 192.168.1.2->217.114.59.3 mode 3 len 48
receive: at 1 192.168.1.2<-217.114.59.3 mode 4 len 48
event at 1 217.114.59.3 8024 84 reachable
clock_filter: n 1 off 13831.038819 del 0.024624 dsp 7.937500 jit 0.000000
transmit: at 2 192.168.1.2->80.93.163.202 mode 3 len 48
receive: at 2 192.168.1.2<-80.93.163.202 mode 4 len 48
event at 2 80.93.163.202 8024 84 reachable
clock_filter: n 1 off 13831.039738 del 0.020040 dsp 7.937501 jit 0.000000
transmit: at 3 192.168.1.2->217.114.59.3 mode 3 len 48
transmit: at 3 192.168.1.2->109.74.206.120 mode 3 len 48
receive: at 3 192.168.1.2<-109.74.206.120 mode 4 len 48
event at 3 109.74.206.120 8024 84 reachable
clock_filter: n 1 off 13831.038957 del 0.019405 dsp 7.937501 jit 0.000000
receive: at 3 192.168.1.2<-217.114.59.3 mode 4 len 48
clock_filter: n 2 off 13831.040463 del 0.028156 dsp 3.937508 jit 0.001644
transmit: at 4 192.168.1.2->194.238.48.2 mode 3 len 48
transmit: at 4 192.168.1.2->80.93.163.202 mode 3 len 48
receive: at 4 192.168.1.2<-194.238.48.2 mode 4 len 48
event at 4 194.238.48.2 8024 84 reachable
clock_filter: n 1 off 13831.047058 del 0.032445 dsp 7.937500 jit 0.000000
receive: at 4 192.168.1.2<-80.93.163.202 mode 4 len 48
clock_filter: n 2 off 13831.047744 del 0.035302 dsp 3.937509 jit 0.008007
transmit: at 5 192.168.1.2->217.114.59.3 mode 3 len 48
transmit: at 5 192.168.1.2->109.74.206.120 mode 3 len 48
receive: at 5 192.168.1.2<-109.74.206.120 mode 4 len 48
clock_filter: n 2 off 13831.037329 del 0.015626 dsp 3.937508 jit 0.001628
receive: at 5 192.168.1.2<-217.114.59.3 mode 4 len 48
clock_filter: n 3 off 13831.038967 del 0.024478 dsp 1.937516 jit 0.001063
transmit: at 6 192.168.1.2->194.238.48.2 mode 3 len 48
transmit: at 6 192.168.1.2->80.93.163.202 mode 3 len 48
receive: at 6 192.168.1.2<-194.238.48.2 mode 4 len 48
clock_filter: n 2 off 13831.039623 del 0.017203 dsp 3.937508 jit 0.007436
receive: at 6 192.168.1.2<-80.93.163.202 mode 4 len 48
clock_filter: n 3 off 13831.040362 del 0.020376 dsp 1.937516 jit 0.005238
transmit: at 7 192.168.1.2->217.114.59.3 mode 3 len 48
transmit: at 7 192.168.1.2->109.74.206.120 mode 3 len 48
receive: at 7 192.168.1.2<-109.74.206.120 mode 4 len 48
clock_filter: n 3 off 13831.037870 del 0.016378 dsp 1.937516 jit 0.000859
receive: at 7 192.168.1.2<-217.114.59.3 mode 4 len 48
clock_filter: n 4 off 13831.039463 del 0.025397 dsp 0.937522 jit 0.000744
select: combine offset 13831.039462860 jitter 0.000000000
event at 7 217.114.59.3 903a 8a sys_peer
clock_update: at 7 sample 7 associd 13069
step_systime: step 13831.039463 residual 0.000000
In ntp_set_tod
ntp_set_tod: clock_settime: 0: Success
ntp_set_tod: Final result: clock_settime: 0: Success
26 Jul 21:53:00 ntpd[2155]: ntpd: time set +13831.039463 s
ntpd: time set +13831.039463s
root@ws1:~# date
Thu Jul 26 21:53:03 BST 2012
root@ws1:~#
Notice the difference?
 
Old 07-26-2012, 04:59 PM   #29
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 432
Blog Entries: 4

Rep: Reputation: 438Reputation: 438Reputation: 438Reputation: 438Reputation: 438
Quote:
Originally Posted by GazL View Post
To work around this you can run the deprecated 'ntpdate' command
The command you are looking for is

Code:
sntp -s pool.ntp.org
It's not deprecated and you can run it when ntpd is already running.
 
1 members found this post helpful.
Old 07-26-2012, 05:08 PM   #30
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
Thanks for that 55020, I suppose another alternative would have been to have a separate config file without the localclock and do
ntpd -q -g -c alternative.cfg && ntpd but thanks for the tip about sntp.


BTW, update to the above. I tried the clocksource=acpi_pm but it didn't help. I'm content enough to run without the local clock reference though so I don't really care, but I must admit I'm curious why it's not working.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
NTPd slackamp Slackware 1 12-26-2006 03:39 PM
ntpd seitan Linux - Software 1 11-29-2004 06:30 AM
ntpd jqcaducifer Linux - General 0 08-22-2003 12:09 AM
ntpd in RH 7.3 melissad Linux - Networking 4 04-28-2003 01:34 PM
ntpd susx Linux - Newbie 3 08-28-2001 05:18 PM


All times are GMT -5. The time now is 08:22 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration