Re: [gentoo-user] NTP problem

2006-02-22 Thread Brandon Enright
On Wed, 2006-02-22 at 01:32 -0600, Anthony E. Caudel wrote:
 My system was off about 10 days and when I turned it back on, I began
 getting these messages in my logwatch:
 
 Time Reset
time stepped -0.133773
time stepped -0.662954
time stepped +0.271164
time stepped +0.461200
time stepped -0.787647
 snip
 
  Time Reset 25 times (total: -1.239782 s  average: -0.049591 s)
 
  **Unmatched Entries**
  synchronized to 80.35.31.228, stratum 3
  synchronized to 80.35.31.228, stratum 4
 snip
  synchronized to 80.35.31.228, stratum 4
  synchronized to 80.35.31.228, stratum 3
  Listening on interface wildcard, 0.0.0.0#123
  Listening on interface eth0, 192.168.1.100#123
  Listening on interface lo, 127.0.0.1#123
  kernel time sync status 0040
 
 I rebooted thinking it needed to stabilize but it still gets them. I
 have ntp-client and ntpd both in the default runlevel.
 
 This seems like an awful high number of resets.  Much more than I used
 to get.
 
 Tony


Those are some pretty big jumps.  What does ntpq -c peers and ntpq -c
rv output?  Also, what are the first few lines (the restrict entries)
of your ntp.conf?

Brandon

-- 
Brandon Enright
UCSD ACS/Network Operations
[EMAIL PROTECTED]

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] NTP problem

2006-02-22 Thread Anthony E. Caudel
Brandon Enright wrote:
 On Wed, 2006-02-22 at 01:32 -0600, Anthony E. Caudel wrote:
 
My system was off about 10 days and when I turned it back on, I began
getting these messages in my logwatch:

Time Reset
   time stepped -0.133773
   time stepped -0.662954
   time stepped +0.271164
   time stepped +0.461200
   time stepped -0.787647
snip

 Time Reset 25 times (total: -1.239782 s  average: -0.049591 s)

 **Unmatched Entries**
 synchronized to 80.35.31.228, stratum 3
 synchronized to 80.35.31.228, stratum 4
snip
 synchronized to 80.35.31.228, stratum 4
 synchronized to 80.35.31.228, stratum 3
 Listening on interface wildcard, 0.0.0.0#123
 Listening on interface eth0, 192.168.1.100#123
 Listening on interface lo, 127.0.0.1#123
 kernel time sync status 0040

I rebooted thinking it needed to stabilize but it still gets them. I
have ntp-client and ntpd both in the default runlevel.

This seems like an awful high number of resets.  Much more than I used
to get.

Tony
 
 
 
 Those are some pretty big jumps.  What does ntpq -c peers and ntpq -c
 rv output?  Also, what are the first few lines (the restrict entries)
 of your ntp.conf?
 
 Brandon
 
ntpq -c peers:

  remote refid  st t when poll reach   delay   offset jitter
==
*ntp3.usv.ro .PPS.  1 u   70 1024  377  203.0807.338   1.485

ntpq -rv:

assID=0 status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg,
version=ntpd [EMAIL PROTECTED] Thu Dec  8 09:35:31 CST 2005 (1)?,
processor=i686, system=Linux/2.6.15-gentoo-r1, leap=00, stratum=2,
precision=-20, rootdelay=203.080, rootdispersion=34.319, peer=35268,
refid=80.96.120.249,
reftime=c7a69e5a.a3227d02  Wed, Feb 22 2006  2:24:58.637, poll=10,
clock=0xc7a6a0b6.78a5bd94, state=4, offset=7.338, frequency=35.514,
noise=2.162, jitter=0.891, stability=64.582

ntp.conf:

restrict default nomodify nopeer
restrict 127.0.0.1

Tony
-- 
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
   -- Benjamin Franklin
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] NTP problem

2006-02-22 Thread Brandon Enright
On Wed, 2006-02-22 at 02:41 -0600, Anthony E. Caudel wrote:
 Brandon Enright wrote:
  On Wed, 2006-02-22 at 01:32 -0600, Anthony E. Caudel wrote:
  
 My system was off about 10 days and when I turned it back on, I began
 getting these messages in my logwatch:
 
 Time Reset
time stepped -0.133773
time stepped -0.662954
time stepped +0.271164
time stepped +0.461200
time stepped -0.787647
 snip
 
  Time Reset 25 times (total: -1.239782 s  average: -0.049591 s)
 
  **Unmatched Entries**
  synchronized to 80.35.31.228, stratum 3
  synchronized to 80.35.31.228, stratum 4
 snip
  synchronized to 80.35.31.228, stratum 4
  synchronized to 80.35.31.228, stratum 3
  Listening on interface wildcard, 0.0.0.0#123
  Listening on interface eth0, 192.168.1.100#123
  Listening on interface lo, 127.0.0.1#123
  kernel time sync status 0040
 
 I rebooted thinking it needed to stabilize but it still gets them. I
 have ntp-client and ntpd both in the default runlevel.
 
 This seems like an awful high number of resets.  Much more than I used
 to get.
 
 Tony
  
  
  
  Those are some pretty big jumps.  What does ntpq -c peers and ntpq -c
  rv output?  Also, what are the first few lines (the restrict entries)
  of your ntp.conf?
  
  Brandon
  
 ntpq -c peers:
 
   remote refid  st t when poll reach   delay   offset jitter
 ==
 *ntp3.usv.ro .PPS.  1 u   70 1024  377  203.0807.338   1.485
 
 ntpq -rv:
 
 assID=0 status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg,
 version=ntpd [EMAIL PROTECTED] Thu Dec  8 09:35:31 CST 2005 (1)?,
 processor=i686, system=Linux/2.6.15-gentoo-r1, leap=00, stratum=2,
 precision=-20, rootdelay=203.080, rootdispersion=34.319, peer=35268,
 refid=80.96.120.249,
 reftime=c7a69e5a.a3227d02  Wed, Feb 22 2006  2:24:58.637, poll=10,
 clock=0xc7a6a0b6.78a5bd94, state=4, offset=7.338, frequency=35.514,
 noise=2.162, jitter=0.891, stability=64.582
 
 ntp.conf:
 
 restrict default nomodify nopeer
 restrict 127.0.0.1
 
 Tony


So from your output a couple issues stick out.  You're only peering with
one machine which generally doesn't work so well.  You're probably
better off just using ntpdate periodically if you are only going to
sample one server.

Also, the delay on the server you are polling is over 200 ms.  I'm not
sure where ntp3.usv.ro is located but it is over 260ms for me too.  With
this high network delay, slight network jitter can make your clock think
it is way off.  Your machine thinks it is 7.3 ms off.  If you had more
servers to peer with and *much* lower average delay between those
servers your clock would stabilize.  As it stands now, you clock
probably won't ever stabilize because your network is the primary source
of uncertainty.

For comparison, here is my ntpq -c rv output:

assID=0 status=06f4 leap_none, sync_ntp, 15 events,
event_peer/strat_chg,
version=ntpd [EMAIL PROTECTED] Mon Oct 17 21:31:52 PDT 2005 (1)?,
processor=i686, system=Linux/2.6.10-gentoo-r6, leap=00, stratum=2,
precision=-20, rootdelay=21.642, rootdispersion=41.662, peer=12542,
refid=132.249.20.88,
reftime=c7a70d4a.975935fc  Wed, Feb 22 2006 16:18:18.591, poll=10,
clock=0xc7a70dc0.a5847f56, state=4, offset=-0.007, frequency=-31.438,
noise=1.052, jitter=2.529, stability=3.132

Notice my offset is pretty marginal and rootdelay is rather low.  If you
can get your root delay down you should see your offset and stability
improve.

Brandon

-- 
Brandon Enright
UCSD ACS/Network Operations
[EMAIL PROTECTED]

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] NTP problem

2006-02-22 Thread Anthony E. Caudel
Brandon Enright wrote:

 
 So from your output a couple issues stick out.  You're only peering with
 one machine which generally doesn't work so well.  You're probably
 better off just using ntpdate periodically if you are only going to
 sample one server.
 
 Also, the delay on the server you are polling is over 200 ms.  I'm not
 sure where ntp3.usv.ro is located but it is over 260ms for me too.  With
 this high network delay, slight network jitter can make your clock think
 it is way off.  Your machine thinks it is 7.3 ms off.  If you had more
 servers to peer with and *much* lower average delay between those
 servers your clock would stabilize.  As it stands now, you clock
 probably won't ever stabilize because your network is the primary source
 of uncertainty.
 
 For comparison, here is my ntpq -c rv output:
 
 assID=0 status=06f4 leap_none, sync_ntp, 15 events,
 event_peer/strat_chg,
 version=ntpd [EMAIL PROTECTED] Mon Oct 17 21:31:52 PDT 2005 (1)?,
 processor=i686, system=Linux/2.6.10-gentoo-r6, leap=00, stratum=2,
 precision=-20, rootdelay=21.642, rootdispersion=41.662, peer=12542,
 refid=132.249.20.88,
 reftime=c7a70d4a.975935fc  Wed, Feb 22 2006 16:18:18.591, poll=10,
 clock=0xc7a70dc0.a5847f56, state=4, offset=-0.007, frequency=-31.438,
 noise=1.052, jitter=2.529, stability=3.132
 
 Notice my offset is pretty marginal and rootdelay is rather low.  If you
 can get your root delay down you should see your offset and stability
 improve.
 
 Brandon
 

Well, overnight it only reset twice; - some improvement!

Here is my complete ntp.conf:


# NOTES:
#  - you should only have to update the server line below
#  - if you start getting lines like 'restrict' and 'fudge'
#and you didnt add them, AND you run dhcpcd on your
#network interfaces, be sure to add '-Y -N' to the
#dhcpcd_ethX variables in /etc/conf.d/net

# Name of the servers ntpd should sync with
# Please respect the access policy as stated by the responsible person.
#server ntp.example.tld iburst

server pool.ntp.org

##
# A list of available servers can be found here:
# http://www.pool.ntp.org/
# http://www.pool.ntp.org/#use
# A good way to get servers for your machine is:
# netselect -s 3 pool.ntp.org
##

# you should not need to modify the following paths
driftfile   /var/lib/ntp/ntp.drift

#server ntplocal.example.com prefer
#server timeserver.example.org

# Warning: Using default NTP settings will leave your NTP
# server accessible to all hosts on the Internet.

# If you want to deny all machines (including your own)
# from accessing the NTP server, uncomment:
#restrict default ignore


# To deny other machines from changing the
# configuration but allow localhost:
restrict default nomodify nopeer
restrict 127.0.0.1


# To allow machines within your network to synchronize
# their clocks with your server, but ensure they are
# not allowed to configure the server or used as peers
# to synchronize against, uncomment this line.
#
#restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap
---

Notice I'm using pool.ntp.org. I thought that picked a random server.
In any event, I restarted ntpd and it picked a different server.

ntpq -c peers is now:
--
remote  refid  st t when poll reach   delay   offset  jitter
==
*Time2.Stupi.SE  .PPS   1 u   33   64  177  159.568   -4.188   5.881
--

We'll see how this works out.

Tony
-- 
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
   -- Benjamin Franklin
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] NTP problem

2006-02-22 Thread Boyd Stephen Smith Jr.
On Wednesday 22 February 2006 12:38, Anthony E. Caudel 
[EMAIL PROTECTED] wrote about 'Re: [gentoo-user] NTP problem':
 Brandon Enright wrote:
 Well, overnight it only reset twice; - some improvement!

 Here is my complete ntp.conf:
 # Name of the servers ntpd should sync with
 # Please respect the access policy as stated by the responsible person.
 #server ntp.example.tld iburst

 server pool.ntp.org

This chooses a single random server from the pool to sync with, which is 
probably not /exactly/ what you want.

You have a few alternatives:
1) Change server to servers.  Then, ntpd will use all the IPs 
associated with the domain name.  As part of the process of syncing it 
will invalidate peers that have long or volatile round-trip times.  It 
will, however, try to connect to 100s (IIRC) of IPs initially.

2) Use:
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

In this case, the daemon will only use the first address from each domain 
name.  n.pool.ntp.org (for n = 0-9, IIRC) resolves to the same addresses 
as pool.ntp.org, but the primary address you get back is different each 
time.  (I believe the n. prefix is an attempt to prevent local caching, 
which would be a problem if you just repeated your server line 3 times.)

You'll get better times syncing off multiple servers because the daemon can 
use some statistics to remove some of the network latency issues.  
However, you could still get a bad draw and get 3 servers far away from 
you.

3) Follow this comment from *your* .conf file:
 # A good way to get servers for your machine is:
 # netselect -s 3 pool.ntp.org

netselect is available from portage, and I think it's generally installed 
during your gentoo install as a dependency of mirrorselect.  In any case, 
you can use it to find 3 (or however many you want to use) servers close 
to you.

Unfortunately, with this method, if better peers are added to the pool, the 
network topology changes, or anything else to invalidate the quality of 
the peers you pick, ntpd won't be able to automagically pick better ones.

Also, for any of these options, you should note the geographic sub-pools 
that are available.  I use us.pool.ntp.org.  For (1) this will reduce the 
number of IPs initially connected to, for (2) it will increase the chance 
that you don't get a bad draw (because, generally, geographically closer 
is closer on the network), for (3) ... Well, actually for 3 you might as 
well pick the best ones from the entire pool.

-- 
Boyd Stephen Smith Jr.
[EMAIL PROTECTED]
ICQ: 514984 YM/AIM: DaTwinkDaddy
-- 
gentoo-user@gentoo.org mailing list



RE: [gentoo-user] NTP problem

2006-02-22 Thread Brandon Enright
Anthony E. Caudel wrote:
 Brandon Enright wrote:
 
 
  So from your output a couple issues stick out.  You're only peering with
  one machine which generally doesn't work so well.  You're probably
  better off just using ntpdate periodically if you are only going to
  sample one server.
 
  Also, the delay on the server you are polling is over 200 ms.  I'm not
  sure where ntp3.usv.ro is located but it is over 260ms for me too.  With
  this high network delay, slight network jitter can make your clock think
  it is way off.  Your machine thinks it is 7.3 ms off.  If you had more
  servers to peer with and *much* lower average delay between those
  servers your clock would stabilize.  As it stands now, you clock
  probably won't ever stabilize because your network is the primary source
  of uncertainty.
 
  For comparison, here is my ntpq -c rv output:
 
  assID=0 status=06f4 leap_none, sync_ntp, 15 events,
  event_peer/strat_chg,
  version=ntpd [EMAIL PROTECTED] Mon Oct 17 21:31:52 PDT 2005 (1)?,
  processor=i686, system=Linux/2.6.10-gentoo-r6, leap=00, stratum=2,
  precision=-20, rootdelay=21.642, rootdispersion=41.662, peer=12542,
  refid=132.249.20.88,
  reftime=c7a70d4a.975935fc  Wed, Feb 22 2006 16:18:18.591, poll=10,
  clock=0xc7a70dc0.a5847f56, state=4, offset=-0.007, frequency=-31.438,
  noise=1.052, jitter=2.529, stability=3.132
 
  Notice my offset is pretty marginal and rootdelay is rather low.  If you
  can get your root delay down you should see your offset and stability
  improve.
 
  Brandon
 
 
 Well, overnight it only reset twice; - some improvement!
 
 Here is my complete ntp.conf:
 
 
 # NOTES:
 #  - you should only have to update the server line below
 #  - if you start getting lines like 'restrict' and 'fudge'
 #and you didnt add them, AND you run dhcpcd on your
 #network interfaces, be sure to add '-Y -N' to the
 #dhcpcd_ethX variables in /etc/conf.d/net
 
 # Name of the servers ntpd should sync with
 # Please respect the access policy as stated by the responsible person.
 #server ntp.example.tld iburst
 
 server pool.ntp.org
 
 ##
 # A list of available servers can be found here:
 # http://www.pool.ntp.org/
 # http://www.pool.ntp.org/#use
 # A good way to get servers for your machine is:
 # netselect -s 3 pool.ntp.org
 ##
 
 # you should not need to modify the following paths
 driftfile   /var/lib/ntp/ntp.drift
 
 #server ntplocal.example.com prefer
 #server timeserver.example.org
 
 # Warning: Using default NTP settings will leave your NTP
 # server accessible to all hosts on the Internet.
 
 # If you want to deny all machines (including your own)
 # from accessing the NTP server, uncomment:
 #restrict default ignore
 
 
 # To deny other machines from changing the
 # configuration but allow localhost:
 restrict default nomodify nopeer
 restrict 127.0.0.1
 
 
 # To allow machines within your network to synchronize
 # their clocks with your server, but ensure they are
 # not allowed to configure the server or used as peers
 # to synchronize against, uncomment this line.
 #
 #restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap
 ---
 
 Notice I'm using pool.ntp.org. I thought that picked a random server.
 In any event, I restarted ntpd and it picked a different server.
 
 ntpq -c peers is now:
 --
 
 remote  refid  st t when poll reach   delay   offset  jitter
 ==
 
 *Time2.Stupi.SE  .PPS   1 u   33   64  177  159.568   -4.188   5.881
 --
 
 
 We'll see how this works out.
 
 Tony

I can't speak for others but my experience with pool.ntp.org has been very
poor.  Some of the servers are close by and low latency and others are in
far off lands.

You may want to see if you can peer with a local university, military base,
ISP, or company in addition to pool.ntp.org.  There is a lot to say for
reliable average latency over your list of peers.  Adding a few more will
really help out.

Brandon

-- 
Brandon Enright
UCSD ACS/Network Operations
[EMAIL PROTECTED]

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] NTP problem

2006-02-22 Thread Boyd Stephen Smith Jr.
On Wednesday 22 February 2006 13:13, Brandon Enright [EMAIL PROTECTED] 
wrote about 'RE: [gentoo-user] NTP problem':
 Anthony E. Caudel wrote:
 I can't speak for others but my experience with pool.ntp.org has been
 very poor.  Some of the servers are close by and low latency and others
 are in far off lands.

I've never had a problem, but I use one of the geographic sub-pools.

 You may want to see if you can peer with a local university, military
 base, ISP, or company in addition to pool.ntp.org.  There is a lot to
 say for reliable average latency over your list of peers.  Adding a few
 more will really help out.

That's true.  Also, many ISPs run an NTP server and it's either poorly (or 
purposely not) advertised.  Check ntp.your isp here to see if it'll peer 
with you, since it'll probably be about as close as you can get network 
wise.  Heck, they don't advertise it (AFAICT) but the first upstream IP 
from my cable modem has an ntpd listening and you definitely can't get any 
closer than that.

-- 
Boyd Stephen Smith Jr.
[EMAIL PROTECTED]
ICQ: 514984 YM/AIM: DaTwinkDaddy
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread krzaq
On 8/23/05, Bruno Lustosa [EMAIL PROTECTED] wrote:
 Hello. I'm running ntpd as server on one of my machines, and it keeps
 itself in sync with 6 time servers around the globe. The
 synchronization works very well.
 The problem is when I try to get the other machines on the network to
 sync themselves with this one server. Most of them are running linux
 (kernel 2.6.x), but some are still running windows.
 Some machines can sync fine, and some don't. All of them can reach the
 server (same network), and there is no firewall at all.
 This is the output I get from ntpq on the machines that don't work:
 
 ntpq peers
  remote   refid  st t when poll reach   delay   offset  jitter
 ==
  timeserver 217.160.252.229  3 u   26   64  3770.214  46927.6 716.379
 ntpq assoc
 
 ind assID status  conf reach auth condition  last_event cnt
 ===
   1 15036  9064   yes   yes  nonereject   reachable  6
 
 The only differences between this one and another machines where it's
 working fine are the status code (it varies a bit) and the condition
 (instead of reject, sys.peer).
 The ntp.conf for all machines have just:
 
 server 192.168.7.1
 
 which is the ip address of the time server in question.
 I don't know the internals of ntp. What can be wrong in my configuration?

I am no NTP expert, but there may be nothing wrong with your configuartion.
NTP is a complex protocol. The machine has decided not to sync
with the requested server. It thinks that the provided server is inacurate (the
machine's internal clock is more acurate).

Leave it running a couple of days and then see what happens.

The whole idea is to calculate the drift of the machines internal
clock. NTP will
not trust specified timeservers blindly.

Frankly I think that ntp works best with several timeservers.
If you want your local machines to blindly set the date to your local timeserver
try nptdate instead.

-- 
Regards
Karol Krzak

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread Bruno Lustosa
On 8/23/05, kashani [EMAIL PROTECTED] wrote:
 That offset looks rather large. NTP really wants to make constant small
 changes, not a single huge change. This is why the ntpd setup allows for
 an immediate sync via ntpdate before starting the daemon. To fix this
 I'd shut down ntpd, run ntpdate 192.168.7.1, and then start ntpd again.

That's what I did yesterday before leaving work. It synced with
ntpdate, and I left ntpd running. Today, the offset was like that.
That's what I don't understand.

-- 
Bruno Lustosa, aka Lofofora  | Email: [EMAIL PROTECTED]
Network Administrator/Web Programmer | ICQ: 1406477
Rio de Janeiro - Brazil  |

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread kashani

Bruno Lustosa wrote:

Hello. I'm running ntpd as server on one of my machines, and it keeps
itself in sync with 6 time servers around the globe. The
synchronization works very well.
The problem is when I try to get the other machines on the network to
sync themselves with this one server. Most of them are running linux
(kernel 2.6.x), but some are still running windows.
Some machines can sync fine, and some don't. All of them can reach the
server (same network), and there is no firewall at all.
This is the output I get from ntpq on the machines that don't work:

ntpq peers
 remote   refid  st t when poll reach   delay   offset  jitter
==
 timeserver 217.160.252.229  3 u   26   64  3770.214  46927.6 716.379
ntpq assoc

ind assID status  conf reach auth condition  last_event cnt
===
  1 15036  9064   yes   yes  nonereject   reachable  6

The only differences between this one and another machines where it's
working fine are the status code (it varies a bit) and the condition
(instead of reject, sys.peer).
The ntp.conf for all machines have just:

server 192.168.7.1

which is the ip address of the time server in question.
I don't know the internals of ntp. What can be wrong in my configuration?


That offset looks rather large. NTP really wants to make constant small 
changes, not a single huge change. This is why the ntpd setup allows for 
an immediate sync via ntpdate before starting the daemon. To fix this 
I'd shut down ntpd, run ntpdate 192.168.7.1, and then start ntpd again.


kashani
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread Uwe Thiem
On 23 August 2005 13:36, Bruno Lustosa wrote:
 Hello. I'm running ntpd as server on one of my machines, and it keeps
 itself in sync with 6 time servers around the globe. The
 synchronization works very well.
 The problem is when I try to get the other machines on the network to
 sync themselves with this one server. Most of them are running linux
 (kernel 2.6.x), but some are still running windows.
 Some machines can sync fine, and some don't. All of them can reach the
 server (same network), and there is no firewall at all.
 This is the output I get from ntpq on the machines that don't work:

 ntpq peers
  remote   refid  st t when poll reach   delay   offset 
 jitter
 ===
=== timeserver 217.160.252.229  3 u   26   64  3770.214  46927.6
^^^
This isn't 192.158.7.1.

 716.379 ntpq assoc

 ind assID status  conf reach auth condition  last_event cnt
 ===
   1 15036  9064   yes   yes  nonereject   reachable  6

 The only differences between this one and another machines where it's
 working fine are the status code (it varies a bit) and the condition
 (instead of reject, sys.peer).
 The ntp.conf for all machines have just:

 server 192.168.7.1

This one should be the only peer of your inside boxes, no?

Uwe

-- 
95% of all programmers rate themselves among the top 5% of all software 
developers. - Linus Torvalds

http://www.uwix.iway.na (last updated: 20.06.2004)
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread krzaq
On 8/23/05, Bruno Lustosa [EMAIL PROTECTED] wrote:
 On 8/23/05, kashani [EMAIL PROTECTED] wrote:
  That offset looks rather large. NTP really wants to make constant small
  changes, not a single huge change. This is why the ntpd setup allows for
  an immediate sync via ntpdate before starting the daemon. To fix this
  I'd shut down ntpd, run ntpdate 192.168.7.1, and then start ntpd again.
 
 That's what I did yesterday before leaving work. It synced with
 ntpdate, and I left ntpd running. Today, the offset was like that.
 That's what I don't understand.
H...
If you specify one timeserver, ntp cannot tell which clock is drifting
away (local
or remote). Ntpd trusts the local clock more than the remote one.
Large offsets cause ntpd to discard 192.168.7.1 as reliable timesource.
Try adding on this one machine more time servers and observe what will happen.

-- 
Regards
Karol Krzak

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread Bruno Lustosa
Just as a sidenote. My machine is running dhcpcd, and it sometimes
overwrites /etc/ntp.conf for some reason, even though I have
'dhcpcd_eth0=-N' on /etc/conf.d/net.
I don't know how to make dhcpcd leave /etc/ntp.conf alone OR make it
write a correct ntp.conf (without a bunch of 'restrict' lines).

-- 
Bruno Lustosa, aka Lofofora  | Email: [EMAIL PROTECTED]
Network Administrator/Web Programmer | ICQ: 1406477
Rio de Janeiro - Brazil  |

-- 
gentoo-user@gentoo.org mailing list



RE: [gentoo-user] ntp problem

2005-08-23 Thread Michael Kintzios


 -Original Message-
 From: Bruno Lustosa [mailto:[EMAIL PROTECTED] 
 Sent: 23 August 2005 15:30
 To: gentoo-user@lists.gentoo.org
 Subject: Re: [gentoo-user] ntp problem
 
 
 On 8/23/05, Uwe Thiem [EMAIL PROTECTED] wrote:
  timeserver 217.160.252.229  3 u   26   64  3770.214  46927.6
  ^^^
  This isn't 192.158.7.1.
 
 Yes, I know. This is the external reference ntp server used by the
 timeserver, not by the client. This ip is on the server's ntp.conf.
 
   server 192.168.7.1
  
  This one should be the only peer of your inside boxes, no?
 
 Yes, it's the only one.

Have you set all the internal clients up as stratum 3, your internal
server as stratum 2 and your external reference timeservers as stratum
1?
-- 
Regards,
Mick

-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] ntp problem

2005-08-23 Thread Bruno Lustosa
On 8/23/05, Michael Kintzios [EMAIL PROTECTED] wrote:
 Have you set all the internal clients up as stratum 3, your internal
 server as stratum 2 and your external reference timeservers as stratum
 1?

No, but do I have to do this manually?
It seems ntp can discover the stratum of the servers by itself.
I have put all the servers I was using in my local server in one
workstation, and am monitoring it now. It seems it's always picking
one of them as peer, though it varies a lot.

-- 
Bruno Lustosa, aka Lofofora  | Email: [EMAIL PROTECTED]
Network Administrator/Web Programmer | ICQ: 1406477
Rio de Janeiro - Brazil  |

-- 
gentoo-user@gentoo.org mailing list



Re: Re: [gentoo-user] ntp problem

2005-08-23 Thread Michael Kintzios
 From:: Bruno Lustosa [EMAIL PROTECTED]
 To: gentoo-user@lists.gentoo.org
 Subject: Re: [gentoo-user] ntp problem
 Date: Tue, 23 Aug 2005 14:50:43 -0300

 On 8/23/05, Michael Kintzios [EMAIL PROTECTED] wrote:
  Have you set all the internal clients up as stratum 3, your internal
  server as stratum 2 and your external reference timeservers as stratum
  1?
 
 No, but do I have to do this manually?
 It seems ntp can discover the stratum of the servers by itself.
 I have put all the servers I was using in my local server in one
 workstation, and am monitoring it now. It seems it's always picking
 one of them as peer, though it varies a lot.

I'm not the best man to advise on ntp (because I don't use it), but that's what 
I remember being recommended by a developer in the forums.  May be you want to 
do a quick search there on time synchro or something like that.
-- 
Regards,
Mick

Lycos email has now 300 Megabytes of free storage... Get it now at 
mail.lycos.co.uk