ntp problems

ntp problems

[Gene Heskett]

Greetings everybody;

I seem to have an ntp problem.  I noticed a few minutes ago that if
my watch was anywhere near correct, then the computer was about 6
minutes fast.  Doing a service ntpd restart crash set it back nearly
6 minutes.

Kernel is 2.6.15-rc5, xp2800 athlon box, gig of ram.

Heres the log since yesterdays reboot, including the restart just
now.  What can be learned from it?

4 Dec 10:39:16 ntpd[1981]: logging to file /var/log/ntp.log
 4 Dec 10:39:16 ntpd[1981]: ntpd 4.2.0a@1.1190-r Fri Aug 26 04:27:20
EDT 2005 (1)
 4 Dec 10:39:16 ntpd[1981]: precision = 1.000 usec
 4 Dec 10:39:16 ntpd[1981]: Listening on interface wildcard,
0.0.0.0#123
 4 Dec 10:39:16 ntpd[1981]: Listening on interface lo, 127.0.0.1#123
 4 Dec 10:39:16 ntpd[1981]: Listening on interface eth0,
192.168.71.3#123
 4 Dec 10:39:16 ntpd[1981]: kernel time sync status 0040
 4 Dec 10:39:17 ntpd[1981]: frequency initialized 4.392 PPM from
/var/lib/ntp/drift
 4 Dec 10:42:32 ntpd[1981]: synchronized to LOCAL(0), stratum 10
 4 Dec 10:42:32 ntpd[1981]: kernel time sync disabled 0041
 4 Dec 10:43:36 ntpd[1981]: kernel time sync enabled 0001
 4 Dec 14:30:12 ntpd[1981]: synchronized to 80.96.120.249, stratum 2
 4 Dec 14:33:02 ntpd[1981]: synchronized to 64.109.43.141, stratum 2
 4 Dec 14:35:12 ntpd[1981]: synchronized to LOCAL(0), stratum 10
 4 Dec 20:35:32 ntpd[1981]: synchronized to 80.96.120.249, stratum 2
 4 Dec 20:37:40 ntpd[1981]: synchronized to 64.109.43.141, stratum 2
 4 Dec 20:38:56 ntpd[1981]: synchronized to LOCAL(0), stratum 10
 5 Dec 00:06:20 ntpd[1981]: ntpd exiting on signal 15
 5 Dec 00:00:38 ntpd[22610]: logging to file /var/log/ntp.log
 5 Dec 00:00:38 ntpd[22610]: ntpd 4.2.0a@1.1190-r Fri Aug 26 04:27:20
EDT 2005 (1)
 5 Dec 00:00:38 ntpd[22610]: precision = 1.000 usec
 5 Dec 00:00:38 ntpd[22610]: Listening on interface wildcard,
0.0.0.0#123
 5 Dec 00:00:38 ntpd[22610]: Listening on interface lo, 127.0.0.1#123
 5 Dec 00:00:38 ntpd[22610]: Listening on interface eth0,
192.168.71.3#123
 5 Dec 00:00:38 ntpd[22610]: kernel time sync status 0040
 5 Dec 00:00:39 ntpd[22610]: frequency initialized 4.392 PPM from
/var/lib/ntp/drift
 5 Dec 00:03:58 ntpd[22610]: synchronized to LOCAL(0), stratum 10
 5 Dec 00:03:58 ntpd[22610]: kernel time sync disabled 0041
 5 Dec 00:05:04 ntpd[22610]: kernel time sync enabled 0001

 Thanks for any hints anybody can throw my way.
 
-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[john stultz]

On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
> Greetings everybody;
> 
> I seem to have an ntp problem.  I noticed a few minutes ago that if
> my watch was anywhere near correct, then the computer was about 6
> minutes fast.  Doing a service ntpd restart crash set it back nearly
> 6 minutes.

Not sure exactly what is going on, but you might want to try dropping
the LOCAL server reference in your ntp.conf. It could be you're just
syncing w/ yourself.

thanks
-john

Re: ntp problems

[Gene Heskett]

On Monday 05 December 2005 16:39, john stultz wrote:
>On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
>> Greetings everybody;
>>
>> I seem to have an ntp problem.  I noticed a few minutes ago that if
>> my watch was anywhere near correct, then the computer was about 6
>> minutes fast.  Doing a service ntpd restart crash set it back nearly
>> 6 minutes.
>
>Not sure exactly what is going on, but you might want to try dropping
>the LOCAL server reference in your ntp.conf. It could be you're just
>syncing w/ yourself.
>
>thanks
>-john

Joanne, bless her, pointed out that I had probably turned the ACPI
stuff in my kernel back on.  She was of course correct, shut it off &
ntpd works just fine.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[john stultz]

On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
> On Monday 05 December 2005 16:39, john stultz wrote:
> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
> >> Greetings everybody;
> >>
> >> I seem to have an ntp problem.  I noticed a few minutes ago that if
> >> my watch was anywhere near correct, then the computer was about 6
> >> minutes fast.  Doing a service ntpd restart crash set it back nearly
> >> 6 minutes.
> >
> >Not sure exactly what is going on, but you might want to try dropping
> >the LOCAL server reference in your ntp.conf. It could be you're just
> >syncing w/ yourself.
> >
> Joanne, bless her, pointed out that I had probably turned the ACPI
> stuff in my kernel back on.  She was of course correct, shut it off &
> ntpd works just fine.

Err. ACPI stuff? Could you elaborate? Sounds like you have some sort of
bug hiding there. 

thanks
-john

Re: ntp problems

[Gene Heskett]

On Monday 05 December 2005 19:14, john stultz wrote:
>On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
>> On Monday 05 December 2005 16:39, john stultz wrote:
>> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
>> >> Greetings everybody;
>> >>
>> >> I seem to have an ntp problem.  I noticed a few minutes ago that
>> >> if my watch was anywhere near correct, then the computer was about
>> >> 6 minutes fast.  Doing a service ntpd restart crash set it back
>> >> nearly 6 minutes.
>> >
>> >Not sure exactly what is going on, but you might want to try
>> > dropping the LOCAL server reference in your ntp.conf. It could be
>> > you're just syncing w/ yourself.
>>
>> Joanne, bless her, pointed out that I had probably turned the ACPI
>> stuff in my kernel back on.  She was of course correct, shut it off &
>> ntpd works just fine.
>
>Err. ACPI stuff? Could you elaborate? Sounds like you have some sort of
>bug hiding there.

This has been a relatively long standing problem, John.  I think its 
possibly related to some access path in the nforce2 chipset as it seems 
to plague that chipset worse than others.  But its long been, and I had 
forgotten, that if ntpd didn't work, turning off the ACPI stuff was the 
fix.

It had worked for a few kernel.org kernels and I had become complacent.  
My mistake.

OTOH, calling it a local bug, no, I certainly wouldn't call it a local to 
my machine bug.  Jdow OTOH, running an FC4 box, has it enabled, and hers 
is working just fine.  She is I believe, running the FC4's latest kernel 
too, so maybe the redhat people have massaged it.  However, at one time 
several months ago I believe she also had to have a grub argument 
turning acpi=no.

There was a bunch of ntp related patches submitted recently, and I have 
no idea which of them may have restored the broken acpi vs ntp scenario 
to its formerly broken status, again.

Should it be looked at?  Certainly, but I don't have the knowledge to do 
so.  So I build kernels, and report problems areas.  The canary in the 
coal mine so to speak. :-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[john stultz]

On Mon, 2005-12-05 at 21:07 -0500, Gene Heskett wrote:
> On Monday 05 December 2005 19:14, john stultz wrote:
> >On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
> >> On Monday 05 December 2005 16:39, john stultz wrote:
> >> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
> >> >> Greetings everybody;
> >> >>
> >> >> I seem to have an ntp problem.  I noticed a few minutes ago that
> >> >> if my watch was anywhere near correct, then the computer was about
> >> >> 6 minutes fast.  Doing a service ntpd restart crash set it back
> >> >> nearly 6 minutes.
> >> >
> >> >Not sure exactly what is going on, but you might want to try
> >> > dropping the LOCAL server reference in your ntp.conf. It could be
> >> > you're just syncing w/ yourself.
> >>
> >> Joanne, bless her, pointed out that I had probably turned the ACPI
> >> stuff in my kernel back on.  She was of course correct, shut it off &
> >> ntpd works just fine.
> >
> >Err. ACPI stuff? Could you elaborate? Sounds like you have some sort of
> >bug hiding there.
> 
> This has been a relatively long standing problem, John.  I think its 
> possibly related to some access path in the nforce2 chipset as it seems 
> to plague that chipset worse than others.  But its long been, and I had 
> forgotten, that if ntpd didn't work, turning off the ACPI stuff was the 
> fix.

Hey Gene,

	I know we've spoken before about a few timekeeping problems, but
sometimes I have a hard time keeping all the issues straight. Have you
filed a bug on this issue? I queried for your email in
bugzilla.kernel.org and I couldn't find anything. If not, would you mind
opening a bug describing the behavior you are seeing with the different
boot options (possibly also dmesg output for both configurations)? It
will greatly help make sure this doesn't slip by without notice.


> It had worked for a few kernel.org kernels and I had become complacent.  
> My mistake.
> 
> OTOH, calling it a local bug, no, I certainly wouldn't call it a local to 
> my machine bug.  Jdow OTOH, running an FC4 box, has it enabled, and hers 
> is working just fine.  She is I believe, running the FC4's latest kernel 
> too, so maybe the redhat people have massaged it.  However, at one time 
> several months ago I believe she also had to have a grub argument 
> turning acpi=no.

Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
why it would have changed recently. Can you bound at all the kernel
versions where it worked and where it broke? Additionally, do be sure
you have the most recent BIOS, I've seen a number of nforce2 issues be
resolved with a BIOS update.


> There was a bunch of ntp related patches submitted recently, and I have 
> no idea which of them may have restored the broken acpi vs ntp scenario 
> to its formerly broken status, again.

I don't think the NTP changes would have triggered this, but I want to
be sure (its more likely something else in the timekeeping code is
causing problems).

> Should it be looked at?  Certainly, but I don't have the knowledge to do 
> so.  So I build kernels, and report problems areas.  The canary in the 
> coal mine so to speak. :-)

The testing and problem report is very much appreciated! Start with
filing a bugzilla bug and then I'll point you at a few more mines to
checkout :)

thanks
-john

Re: ntp problems

[Gene Heskett]

On Monday 05 December 2005 22:20, john stultz wrote:
>On Mon, 2005-12-05 at 21:07 -0500, Gene Heskett wrote:
>> On Monday 05 December 2005 19:14, john stultz wrote:
>> >On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
>> >> On Monday 05 December 2005 16:39, john stultz wrote:
>> >> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
>> >> >> Greetings everybody;
>> >> >>
>> >> >> I seem to have an ntp problem.  I noticed a few minutes ago
>> >> >> that if my watch was anywhere near correct, then the computer
>> >> >> was about 6 minutes fast.  Doing a service ntpd restart crash
>> >> >> set it back nearly 6 minutes.
>> >> >
>> >> >Not sure exactly what is going on, but you might want to try
>> >> > dropping the LOCAL server reference in your ntp.conf. It could
>> >> > be you're just syncing w/ yourself.
>> >>
>> >> Joanne, bless her, pointed out that I had probably turned the ACPI
>> >> stuff in my kernel back on.  She was of course correct, shut it
>> >> off & ntpd works just fine.
>> >
>> >Err. ACPI stuff? Could you elaborate? Sounds like you have some sort
>> > of bug hiding there.
>>
>> This has been a relatively long standing problem, John.  I think its
>> possibly related to some access path in the nforce2 chipset as it
>> seems to plague that chipset worse than others.  But its long been,
>> and I had forgotten, that if ntpd didn't work, turning off the ACPI
>> stuff was the fix.
>
>Hey Gene,
>
> I know we've spoken before about a few timekeeping problems, but
>sometimes I have a hard time keeping all the issues straight. Have you
>filed a bug on this issue? I queried for your email in
>bugzilla.kernel.org and I couldn't find anything. If not, would you
> mind opening a bug describing the behavior you are seeing with the
> different boot options (possibly also dmesg output for both
> configurations)? It will greatly help make sure this doesn't slip by
> without notice.

You're asking me to fight with bugzilla again John?  I'm not THAT 
masochistic.

When you have to lose your cool to get out of the search for duplicate 
entries menu's, I call the software broken.  Lifes too short to put up 
with that, just let me file the friggin bug and let the software search 
for similar ones.  If there are, then it should email you for 
clarification as to whether my bug is a dup, or a new one with different 
triggering conditions.  The present interface is a genuine PITA.

>> It had worked for a few kernel.org kernels and I had become
>> complacent. My mistake.
>>
>> OTOH, calling it a local bug, no, I certainly wouldn't call it a
>> local to my machine bug.  Jdow OTOH, running an FC4 box, has it
>> enabled, and hers is working just fine.  She is I believe, running
>> the FC4's latest kernel too, so maybe the redhat people have massaged
>> it.  However, at one time several months ago I believe she also had
>> to have a grub argument turning acpi=no.
>
>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
>why it would have changed recently. Can you bound at all the kernel
>versions where it worked and where it broke? Additionally, do be sure
>you have the most recent BIOS, I've seen a number of nforce2 issues be
>resolved with a BIOS update.

I've already put more powerdown cycles (60 some) on my hard drives 
fighting with the recent tv card problem, I'd like to get some uptime 
in.  All I know for sure is if I build 2.6.15-rc5 with acpi, ntpd 
doesn't work.  ntpdate does, but ntpd doesn't.  And both dmesg and the 
ntp.log (and -d's passed at launch time do not make it more verbose, 
they just keep it from starting) are silent as to the diffs other than 
the interrupt number shuffling in dmesg when its on.  But I suspect it 
may have started with 2.6.15-rc2, and I didn't build rc1.  And I *think* 
it worked as recently as 2.6.14.1 with it turned on.  I've cleaned house 
in /usr/src's so I don't have anything older.  Sorry.

>> There was a bunch of ntp related patches submitted recently, and I
>> have no idea which of them may have restored the broken acpi vs ntp
>> scenario to its formerly broken status, again.
>
>I don't think the NTP changes would have triggered this, but I want to
>be sure (its more likely something else in the timekeeping code is
>causing problems).
>
>> Should it be looked at?  Certainly, but I don't have the knowledge to
>> do so.  So I build kernels, and report problems areas.  The canary in
>> the coal mine so to speak. :-)
>
>The testing and problem report is very much appreciated! Start with
>filing a bugzilla bug and then I'll point you at a few more mines to
>checkout :)

Maybe next week when I have restored my patience, its been in short 
supply lately over this tv card problem.  Joanne (jdow) might be able to 
furnish more co-oberating details as she sees more machines at earthlink 
in a days work than I do in a year.  I only have 3 here on my little 
network, one rh7.3 box (firewall), this one, and a box in the shop that 
runs my milling machine, so there is not at the moment, a sacrificial 
lamb.

>thanks
>-john

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[jdow]

From: "Gene Heskett" <gene.heskett@verizon.net>

>>> Should it be looked at?  Certainly, but I don't have the knowledge to
>>> do so.  So I build kernels, and report problems areas.  The canary in
>>> the coal mine so to speak. :-)
>>
>>The testing and problem report is very much appreciated! Start with
>>filing a bugzilla bug and then I'll point you at a few more mines to
>>checkout :)
> 
> Maybe next week when I have restored my patience, its been in short 
> supply lately over this tv card problem.  Joanne (jdow) might be able to 
> furnish more co-oberating details as she sees more machines at earthlink 
> in a days work than I do in a year.  I only have 3 here on my little 
> network, one rh7.3 box (firewall), this one, and a box in the shop that 
> runs my milling machine, so there is not at the moment, a sacrificial 
> lamb.

No I don't. I've just used ntp for several years, back to when it was
xntp and a new thing to RedHat releases. I don't have anything to do
with Earthlink other than as a customer. I use Linux as the firewall
and mail service here as well as a general "let off steam" from doing
work on Windows that I can't do on Linux. (Matrox DigiSuite cards
feature heavily.)

{^_^}   Joanne

Re: ntp problems

[Gene Heskett]

On Tuesday 06 December 2005 02:33, jdow wrote:
>From: "Gene Heskett" <gene.heskett@verizon.net>
>
>>>> Should it be looked at?  Certainly, but I don't have the knowledge
>>>> to do so.  So I build kernels, and report problems areas.  The
>>>> canary in the coal mine so to speak. :-)
>>>
>>>The testing and problem report is very much appreciated! Start with
>>>filing a bugzilla bug and then I'll point you at a few more mines to
>>>checkout :)
>>
>> Maybe next week when I have restored my patience, its been in short
>> supply lately over this tv card problem.  Joanne (jdow) might be able
>> to furnish more co-oberating details as she sees more machines at
>> earthlink in a days work than I do in a year.  I only have 3 here on
>> my little network, one rh7.3 box (firewall), this one, and a box in
>> the shop that runs my milling machine, so there is not at the moment,
>> a sacrificial lamb.
>
>No I don't. I've just used ntp for several years, back to when it was
>xntp and a new thing to RedHat releases. I don't have anything to do
>with Earthlink other than as a customer. I use Linux as the firewall
>and mail service here as well as a general "let off steam" from doing
>work on Windows that I can't do on Linux. (Matrox DigiSuite cards
>feature heavily.)
>
>{^_^}   Joanne

My mistaken impression then, and my apologies Joanne.  I was under the 
impression that you've been an earthlink related employee for several 
years, and just speaking as a user for those posts that were revelant.

Does this mean I should go buy a Matrox card the next time I need a video 
card?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[jdow]

From: "Gene Heskett" <gene.heskett@verizon.net>

> On Tuesday 06 December 2005 02:33, jdow wrote:
>>From: "Gene Heskett" <gene.heskett@verizon.net>
>>
>>>>> Should it be looked at?  Certainly, but I don't have the knowledge
>>>>> to do so.  So I build kernels, and report problems areas.  The
>>>>> canary in the coal mine so to speak. :-)
>>>>
>>>>The testing and problem report is very much appreciated! Start with
>>>>filing a bugzilla bug and then I'll point you at a few more mines to
>>>>checkout :)
>>>
>>> Maybe next week when I have restored my patience, its been in short
>>> supply lately over this tv card problem.  Joanne (jdow) might be able
>>> to furnish more co-oberating details as she sees more machines at
>>> earthlink in a days work than I do in a year.  I only have 3 here on
>>> my little network, one rh7.3 box (firewall), this one, and a box in
>>> the shop that runs my milling machine, so there is not at the moment,
>>> a sacrificial lamb.
>>
>>No I don't. I've just used ntp for several years, back to when it was
>>xntp and a new thing to RedHat releases. I don't have anything to do
>>with Earthlink other than as a customer. I use Linux as the firewall
>>and mail service here as well as a general "let off steam" from doing
>>work on Windows that I can't do on Linux. (Matrox DigiSuite cards
>>feature heavily.)
>>
>>{^_^}   Joanne
> 
> My mistaken impression then, and my apologies Joanne.  I was under the 
> impression that you've been an earthlink related employee for several 
> years, and just speaking as a user for those posts that were revelant.
> 
> Does this mean I should go buy a Matrox card the next time I need a video 
> card?

No, my competitors are not ATI and nVidia. And the cards I work with
are intended for broadcast video.

And this is severely OT by now so... Ta

{^_^}

Re: ntp problems

[Jean-Christian de Rivaz]

Gene Heskett a écrit :

>>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
>>why it would have changed recently. Can you bound at all the kernel
>>versions where it worked and where it broke? Additionally, do be sure
>>you have the most recent BIOS, I've seen a number of nforce2 issues be
>>resolved with a BIOS update.
> 
> 
> I've already put more powerdown cycles (60 some) on my hard drives 
> fighting with the recent tv card problem, I'd like to get some uptime 
> in.  All I know for sure is if I build 2.6.15-rc5 with acpi, ntpd 
> doesn't work.  ntpdate does, but ntpd doesn't.  And both dmesg and the 
> ntp.log (and -d's passed at launch time do not make it more verbose, 
> they just keep it from starting) are silent as to the diffs other than 
> the interrupt number shuffling in dmesg when its on.  But I suspect it 
> may have started with 2.6.15-rc2, and I didn't build rc1.  And I *think* 
> it worked as recently as 2.6.14.1 with it turned on.  I've cleaned house 
> in /usr/src's so I don't have anything older.  Sorry.

I have to agree with John Stultz. I am one with a nForce2 chipset where 
updating to the latest BIOS have totaly solved the excatly same ntpd 
problem.

Regards,
-- 
Jean-Christian de Rivaz

Re: ntp problems

[Gene Heskett]

On Tuesday 06 December 2005 06:44, Jean-Christian de Rivaz wrote:
>Gene Heskett a écrit :
>>>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not
>>> sure why it would have changed recently. Can you bound at all the
>>> kernel versions where it worked and where it broke? Additionally, do
>>> be sure you have the most recent BIOS, I've seen a number of nforce2
>>> issues be resolved with a BIOS update.
>>
>> I've already put more powerdown cycles (60 some) on my hard drives
>> fighting with the recent tv card problem, I'd like to get some uptime
>> in.  All I know for sure is if I build 2.6.15-rc5 with acpi, ntpd
>> doesn't work.  ntpdate does, but ntpd doesn't.  And both dmesg and
>> the ntp.log (and -d's passed at launch time do not make it more
>> verbose, they just keep it from starting) are silent as to the diffs
>> other than the interrupt number shuffling in dmesg when its on.  But
>> I suspect it may have started with 2.6.15-rc2, and I didn't build
>> rc1.  And I *think* it worked as recently as 2.6.14.1 with it turned
>> on.  I've cleaned house in /usr/src's so I don't have anything older.
>>  Sorry.
>
>I have to agree with John Stultz. I am one with a nForce2 chipset where
>updating to the latest BIOS have totaly solved the excatly same ntpd
>problem.

Problems: I went and got a newer bios, for a Biostar N7NCD-Pro, put it 
on a floppy and rebooted.  Going into the bios I chose to update it as 
that is part of the existing bios, no awardflash.exe needed according to 
the propaganda.  But the bios can't find it on the floppy.

Or do I still need awardflash.exe on the floppy too?  I'll put it there 
and try again.
------
Several reboots later, I still haven't managed to get it updated.

The first problem was that the builtin bios flasher couldn't find the 
file on the floppy, presumably because while vfat shows the correct name 
of ncdp1102bf.exe, a dos boot or compatible dir util can't see it as 
anything but ncdp11~1.exe.  So I put their latest awdflash.exe on the 
disk too.  Same deal except I had it save the old bios as oldbios.exe, 
and it can see that, but not the new file until I renamed it to 
something short enough for an idiot dos, ncdpbf.exe.

So, having arrived as a dos compatible name, I tried again, but now its 
bitching about a file size error and still refuses to do the update 
using their instructions to recover a bad update.  And the builtin bios 
flasher still can't see the shortened name.  I don't see a filesize 
error in the ls -l's below either.

An ls -l on that floppy shows:
[root@coyote root]# ls -l /mnt/floppy
total 563
-rwxr-xr-x  1 root root  47916 Dec  6 13:23 awdflash.exe
-rwxr-xr-x  1 root root 266240 Dec  6 13:24 ncdpbf.exe
-rwxr-xr-x  1 root root 262144 Dec  6  2005 oldbios.exe


An ls -l on the /dos dir of my hd, grepped for ncdp:
-rwxr-xr-x  1 root root 266240 Sep 16  2004 ncdp0730bf.exe
-rwxr-xr-x  1 root root 266240 Dec  6 12:10 ncdp1102bf.exe

The ncdp0730bf.exe is the file thats in the bios now, and which was then 
saved using the awdflash.exe as oldbios.exe thats on that disk now. 
FWIW, awdflash.exe CAN see the oldbios.exe file just fine.  I have now 
downloaded the new one twice from biostar.com.tw.

Has anyone got a clue as to what the heck is wrong here?

>Regards,

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[Gene Heskett]

On Tuesday 06 December 2005 14:02, Gene Heskett wrote:
>On Tuesday 06 December 2005 06:44, Jean-Christian de Rivaz wrote:
>>Gene Heskett a écrit :
>>>>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not
>>>> sure why it would have changed recently. Can you bound at all the
>>>> kernel versions where it worked and where it broke? Additionally,
>>>> do be sure you have the most recent BIOS, I've seen a number of
>>>> nforce2 issues be resolved with a BIOS update.
>>>
>>> I've already put more powerdown cycles (60 some) on my hard drives
>>> fighting with the recent tv card problem, I'd like to get some
>>> uptime in.  All I know for sure is if I build 2.6.15-rc5 with acpi,
>>> ntpd doesn't work.  ntpdate does, but ntpd doesn't.  And both dmesg
>>> and the ntp.log (and -d's passed at launch time do not make it more
>>> verbose, they just keep it from starting) are silent as to the diffs
>>> other than the interrupt number shuffling in dmesg when its on.  But
>>> I suspect it may have started with 2.6.15-rc2, and I didn't build
>>> rc1.  And I *think* it worked as recently as 2.6.14.1 with it turned
>>> on.  I've cleaned house in /usr/src's so I don't have anything
>>> older. Sorry.
>>
>>I have to agree with John Stultz. I am one with a nForce2 chipset
>> where updating to the latest BIOS have totaly solved the excatly same
>> ntpd problem.
>
>Problems: I went and got a newer bios, for a Biostar N7NCD-Pro, put it
>on a floppy and rebooted.  Going into the bios I chose to update it as
>that is part of the existing bios, no awardflash.exe needed according
> to the propaganda.  But the bios can't find it on the floppy.
>
>Or do I still need awardflash.exe on the floppy too?  I'll put it there
>and try again.
>------
>Several reboots later, I still haven't managed to get it updated.
>
>The first problem was that the builtin bios flasher couldn't find the
>file on the floppy, presumably because while vfat shows the correct
> name of ncdp1102bf.exe, a dos boot or compatible dir util can't see it
> as anything but ncdp11~1.exe.  So I put their latest awdflash.exe on
> the disk too.  Same deal except I had it save the old bios as
> oldbios.exe, and it can see that, but not the new file until I renamed
> it to something short enough for an idiot dos, ncdpbf.exe.
>
>So, having arrived as a dos compatible name, I tried again, but now its
>bitching about a file size error and still refuses to do the update
>using their instructions to recover a bad update.  And the builtin bios
>flasher still can't see the shortened name.  I don't see a filesize
>error in the ls -l's below either.
>
>An ls -l on that floppy shows:
>[root@coyote root]# ls -l /mnt/floppy
>total 563
>-rwxr-xr-x  1 root root  47916 Dec  6 13:23 awdflash.exe
>-rwxr-xr-x  1 root root 266240 Dec  6 13:24 ncdpbf.exe
>-rwxr-xr-x  1 root root 262144 Dec  6  2005 oldbios.exe
>
>
>An ls -l on the /dos dir of my hd, grepped for ncdp:
>-rwxr-xr-x  1 root root 266240 Sep 16  2004 ncdp0730bf.exe
>-rwxr-xr-x  1 root root 266240 Dec  6 12:10 ncdp1102bf.exe
>
>The ncdp0730bf.exe is the file thats in the bios now, and which was
> then saved using the awdflash.exe as oldbios.exe thats on that disk
> now. FWIW, awdflash.exe CAN see the oldbios.exe file just fine.  I
> have now downloaded the new one twice from biostar.com.tw.
>
>Has anyone got a clue as to what the heck is wrong here?
>
Well, it turns out I was the one without a clue, I was downloading the 
bios images from biostar.com.tw, which are NOT apparently correct.  On a 
hunch, I specifically went to the usa1.biostar.com site, and found there 
was a different file posted there for my M7NCD-pro board.

That one installed without any hiccups, but I saw where the sign-on said 
it was DDR400 dual channel ram, whereas before the update it was DDR333 
dual channel ram.  As the XP2800 athlon isn't rated for DDR400, I backed 
into the bios and reset the fsb for 166 mhz which should give me a 333 
fsb.  But it still says DDR400 at signon.  So I guess we'll see if its 
now stable at a 400 mhz fsb even if its set to 166/333.

dmesg says its running the cpu at 2080mhz, which is normal.

Has anyone else observed this and care to comment?

>>Regards,

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[Kyle Moffett]

On Dec 06, 2005, at 16:22, Gene Heskett wrote:
> That one installed without any hiccups, but I saw where the sign-on  
> said it was DDR400 dual channel ram, whereas before the update it  
> was DDR333 dual channel ram.  As the XP2800 athlon isn't rated for  
> DDR400, I backed into the bios and reset the fsb for 166 mhz which  
> should give me a 333
> fsb.  But it still says DDR400 at signon.  So I guess we'll see if  
> its now stable at a 400 mhz fsb even if its set to 166/333.

Hmm, this sounds a lot like the BIOS insanity we saw on one cheapo  
Chaintech board.  We knew it was bad when the thing reported in its  
boot display that the CPU was an "Intel Athlon".  Things only got  
worse from there; but sadly there was no BIOS update, and we ended up  
throwing away the $35 board just on general principles :-D.

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to  
make it so simple that there are obviously no deficiencies. And the  
other way is to make it so complicated that there are no obvious  
deficiencies.  The first method is far more difficult.
   -- C.A.R. Hoare

Re: ntp problems

[Gene Heskett]

On Wednesday 07 December 2005 00:14, Kyle Moffett wrote:
>On Dec 06, 2005, at 16:22, Gene Heskett wrote:
>> That one installed without any hiccups, but I saw where the sign-on
>> said it was DDR400 dual channel ram, whereas before the update it
>> was DDR333 dual channel ram.  As the XP2800 athlon isn't rated for
>> DDR400, I backed into the bios and reset the fsb for 166 mhz which
>> should give me a 333
>> fsb.  But it still says DDR400 at signon.  So I guess we'll see if
>> its now stable at a 400 mhz fsb even if its set to 166/333.
>
>Hmm, this sounds a lot like the BIOS insanity we saw on one cheapo
>Chaintech board.  We knew it was bad when the thing reported in its
>boot display that the CPU was an "Intel Athlon".  Things only got
>worse from there; but sadly there was no BIOS update, and we ended up
>throwing away the $35 board just on general principles :-D.
>
Thats been my impression of anything wearing a chaintech label, and I 
cannot pin a reason on it, just 71 years of experience.  Is that good 
enough?  Dunno Kyle, but when shopping for a mobo, the chaintech stuff 
has always been bypassed.  Some of the tech reports seem to say they're 
ok though.  Another example of YMMV I guess.

Anyway, I did finally get the bios to stop running the memory faster than 
an XP2800, rated at DDR333 can do.  So after a couple of hard crashes, 
it seems to be back among the living.  I had to use the expert group of 
settings though, & me not an expert, not 50 miles from home, nor am I 
carrying a briefcase as I once heard an expert described.

And, acpi is on, and ntpd is happy with the new bios.  Hurrah!

>Cheers,
>Kyle Moffett
>
>--
>There are two ways of constructing a software design. One way is to
>make it so simple that there are obviously no deficiencies. And the
>other way is to make it so complicated that there are no obvious
>deficiencies.  The first method is far more difficult.
>   -- C.A.R. Hoare

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[Jean-Christian de Rivaz]

Gene Heskett a écrit :
> And, acpi is on, and ntpd is happy with the new bios.  Hurrah!

Good news!

I wonder if it would be a good idea to add something into the kernel or 
into ntpd to alert the users that ntpd can't run normaly because of a 
too fast drift ? Then a BIOS upgrade could be proposed (especially on a 
nForce2 system). I don't know if it's even realistc.

Regards,
-- 
Jean-Christian de Rivaz

Re: ntp problems

[Gene Heskett]

On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>Gene Heskett a écrit :
>> And, acpi is on, and ntpd is happy with the new bios.  Hurrah!
>
>Good news!
>
>I wonder if it would be a good idea to add something into the kernel or
>into ntpd to alert the users that ntpd can't run normaly because of a
>too fast drift ? Then a BIOS upgrade could be proposed (especially on a
>nForce2 system). I don't know if it's even realistc.
>
>Regards,

The drift itself wasn't what I'd call excessive, 
something like 6 minutes in a week, which for 
mainboard quality crystals is pretty darned good.

I didn't discover it wasn't working till my watch beeped 
at me on the hour like it always does (casio) and I glanced 
at the cornerclock to see it said it was 6 minutes & some 
after the hour.  So either my watch was funkity, or the ntpd.
My watch has been *very* reliable, staying within 10 seconds 
a month, so I discounted that theory and went after ntpd.

After my experience, I'd recommend any nforce2 board get 
the latest bios and install it.  On this biostar though, 
I then had to go into the expert mode on the 3rd screen 
and play for a while till I had restored the DDR to 333 mhz, 
the defaults want to run it at 400 mhz, and an XP2800 
athlon will only stay up 10 minutes or so at 40, as its 
only rated at 333.  The faster athlons, Xp3200+ chips, 
are rated for 400 though.

But in my case, I think that was the only 'gotcha', and 
everything else seems to be as happy as that infamous pig 
in you know what.

When its running, drift file contents have not to my knowledge ever 
exceeded 6.000, and are currently running like this:
drift=4.236
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ns2.pulsation.f 129.240.64.3     3 u  232 1024  377  132.270    1.516   1.117
+ntp.aramiska.ne 172.16.33.1      2 u  333 1024  377  123.445    3.725   0.704
*ftp.cerias.purd 128.10.252.7     2 u 1370 1024  376   73.101    0.532   5.700
 LOCAL(0)        LOCAL(0)        10 l    6   64  377    0.000    0.000   0.001
drift=4.236

I have a while true script logging the drift and the output of 
ntpq -p into /var/log/ntp.log every half hour temporarily.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[Jean-Christian de Rivaz]

Gene Heskett a écrit :
> On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
> 
>>Gene Heskett a écrit :
>>
>>>And, acpi is on, and ntpd is happy with the new bios.  Hurrah!
>>
>>Good news!
>>
>>I wonder if it would be a good idea to add something into the kernel or
>>into ntpd to alert the users that ntpd can't run normaly because of a
>>too fast drift ? Then a BIOS upgrade could be proposed (especially on a
>>nForce2 system). I don't know if it's even realistc.
>>
>>Regards,
> 
> 
> The drift itself wasn't what I'd call excessive, 
> something like 6 minutes in a week, which for 
> mainboard quality crystals is pretty darned good.

ntpd work only on system with a drift of maximum +/-500ppm. This post 
summarize a lot of informations about the problem:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113105244509795&w=2
It was found later that an issue into the nForce2 is the root of the 
problem and that a BIOS update solve it.

6.0 / (60*24*7) * 1e6 = 595.24
6 minutes per week is near 600ppm, it's enough to trigg the problem you 
have seen. Even very cheap crystal are 100ppm at commercial temperature 
range. 100ppm is about 1 minute per week. Some crystal manufacturers 
propose now 30ppm as the default standard at commercial temperature range.

As your watch prove, good cristal can be just a few ppm (about 3.86ppm 
for your watch)

Regards,
-- 
Jean-Christian de Rivaz

Re: ntp problems

[Gene Heskett]

On Wednesday 07 December 2005 18:34, Jean-Christian de Rivaz wrote:
>Gene Heskett a écrit :
>> On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>>>Gene Heskett a écrit :
>>>>And, acpi is on, and ntpd is happy with the new bios.  Hurrah!
>>>
>>>Good news!
>>>
>>>I wonder if it would be a good idea to add something into the kernel
>>> or into ntpd to alert the users that ntpd can't run normaly because
>>> of a too fast drift ? Then a BIOS upgrade could be proposed
>>> (especially on a nForce2 system). I don't know if it's even
>>> realistc.
>>>
>>>Regards,
>>
>> The drift itself wasn't what I'd call excessive,
>> something like 6 minutes in a week, which for
>> mainboard quality crystals is pretty darned good.
>
>ntpd work only on system with a drift of maximum +/-500ppm. This post
>summarize a lot of informations about the problem:
>http://marc.theaimsgroup.com/?l=linux-kernel&m=113105244509795&w=2
>It was found later that an issue into the nForce2 is the root of the
>problem and that a BIOS update solve it.
>
Yes, but this 500ppm limitation does not AIUI, include the mitigating 
effects of the drift files contents I'm told.  I know there have been 
times when I had to manually play with it to get it in range, or simply 
delete it and let ntpd reset it, which it then finetuned as I can see in 
an ntpq -p output.

Is this incorrect?  FWIW, the value in the drift file right now is within 
about 1 ppm of the value that was in it when it wasn't working.  So that 
tells me the drift rate was ok, with the files compensating effects 
added in.  Offsets to the server its peering to right now haven't 
exceeded 6.554 since the last reboot.  Humm, I'll take it back, just in 
the last half hour the peer site has gone from an offset of -1.568 to an 
offset of -41.184, and it did this without updateing the contents of the 
drift file logged a few milliseconds before.  This bears watching I 
think.


>6.0 / (60*24*7) * 1e6 = 595.24
>6 minutes per week is near 600ppm, it's enough to trigg the problem you
>have seen. Even very cheap crystal are 100ppm at commercial temperature
>range. 100ppm is about 1 minute per week. Some crystal manufacturers
>propose now 30ppm as the default standard at commercial temperature
> range.
>
>As your watch prove, good cristal can be just a few ppm (about 3.86ppm
>for your watch)
>
>Regards,

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[Gene Heskett]

On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>Gene Heskett a écrit :
>> And, acpi is on, and ntpd is happy with the new bios.  Hurrah!
>
>Good news!
>
>I wonder if it would be a good idea to add something into the kernel
> or into ntpd to alert the users that ntpd can't run normaly because
> of a too fast drift ? Then a BIOS upgrade could be proposed
> (especially on a nForce2 system). I don't know if it's even
> realistc.
>
>Regards,

I don't know as this is a kernel issue in this case.  So if warning are 
to be output to the logs, then they really should come from ntpd IMO.

Frankly, the existing log output from ntpd sucks.  Once it has output a 
msg saying:
 8 Dec 16:38:20 ntpd[1966]: kernel time sync enabled 0001
it is totally mute until:
11 Dec 10:47:29 ntpd[1966]: synchronized to 64.112.189.11, stratum 2
11 Dec 13:04:34 ntpd[1966]: synchronized to 80.96.123.120, stratum 2

Nearly 3 days of silence, during which time it updated the contents of 
the drift file at least 20 times is rather hard to swallow when you 
are trying to see what its doing.  So I have another script being 
started in /etc/init/ntpd that fires off at 30 minute intervals, cats 
the contents of the drift file to the log & runs an instance of ntpq 
-p >>ntp.log.

That looks like this (excuse the word wrap please):
drift=4.353
     remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
+time.uswo.net   128.10.252.6     2 u  126 1024  377   85.553   -1.657   
0.167
+rrcs-24-172-8-1 80.64.135.105    3 u  200 1024  377   73.522    6.885   
3.648
*ecoca.eed.usv.r 80.96.120.253    2 u  200 1024  377  206.528    2.798   
3.468
 LOCAL(0)        LOCAL(0)        10 l   39   64  377    0.000    0.000   
0.001

A bit voluminous perhaps, but it sure gives me a much better picture of 
whether I can set my $25 Casio wristwatch to somewhere near the real 
time.  And, now that I've determined it is working, I could shut it 
off, but what happens then when I reboot to a new kernel and foo, bar, 
and baz are all on the missing list as has happened several times?  So 
I'll leave it running until I feel I can realy trust it.

I guess my point is, if we are to have a time synchronizer utility, it 
either should work, or raise hell & stomp its feet all over the logs 
once it determines that it cannot work correctly.  ntpd as implemented 
right now has a very bad case of laringitis(sp).

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.heskett@verizononline.net> which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: ntp problems

[Gene Heskett]

On Monday 05 December 2005 22:20, john stultz wrote:

[...]

>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
>why it would have changed recently. Can you bound at all the kernel
>versions where it worked and where it broke? Additionally, do be sure
>you have the most recent BIOS, I've seen a number of nforce2 issues be
>resolved with a BIOS update.

And, while I had a heck of a time doing the bios upgrade, it did work, 
acpi is now enabled, and ntpd is working 'nominally'.

Many thanks for the kick in the pants to go do that, John.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

NTP problems

[Shaw, Marco]

I've not been able to get NTP working on some of my RH7.2 and RHAS2.1 systems.

Absolutely no TCP or UDP traffic shows in a tcpdump.  The command ntpdate gives me this
and nothing more:

15 Jan 10:06:59 ntpdate[22868]: poll(): nfound = 0, error: Success

I was intially thinking that this was a glibc-i386 vs glibc-i686 problem, but
it does not appears so after more research.

I decided to run lsof, and get the following whenver ntpdate fails (doesn't
send out any traffic at all when looking via tcpdump).  Note
the last line where I get "can't indentify protocol".

[root@server]# lsof|grep ntpdate
ntpdate     461     root  cwd    DIR        8,7     4096    144002 /root
ntpdate     461     root  rtd    DIR        8,7     4096         2 /
ntpdate     461     root  txt    REG        8,5    40460    128472 /usr/sbin/ntp
date
ntpdate     461     root  mem    REG        8,7   464409     65742 /lib/ld-2.2.4
.so
ntpdate     461     root  mem    REG        8,5    44851     64355 /usr/lib/libc
ap.so.1.10
ntpdate     461     root  mem    REG        8,7  5737154     64013 /lib/libc-2.2
.4.so
ntpdate     461     root    0u   CHR      136,3                  5 /dev/pts/3
ntpdate     461     root    1u   CHR      136,3                  5 /dev/pts/3
ntpdate     461     root    2u   CHR      136,3                  5 /dev/pts/3
ntpdate     461     root    3u  sock        0,0          175748304 can't identif
y protocol

I've checked the LSOF FAQ regarding this "can't indentify protocol", and I'm not
any further ahead.

I've not been able to reproduce this consistently, but when I shut down xinetd, ipchains,
and enter "ALL:ALL" in hosts.allow, *eventually* (but not consistently especially as 
far as a timeframe), eventually ntpdate works as expected.

Any ideas?

Marco

Re: NTP problems

[Erik Hensema]

Shaw, Marco (Marco.Shaw@aliant.ca) wrote:
> I've not been able to get NTP working on some of my RH7.2 and RHAS2.1 systems.
> 
> Absolutely no TCP or UDP traffic shows in a tcpdump.  The
> command ntpdate gives me this and nothing more:
> 
> 15 Jan 10:06:59 ntpdate[22868]: poll(): nfound = 0, error: Success

Is this on a 2.6 kernel? I have similar problems between two 2.6
machines, but haven't investigated it much yet.

Both systems work well as a client. My home server running 2.6 is
NTP server to the rest of the network at home. A 2.4 machine can
sync its time, but a 2.6 machine can't. The 2.6 client can sync
to the public ntp servers on the internet.

(this is all IIRC)
-- 
Erik Hensema <erik@hensema.net>