On Friday 26 October 2018 09:53:39 Greg Wooledge wrote:
> On Fri, Oct 26, 2018 at 09:29:38AM -0400, Gene Heskett wrote:
> > and it goes out on the net and checks
> > all servers before ntpq -p is completed, take 5 or 6 seconds to do
> > that,
>
> That's DNS resolution. It's looking up the IP addr
On Fri, Oct 26, 2018 at 09:44:47AM -0400, Gene Heskett wrote:
As I'm fond of saying TANSTAAFL. If we all, with multiple machine sites,
did this it would make a measureable difference in bandwidth used
If people want to set up local ntp servers, great. But just configure
the clients with a ser
On Fri, Oct 26, 2018 at 09:29:38AM -0400, Gene Heskett wrote:
> and it goes out on the net and checks
> all servers before ntpq -p is completed, take 5 or 6 seconds to do that,
That's DNS resolution. It's looking up the IP addresses so it can
report names to you. If you want to skip that, you
On Friday 26 October 2018 09:01:50 Curt wrote:
> On 2018-10-25, Gene Heskett wrote:
> > Now this machine shows for ntpq -p:
> > remote refid st t when poll reach delay
> > offset jitter
> >
> >==
On Friday 26 October 2018 08:26:47 Greg Wooledge wrote:
> On Thu, Oct 25, 2018 at 05:36:21PM -0400, Gene Heskett wrote:
> > I put the router back on pool.ntp.org, but had to reboot it to take
> > effect.
> >
> > Now this machine shows for ntpq -p:
> > remote refid st t when pol
On 2018-10-25, Gene Heskett wrote:
> Now this machine shows for ntpq -p:
> remote refid st t when poll reach delay offset jitter
>==
> +159.203.158.197 45.33.103.94 3 u 59 643 19.551
On Thu, Oct 25, 2018 at 05:36:21PM -0400, Gene Heskett wrote:
> I put the router back on pool.ntp.org, but had to reboot it to take effect.
>
> Now this machine shows for ntpq -p:
> remote refid st t when poll reach delay offset jitter
> ===
On Thursday 25 October 2018 16:50:11 Greg Wooledge wrote:
> On Thu, Oct 25, 2018 at 04:40:46PM -0400, Gene Heskett wrote:
> > I added the router to the server list for this machine and get this
> > for an ntpq -p: remote refid st t when poll reach
> > delay offset jitter
> > ==
On Thu, Oct 25, 2018 at 04:40:46PM -0400, Gene Heskett wrote:
> I added the router to the server list for this machine and get this for an
> ntpq -p:
> remote refid st t when poll reach delay offset jitter
> ==
On Thursday 25 October 2018 14:08:47 Curt wrote:
> On 2018-10-25, Gene Heskett wrote:
> > On Thursday 25 October 2018 09:32:08 Curt wrote:
> >> On 2018-10-25, Greg Wooledge wrote:
> >> >> 2 machines report:
> >> >> pi@picnc:/etc $ ntpq -p
> >> >> No association ID's returned
> >> >
> >> > I've l
On 2018-10-25, Gene Heskett wrote:
> On Thursday 25 October 2018 09:32:08 Curt wrote:
>
>> On 2018-10-25, Greg Wooledge wrote:
>> >> 2 machines report:
>> >> pi@picnc:/etc $ ntpq -p
>> >> No association ID's returned
>> >
>> > I've literally never seen such a message before. I googled it, and
>>
On Thursday 25 October 2018 09:32:08 Curt wrote:
> On 2018-10-25, Greg Wooledge wrote:
> >> 2 machines report:
> >> pi@picnc:/etc $ ntpq -p
> >> No association ID's returned
> >
> > I've literally never seen such a message before. I googled it, and
> > there are definitely results that look rele
On 2018-10-25, Greg Wooledge wrote:
>> 2 machines report:
>> pi@picnc:/etc $ ntpq -p
>> No association ID's returned
>
> I've literally never seen such a message before. I googled it, and there
> are definitely results that look relevant. After adding "broadcast" to
> the search terms, I came u
On Wed, Oct 24, 2018 at 06:23:49PM -0400, Gene Heskett wrote:
> The idea is to reduce the loading of 7 machines all banging one the level
> 1 and 2 servers by designating one machine to bang of the debian pool,
> and then broadcast it on the local 192.169.xx.xx net so all the others
> stay withi
On Wednesday, October 24, 2018 07:10:00 PM rhkra...@gmail.com wrote:
> On Wednesday, October 24, 2018 06:25:46 PM Gene Heskett wrote:
> > On Wednesday 24 October 2018 11:07:05 rhkra...@gmail.com wrote:
> > > I think that covers what I was going to say, but in an attempt to show
> > > off my knowled
On Wednesday, October 24, 2018 06:25:46 PM Gene Heskett wrote:
> On Wednesday 24 October 2018 11:07:05 rhkra...@gmail.com wrote:
> > I think that covers what I was going to say, but in an attempt to show
> > off my knowledge (or lack thereof) ;-)
> >
> > As I understand it, NTP tries to get an app
On Wednesday 24 October 2018 11:07:05 rhkra...@gmail.com wrote:
> On Wednesday, October 24, 2018 10:27:04 AM john doe wrote:
> > On 10/24/2018 2:44 PM, Greg Wooledge wrote:
> > > On Wed, Oct 24, 2018 at 08:22:49AM -0400, Gene Heskett wrote:
> > >> I has this machine running ntp normally, and set t
On Wednesday 24 October 2018 10:27:04 john doe wrote:
> On 10/24/2018 2:44 PM, Greg Wooledge wrote:
> > On Wed, Oct 24, 2018 at 08:22:49AM -0400, Gene Heskett wrote:
> >> I has this machine running ntp normally, and set to broadcast on
> >> the $local/24 network.
> >
> > I've never used NTP in "br
On Wednesday, October 24, 2018 10:27:04 AM john doe wrote:
> On 10/24/2018 2:44 PM, Greg Wooledge wrote:
> > On Wed, Oct 24, 2018 at 08:22:49AM -0400, Gene Heskett wrote:
> >> I has this machine running ntp normally, and set to broadcast on the
> >> $local/24 network.
> >
> > I've never used NTP i
On 10/24/2018 2:44 PM, Greg Wooledge wrote:
> On Wed, Oct 24, 2018 at 08:22:49AM -0400, Gene Heskett wrote:
>> I has this machine running ntp normally, and set to broadcast on the
>> $local/24 network.
>
> I've never used NTP in "broadcast" mode.
>
> If it were me, I would simply use the normal
On Wed, Oct 24, 2018 at 08:22:49AM -0400, Gene Heskett wrote:
> I has this machine running ntp normally, and set to broadcast on the
> $local/24 network.
I've never used NTP in "broadcast" mode.
If it were me, I would simply use the normal configuration in which
each client system has the NTP se
I has this machine running ntp normally, and set to broadcast on the
$local/24 network.
I have 6 other machines on this local network, but only 2 are staying
with this machine timewise.
Does anyone have a clue why the other 4 are not, atm up to 35 seconds
diff between them? They all have th
On Sun, 6 Jul 2014, John D. Hendrickson and Sara Darnell wrote:
. . .
when i used it you have to run ntpdate(1) to synchronize before running ntpd
. . .
In my 1st post, I wrote:
=
I tried ntpdate, which actually restabl
On Tue, 01 Jul 2014, Pierre Frenkiel wrote:
> Measuring the battery voltage should give me the answer for my
> configuration. Still remains the un-answered question: what can be the
> cause of this time problem after 5 years of good working, and no
> configuration change?.
For a PC RTC? Damaged
thanks for all your replies (although some are rather contradictory)
1> Very few chances, as this kinda battery can save its load for
1> at least 10 years (except if you had very long periods without
1> pluging your computer).
2> I've never seen one that lasted for 10 years, and I've had to repl
Hi Pierre,
Please post the contents of these files:
/etc/adjtime
/etc/default/adjtimex
/var/lib/ntp/ntp.drift
Thanks!
Rick
On Jun 26, 2014, at 8:08 AM, Pierre Frenkiel wrote:
> On Thu, 26 Jun 2014, Rob Owens wrote:
>
>>> On Wed, 25 Jun 2014, Bob Proulx wrote:
Utilities such as NTP are r
On Thu, Jun 26, 2014 at 05:08:52PM +0200, Pierre Frenkiel wrote:
> On Thu, 26 Jun 2014, Rob Owens wrote:
> >Maybe a cron job running ntpdate?
>
> it's what I did up to now, (ntpdate or rdate), but the drift
> became too big, even with a call in cron.hourly
Do you still have the cron job enab
On Thu, 26 Jun 2014, Rob Owens wrote:
On Wed, 25 Jun 2014, Bob Proulx wrote:
Utilities such as NTP are really good at adjusting the counting per
second to tune the OS view of time to be very accurate. If that isn't
working then I suspect some other problem. Such as two daemons
fighting each o
> On Wed, 25 Jun 2014, Bob Proulx wrote:
> > Utilities such as NTP are really good at adjusting the counting per
> > second to tune the OS view of time to be very accurate. If that isn't
> > working then I suspect some other problem. Such as two daemons
> > fighting each other both trying to adju
On Wed, 25 Jun 2014, Bob Proulx wrote:
> It depends upon the motherboard but most won't draw battery power
Lithium cells don't age just because you drain them, they will also degrade
with time. The fact that they're *always* being drained due to the leakage
current _inside_ the cell (which is rea
Henrique de Moraes Holschuh wrote:
> Pierre Frenkiel wrote:
> > Anyway, the fact that this problem appeared just a few days ago on a
> > machine running since about 5 years seems indicate a hardware
> > problem (battery?)
>
> Yes, the lower "voltage" caused by a dying battery can increase the
> sy
On Wed, 25 Jun 2014 13:30:34 -0300
Henrique de Moraes Holschuh wrote:
> I've never seen one that lasted for 10 years, and I've had to
> replace several CR2032 lithium cells on motherboards that were ~5
> years old. And those were good quality cells, made in Japan.
>
> These cells do age (and di
On Wed, 25 Jun 2014, B wrote:
> On Wed, 25 Jun 2014 09:13:12 +0200 (CEST)
> Pierre Frenkiel wrote:
> > Anyway, the fact that this problem appeared just a few days ago on
> > a machine running since about 5 years seems indicate a hardware
> > problem (battery?)
>
> Very few chances, as this ki
On Wed, 25 Jun 2014, Pierre Frenkiel wrote:
> Anyway, the fact that this problem appeared just a few days ago on a
> machine running since about 5 years seems indicate a hardware
> problem (battery?)
Yes, the lower "voltage" caused by a dying battery can increase the
systematic drift on the RTC, o
On Wednesday 25 June 2014 14:11:29 Curt wrote:
> On 2014-06-25, Lisi Reisz wrote:
> > On Wednesday 25 June 2014 08:13:12 Pierre Frenkiel wrote:
> >> seems indicate a hardware problem (battery?)
> >
> > I nearly said so, but grandmothers and eggs came to mind.
>
> Grandmothers will promptly replac
On 2014-06-25, Lisi Reisz wrote:
> On Wednesday 25 June 2014 08:13:12 Pierre Frenkiel wrote:
>> seems indicate a hardware problem (battery?)
>
> I nearly said so, but grandmothers and eggs came to mind.
Grandmothers will promptly replace a faulty egg?
> CMOS batteries are cheap enough. Why no
On Wed, 25 Jun 2014 09:13:12 +0200 (CEST)
Pierre Frenkiel wrote:
> Anyway, the fact that this problem appeared just a few days ago on
> a machine running since about 5 years seems indicate a hardware
> problem (battery?)
Very few chances, as this kinda battery can save its load for
at least 10 y
On Wed, 25 Jun 2014, Lisi Reisz wrote:
On Wednesday 25 June 2014 08:13:12 Pierre Frenkiel wrote:
seems indicate a hardware problem (battery?)
I nearly said so, but grandmothers and eggs came to mind.
CMOS batteries are cheap enough. Why not just change it and see? It does not
sound unreaso
On Wednesday 25 June 2014 08:13:12 Pierre Frenkiel wrote:
> seems indicate a hardware problem (battery?)
I nearly said so, but grandmothers and eggs came to mind.
CMOS batteries are cheap enough. Why not just change it and see? It does not
sound unreasonable that a battery should be running do
On Tue, 24 Jun 2014, Henrique de Moraes Holschuh wrote:
start ntpd with the '-g' option to fix that (add it to /etc/default/ntp).
That doesn't work, as this option was already in use.
We used to apply drift correction (stored in /etc/adjtime) when we still ran
hctosys / systohc during syst
On Tue, 24 Jun 2014, Pierre Frenkiel wrote:
> ==> ntpq -p
> remote refid st t when poll reach delay offset
> jitter
>
> ==
> outbound-smtp.n 192.93.2.20 2 u 53 64 377 29.858
On Tue, 24 Jun 2014, Darac Marjal wrote:
. . .
ntp_gettime() error 5 is, according to the man page, "TIME_ERROR (clock
not synchronised". So, in that case, look to your ntpd. Run "ntpq -p" to
see the status of your peers and/or "ntpq -c assoc" for more details.
The information there can be compl
On Tue, Jun 24, 2014 at 09:53:07AM +0200, Pierre Frenkiel wrote:
> hi eveybody,
> I recently discovered that the time on my desktop was wrong by several
> minutes,
> although it is running ntpd. On my laptop, which has exactly the same
> ntp.conf,
> the time correct.
> Here are the output of ntpt
hi eveybody,
I recently discovered that the time on my desktop was wrong by several minutes,
although it is running ntpd. On my laptop, which has exactly the same ntp.conf,
the time correct.
Here are the output of ntptime on the 2 machines
laptop:
ntp_gettime() returns code 0 (OK)
time d75
gt; it's possible. Assuming the hardware is ok, I'm surprised a default
>> Debian kernel won't keep time accurately on it. Google didn't spit back
>> any such Debian+DL580 clock issues...
>
> I have a hp DL360 with same kernel, same squeeze 64bit etc. and ther
m surprised a default
> Debian kernel won't keep time accurately on it. Google didn't spit back
> any such Debian+DL580 clock issues...
I have a hp DL360 with same kernel, same squeeze 64bit etc. and there
aren't any issues with ntp how you can see
remote refid st t when pol
On 8/9/2011 6:55 AM, Rick Thomas wrote:
> In many cases, judicious use of "adjtimex" to trim the system clock can
> avoid a system board replacement.
And if the machine is under depot warranty? Better yet, that + on-site
service contract? If it does turn out to be defective hardware, and the
a
On Aug 9, 2011, at 5:41 AM, Stan Hoeppner wrote:
On 8/9/2011 2:40 AM, owl...@gmail.com wrote:
remote refid st t when poll reach delay
offset jitter
=
=
=
=
=
=
=
=
=
=
ntp1.inrim.it .CTD.
On 8/9/2011 2:40 AM, owl...@gmail.com wrote:
> remote refid st t when poll reach delay offset jitter
> ==
> ntp1.inrim.it .CTD.1 u 46 64 377 23.641 329686. 2517.77
> ntp2.inr
2011/8/9 Jerome BENOIT :
> Hell List:
>
> On 09/08/11 09:40, owl...@gmail.com wrote:
>>
>> Hello, the server clock continually recedes as you can see the ntpq -p
>> offset is too high.
>> Setting the right time at hand not solve anything after a while the
>> server clock slowly recedes
>>
>>
>> Any
Hell List:
On 09/08/11 09:40, owl...@gmail.com wrote:
Hello, the server clock continually recedes as you can see the ntpq -p
offset is too high.
Setting the right time at hand not solve anything after a while the
server clock slowly recedes
Any suggestions?
ahve you tried an other server ?
Hello, the server clock continually recedes as you can see the ntpq -p
offset is too high.
Setting the right time at hand not solve anything after a while the
server clock slowly recedes
Any suggestions?
remote refid st t when poll reach delay offset jitter
On Thu, Jul 15, 2004 at 07:47:36AM -0500, John Hasler wrote:
> John Summerfield writes:
> > If you think your ISP's blocking it, why not
> > a) Ask your ISP whether it provides an NTP or simple NTP server?
> > b) Ask your ISP whether if does block NTP traffic.
>
> It is generally very difficult to
John Summerfield writes:
> If you think your ISP's blocking it, why not
> a) Ask your ISP whether it provides an NTP or simple NTP server?
> b) Ask your ISP whether if does block NTP traffic.
It is generally very difficult to reach anyone at an ISP that knows what
an NTP server is. Just try using
Didar Hussain wrote:
Hi,
I'm having a problem connecting to the public NTP servers.
I have tried clock.redhat.com, time.windows.com (well...uhmm)
and ntp.debian.org. I use `ntpdate' to synchronise my system
when I connect to the ISP using dial-up. I have been using
the "-u" option consistently to
Hi,
I'm having a problem connecting to the public NTP servers.
I have tried clock.redhat.com, time.windows.com (well...uhmm)
and ntp.debian.org. I use `ntpdate' to synchronise my system
when I connect to the ISP using dial-up. I have been using
the "-u" option consistently to query the NTP server
On Fri, Feb 14, 2003 at 12:22:39PM +0200, Cristi Banciu wrote:
> Hi,
>
> I try to install and configure a ntpd on a machine
>
> I do apt-get install ntp ntpdate ntp-doc
> When it prompts for an ntp server to synchronize I get on already
> working. It asks me if I want him to overwrite ntp.conf an
Hi,
I try to install and configure a ntpd on a machine
I do apt-get install ntp ntpdate ntp-doc
When it prompts for an ntp server to synchronize I get on already
working. It asks me if I want him to overwrite ntp.conf and I say yes.
All fine, ps -ax shows ntpd working
but when I try to synchroni
On Wed Oct 17 11:04:54 2001 David Roundy wrote...
>
>On Tue, Oct 16, 2001 at 03:04:38PM -0400, Stan Brown wrote:
>>
>> The machine has been up for a good while now, but ntptrace still says it's
>> not synched.
>>
>> Any sugestions?
>
>Did you run ntpdate? (which requires you to enter the IP addre
On Tue, Oct 16, 2001 at 03:04:38PM -0400, Stan Brown wrote:
>
> The machine has been up for a good while now, but ntptrace still says it's
> not synched.
>
> Any sugestions?
Did you run ntpdate? (which requires you to enter the IP address into yet
another config file)
--
David Roundy
http://civ
I'm installing a Debian potato + Progeny + 2.4.9 kernel system on a netwokr
with sever HP-UX machines, SCO machines, Solaris machines, and FreeBSD
machines.
On all teh other machines I have ntp working to using an internal
timeserver machien. I pput the IP add ress of this in the Debian machines
/
61 matches
Mail list logo
