On Mon, 26 Apr 2010, Vieri wrote: > I ran the following and it supposedly updated my system time while ntpd was > running: > > # ps ax | fgrep ntp > 1256 ? Ss 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u ntp:ntp > 1623 pts/14 S+ 0:00 fgrep ntp > > # ntpdate -b -u pool.ntp.org > 26 Apr 19:41:18 ntpdate[2791]: step time server 163.117.131.239 offset > 0.142263 sec
Steves posted the reason - the -u flag causes it to bypass the normal ports, and so does work in this instance. > By the way, as a side question, on another server I see this: > > # ntpq -c peers > remote refid st t when poll reach delay offset jitter > ============================================================================== > inf-srv1.hospit .LOCL. 1 u 56 64 377 0.314 21755.8 7.634 > > Not sure what LOCL means but I'll refer to the NTP docs (inf-srv1 is my > LAN Windoze time server). It may mean that it's using it's internal clock as the master source. If so, then it's trust it as far as I could spit a rat... Try this: ntpq host inf-srv1 (or it's IP addresS) peers and find out what peers it's using. It's just possible that your server is actually more accurate that your LAN server... Give your server a few more peers and find out - just list pool.ntp.org in the /etc/ntp.conf file a few times (and restart ntpd) > Anyway, back to the faulty new server (which reports a stratum of 3 > after ntpd has been running for a while and sync'ing to pool.ntp.org): The stratus is just how far it is away from stratum 1 - which is deemed to be synchronised to "true" time - usually derived from GPS, local atomic clock or MSF type radio. (I used to run an MSF clock synced NTP server for a while) So a host synchronised to a stratum 1 server will be at stratum 2, and hosts synchronised to a stratum 2 server will be at stratum 3. If you synchronise to a mixture, then your host will be somewhere in the range, depending on how good it reckons the other are... > it's supposed to be a good motherboard (Asus) but I'm running a > relatively "old" kernel (2.6.23). Googling around suggests me to try to > boot with "noapic" if I keep seeing my clock drift so much. > > # more /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 103 0 0 1 IO-APIC-edge timer > 1: 2151 0 0 9 IO-APIC-edge i8042 > 4: 12772543 13217932 9603064 7661766 IO-APIC-edge serial That's a rather high number of serial interrupts... Do you have a serial console, or using the serial link with Linux HA? In-general, I like ASUS motherboards though and use them a lot myself. > 8: 1 0 1 0 IO-APIC-edge rtc > 9: 0 0 0 1 IO-APIC-fasteoi acpi > 12: 0 0 0 4 IO-APIC-edge i8042 > 14: 2234 73664 0 2470 IO-APIC-edge ide0 > 16: 28322780 51914617 40744985 39615361 IO-APIC-fasteoi eth0 > 17: 63242610 42157366 43790794 48255583 IO-APIC-fasteoi eth1 > 18: 1348544 0 0 1 IO-APIC-fasteoi eth2 > 20: 9006839 8244295 6076595 4923525 IO-APIC-fasteoi ahci > 21: 162750903 140985080 176469550 166839225 IO-APIC-fasteoi wcte12xp0 > 22: 16662710 18210608 12053147 12739782 IO-APIC-fasteoi HFC-multi > NMI: 0 0 0 0 > LOC: 64546905 64546897 64546897 64546897 > ERR: 0 > MIS: 0 > > I have 3 PCI cards: 1 PRI, 1 quad BRI, 1 dual ethernet. > > Could booting with "noapic" help? Doubt it, but iy's worth a try. Personally, I'd try more NTP hosts first. (Especially knowing you're syncing to a windoze host ;-) > What about my PCI devices? Will they be stable even with "noapic"? > The reason I got this new mobo is that the previous hardware froze the > system with a kernel crash. In fact, I rsync'ed to this new hardware (so > identical system software) and it has been running flawlessly for more > than a week now, while it used to crash/freeze once a day (another Asus > board, by the way). My only problem now is with the d...@!mned clock... > > As far as syslog messages, I don't see anything wrong. No errors whatsoever. > > Thanks for your time. I'll try to boot with noapic and cross my fingers. Good luck.. What may also help is compiling a custom kernel for your hardware - it's what I do by default, but I appreciate that's not for everyone, however it is the best way to make sure you have the kernel tuned exactly to your hardware needs. Gordon -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
