Re: [ntp:questions] Syncing to nearby vs. faraway servers

Unruh wrote: > John Hasler writes: > >> Richard B. Gilbert writes: >>> Country pools were a good start and probably adequate for small >>> countries. Countries the size of the U.S. or the U.S.S.R. can't use a >>> country wide pool and have much hope of getting a nearby server. For the >>> U.S.

Re: [ntp:questions] ntpdate

A few basic usage questions: 1) Running `ntpd -qgd` as a non root users returns nothing. It appears to immediately exit. Is this correct behavior, or should I get some warning message to change users? 2) `ntpdate -u` on the other hand, does warn me: 16 Jun 12:29:09 ntpdate[43457]: step-syst

Re: [ntp:questions] ntpdate

On Jun 15, 2009, at 7:59 PM, Brad Knowles wrote: > Well, I wrote the page that was originally at > >, but it Great read, thanks for that. > seems that there have been a few updates by other authors since > then. It does

Re: [ntp:questions] Syncing to nearby vs. faraway servers

Rich Wales wrote: > Richard B. Gilbert wrote: > >> The "Delay" values for some of the servers you have configured >> are large enough to suggest that they are poor choices! > > Agreed. Please note, though, that I didn't explicitly choose > these particular servers -- they came from pools. > > T

Re: [ntp:questions] ntpdate

[snip... about audit trail and a bit of a debate ...] On Jun 16, 2009, at 9:57 AM, Danny Mayer wrote: > Not at all. We have SOX processes everywhere at work. None of them > require accurate time since they are not needed. What is needed is a > clear audit trail of what did what. > > Don't try

Re: [ntp:questions] Syncing to nearby vs. faraway servers

> As for grandfather's two stratum-1 backup servers, here's the current > info on bigben.cac.washington.edu: > > ntpq> host > current host is bigben.cac.washington.edu > ntpq> peers >     remote           refid      st t when poll reach   delay   offset  jitter > ===

Re: [ntp:questions] Syncing to nearby vs. faraway servers

Replying to Bill Unruh: > If the Stanford machines all cluster around a time server milliseconds > different from the rest of the world they are wrong. Stanford's stratum-2 servers currently appear to be syncing to grandfather.stanford.edu (171.64.7.87) -- a stratum-1 server which is located here

Re: [ntp:questions] ntpdate

Todd Glassey CISM CIFI wrote: > Danny Mayer wrote: >> Todd Glassey CISM CIFI wrote: >> >>> Danny Mayer wrote: >>> tglassey wrote: > Danny Mayer wrote: > >> Scott Haneda wrote: >> >> >>> On Jun 15, 2009, at 8:59 AM, Tod

Re: [ntp:questions] Syncing to nearby vs. faraway servers

John Hasler writes: >Richard B. Gilbert writes: >> Country pools were a good start and probably adequate for small >> countries. Countries the size of the U.S. or the U.S.S.R. can't use a >> country wide pool and have much hope of getting a nearby server. For the >> U.S. I'd want a "New Englan

Re: [ntp:questions] Cannot sync on embedded PPC running Linux

Andrea, gizero wrote: > I'm trying to run ntpd 4.2.4p7 on a ppc embedded system running Linux/ > 2.6.24.6. I'm not very accustomed to using NTP daemon, hence I'm > looking for some help in debugging the system, which appear to be > unable to sync with a public NTP server. [...] > What make me susp

Re: [ntp:questions] Cannot sync on embedded PPC running Linux

gizero wrote: > I'm trying to run ntpd 4.2.4p7 on a ppc embedded system running Linux/ > 2.6.24.6. I'm not very accustomed to using NTP daemon, hence I'm > looking for some help in debugging the system, which appear to be > unable to sync with a public NTP server. > > ntptime is always reporting t

Re: [ntp:questions] Cannot sync on embedded PPC running Linux

"Richard B. Gilbert" wrote: > gizero wrote: > > # You do need to talk to an NTP server or two (or three). > > server it.pool.ntp.org > Ideally you should be using a minimum of four servers but you have > configured only one. > > If possible, add three more servers to your configuration. Resta

Re: [ntp:questions] Syncing to nearby vs. faraway servers

Richard B. Gilbert writes: > Country pools were a good start and probably adequate for small > countries. Countries the size of the U.S. or the U.S.S.R. can't use a > country wide pool and have much hope of getting a nearby server. For the > U.S. I'd want a "New England pool", a "middle Atlantic

[ntp:questions] Cannot sync on embedded PPC running Linux

I'm trying to run ntpd 4.2.4p7 on a ppc embedded system running Linux/ 2.6.24.6. I'm not very accustomed to using NTP daemon, hence I'm looking for some help in debugging the system, which appear to be unable to sync with a public NTP server. ntptime is always reporting the following (this is afte

Re: [ntp:questions] Syncing to nearby vs. faraway servers

Rich Wales wrote: > Richard B. Gilbert wrote: > >> The "Delay" values for some of the servers you have configured >> are large enough to suggest that they are poor choices! > > Agreed. Please note, though, that I didn't explicitly choose > these particular servers -- they came from pools. > > T

Re: [ntp:questions] ntpdate

Todd Glassey CISM CIFI wrote: > Danny Mayer wrote: >> tglassey wrote: >> >>> Danny Mayer wrote: >>> Scott Haneda wrote: > On Jun 15, 2009, at 8:59 AM, Todd Glassey CISM CIFI wrote: > > >>> You should be running ntpd as a daemon. That will keep

Re: [ntp:questions] Syncing to nearby vs. faraway servers

Rich writes: >I'm running ntpd 4.2.4p4 on several Ubuntu 9.04 ("Jaunty") servers. >I'm associated with Stanford University and have been depending >primarily on Stanford's own pool of stratum-2 servers. >Recently, in order to spread out my time base somewhat, I tried adding >some outside servers

Re: [ntp:questions] Stratum 1 servers in pools?!?

Rich writes: >I'm using ntpd 4.2.4p4 on several Ubuntu 9.04 ("Jaunty") servers. >Recently, I've been reconfiguring some of my servers to use the "pool" >DNS names (e.g., "server 0.us.pool.ntp.org"). I've noticed that I >sometimes end up associating with a stratum-1 server from a pool. As >an e

Re: [ntp:questions] Syncing to nearby vs. faraway servers

Rich Wales wrote: > Richard B. Gilbert wrote: > > The "Delay" values for some of the servers you have configured > > are large enough to suggest that they are poor choices! > > Agreed. Please note, though, that I didn't explicitly choose > these particular servers -- they came from pools. > >