NTP issue - time drifting, ntpd crashing?
in [Slackware]
|
Prev: Driver for Buffalo LPC PCM CLX
Next: Apple iPod
From: Dan C on 16 Jan 2006 09:00 On Mon, 16 Jan 2006 21:11:35 +0800, Chu Mai Fat wrote: > If we assume that 2.6.12.3 kernel was a "current" and "stable" kernel > six months ago, why would it need to be updated now? Ummmm.... because of security updates and new hardware support. > I was under the impression that odd numbered kernels, ie 2.1.x, 2.3.x > and 2.5.x were development kernels and should be updated but that even > numbered kernels were considered stable and if they contained all the > needed functionality then they were suitable and sufficient for general > use. See above. > Seems to me that this continuous necessity to upgrade is far worse than > the much maligned Windows model of regularly releasing security fixes > and patches. Well, it would seem that way to a Windroid, yes. See below. > User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Right. Score on the (1-10) Troll-o-Meter: 1.2 Run along boy. -- If you're not on the edge, you're taking up too much space. Linux Registered User #327951
From: Martin Boening on 16 Jan 2006 09:39 Hi there, On 2006-01-14, Logical <me(a)privacy.net> wrote: > Hi > > Been fiddling with ntpd on my slackware 10.0 box for a while now but it > constantly seems to be freezing and allowing the time to drift > significantly. > [...ntp.conf deleted...] in my ntp.conf I have server 195.13.23.5 # ntp1.belbone.be server 81.0.239.181 # ntp.cgi.cz server 84.207.3.38 # ntp1.tuxfamily.net I also have restrict 195.13.23.5 nomodify # trust servers regarding time restrict 81.0.239.181 nomodify restrict 80.67.179.98 nomodify I think these are needed to actually allow these servers to be accepted as time sources. I don't see any similar entries in your ntp.conf file. According to the documentation one would think they are unnecessary, since the server statements should implicitly allow the listed servers - however, I never got NTP to work without them. Try it and see what happens. (Maybe the server responses come as "queries which return information", thus the weird interpretation). Interestingly enough, while checking all this as result of your query, I found that my third 'server' line and my third "restrict" line differ, as one ntp server was changed some time ago. 'ntp -p -n' on my system shows the third server (not covered by a restrict statement) as 84.207.3.38 .STEP. 16 u - 1024 0 0.000 0.000 4000.00 My time synchronisation works, AFAICS: mboen(a)mboen3:~$ /usr/sbin/ntpq -c rv status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg, version="ntpd 4.2.0(a)1.1161-r Mon Mar 29 22:23:49 PST 2004 (1)", processor="i686", system="Linux/2.6.14.4-mboen3-1", leap=00, stratum=3, precision=-20, rootdelay=70.982, rootdispersion=74.574, peer=45862, refid=81.0.239.181, reftime=c7762586.c469d734 Mon, Jan 16 2006 15:00:38.767, poll=10, clock=c7762851.af738e6d Mon, Jan 16 2006 15:12:33.685, state=4, offset=2.009, frequency=-27.389, jitter=8.853, stability=0.018 (i.e. my system is in ntp stratum 3 and synchronised with server 81.0.239.181.) From the output of "ntpq -p" you posted in another article, I also conclude that synchronisation is not working for you, since the column st (stratum) is always "16" which is the value for a system "too far out to synchronise with". So again, try to see what happens, if you enter restrict statements for the ntp servers you wish to use. Of course, I may misinterpret something here... While my system is running kernel version 2.6.14.4, I don't think this matters - I've been synchronising my clock with the servers shown here for some time now so at one time or another I have certainly used ntp in conjunction with some 2.6.12 version kernel... [...] > > is SLs it's normal running state? I'm not sure... thats normal running state. my ntpd also runs in that state. HTH Martin -- Martin Boening, mboen(a)t-online.de, Linux Registered User #258205 KERNEL: A part of an operating system that preserves the medieval traditions of sorcery and black art.
From: Grant on 16 Jan 2006 10:22 On Mon, 16 Jan 2006 21:11:35 +0800, Chu Mai Fat <ChuMaiFat(a)nowhere.com> wrote: >Grant wrote: >> >> Six months old, current stable is 2.6.14.6 or 2.6.15 for the adventurous, >> the first stable bugfix for 2.6.15.1 be out very soon. .... >If we assume that 2.6.12.3 kernel was a "current" and "stable" kernel >six months ago, why would it need to be updated now? Changes in udev for 2.6.13? Slackware-current now has 2.6.14.6 (of course released in the same week was 2.6.15.1). Note too the 2.6.stable series now has bugfix and security patches applied during the kernel lifecycle since March'05. Applying these does not change the setup. >I was under the impression that odd numbered kernels, ie 2.1.x, 2.3.x >and 2.5.x were development kernels and should be updated but that even >numbered kernels were considered stable and if they contained all the >needed functionality then they were suitable and sufficient for general >use. No longer as true, the development process that orphaned the 2.4 series too early has been changed so that 2.6 is now the development tree until it is stabilised. Unfortunately lots of new stuff comes out, so driver development takes resources from stabilising the kernel. Production systems use 2.4 series plus hotfix, see: http://linux.exosec.net/kernel/2.4-hf/ http://bugsplatter.mine.nu/test/linux-2.4/ Notice the 2.4 hotfix series supports 2.4.29 through 2.4.32 just so getting the latest bugfix/security patches does not involve a kernel upgrade. This 2.4.stable model has been in place for 12 months. Look at the size of the patches between major releases of 2.4 vs 2.6 from kernel.org, for rate of change: patch-2.6.15.bz2 02-Jan-2006 21:04 6.0M patch-2.6.14.bz2 27-Oct-2005 17:27 4.1M patch-2.6.13.bz2 28-Aug-2005 17:03 4.8M patch-2.6.12.bz2 17-Jun-2005 15:04 4.5M patch-2.6.11.bz2 02-Mar-2005 00:00 4.0M patch-2.4.32.bz2 16-Nov-2005 11:13 54K patch-2.4.31.bz2 31-May-2005 17:57 25K patch-2.4.30.bz2 03-Apr-2005 18:44 100K 2.3MB/month vs 21kB/month? You could say from these numbers that 2.4 is a hundred times more stable than 2.6, no? On the bright side I recently (2.6.14.5) started testing 2.6.latest on my firewall box and it runs with only one config file change: copy /etc/modules.conf to /etc/modprobe.conf. http://bugsplatter.mine.nu/test/boxen/deltree/ Grant. -- Cats are smarter than dogs. You can't make eight cats pull a sled through the snow.
From: Loki Harfagr on 16 Jan 2006 12:39 Le Mon, 16 Jan 2006 23:05:15 +0800, Chu Mai Fat a ?crit?: > If you don't know the answer, don't bother replying. Surely your time > would be better utilised sodomising your shipmates. Please don't do any harm to chipmunks, they're so nice :-) > With kind regards Ah, I can hear envy in your "phras?" ;D)
From: Eef Hartman on 16 Jan 2006 14:18
Chu Mai Fat <ChuMaiFat(a)nowhere.com> wrote: > I was under the impression that odd numbered kernels, ie 2.1.x, 2.3.x > and 2.5.x were development kernels and should be updated but that even > numbered kernels were considered stable and if they contained all the > needed functionality then they were suitable and sufficient for general > use. That scheme isn't used anymore. The "stable kernel" gets updated for security and bugfix reasons, giving the 2.6.N.* versions, and _in the same time_ the NEXT upgrade is being developed as 2.6.N+1 (and when it gets reasonable stable it becomes a "rcX", a Release Candidate). As soon as it DOES gets released, that version will get the .1 etc. SUBversions, while the development team goes on with 2.6.N+2. This way the releases don't got to be SO different that you would have to learn a new kernel every once in a while, the differences between releases are smaller while they still _will_ get new functionality (the old even/odd scheme didn't allow for new functionality in the "stable" kernel, so as soon as a "odd" one DID get released you got a totally different kernel). PS: there also some teams that still maintain the older "major" releases, like 2.4.x and even 2.2.x, but those are pure maintenance updates. And even Linux needs security fixes every once in a while. -- ******************************************************************** ** Eef Hartman, Delft University of Technology, dept. EWI/TW ** ** e-mail: E.J.M.Hartman(a)math.tudelft.nl, fax: +31-15-278 7295 ** ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands ** ******************************************************************** |