9.3 firewall/email server - clock slows down?
Hi all, I've got a weird problem with a 9.3 box. After running for a few hours, the system clock seems to start running extremely slowly - about 1 second for every real 5 seconds. Next time it happens I'm going to check on the hardware clock with hwclock, but I would be very surprised if it is out - I think this is a software problem. The system is fairly basic - it's a firewall using Shorewall and a mail server using Dovecot and sendmail, no GUI at all. Kernel version installed (with the non GPL stuff as well) is 2.6.11.4-21.9, SMP version (it's a hyperthreading box). Does anyone have any ideas, or suggestions for how best to troubleshoot this one? Regards, Danny Smith Midrange Software Design http://www.msd.net.au 61-7-3368-7888 Midrange Software Design Pty. Ltd. does not represent or warrant that the attached files are free from computer viruses or other defects. The attached files are provided, and may only be used, on the basis that the user assumes all responsibility for any loss, damage or consequences resulting directly or indirectly from use of the attached files. This email is confidential. If it includes quoted prices, unless otherwise stated, validity is 14 days from the date of this message. Sales tax, GST and delivery charges are excluded unless noted. Acceptance of any quotation or order is subject to MSD's usual terms and conditions of sale.
On Tue, 4 Oct 2005 08:25:34 +1000, you wrote:
Hi all,
I've got a weird problem with a 9.3 box. After running for a few hours, the system clock seems to start running extremely slowly - about 1 second for every real 5 seconds.
Next time it happens I'm going to check on the hardware clock with hwclock, but I would be very surprised if it is out - I think this is a software problem. The system is fairly basic - it's a firewall using Shorewall and a mail server using Dovecot and sendmail, no GUI at all. Kernel version installed (with the non GPL stuff as well) is 2.6.11.4-21.9, SMP version (it's a hyperthreading box).
Does anyone have any ideas, or suggestions for how best to troubleshoot this one?
You don't mention your hardware details but there was a design decision made back in the stone age that causes the hardware clock to drop a bit under heavy disk IO (like a mail server with possible insufficient cache ram). The technical explanation of the problem is "Critical interrupt masking during disk IO". I don't know if the linux system clock driver compensates for that properly or not. My usual practice (since DOS days, as a matter of fact) has been to have a NIST clock update (like ntpdate) run every 12 or 24 hours. Mike- -- Mornings: Evolution in action. Only the grumpy will survive. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments.
On Tue, 2005-10-04 at 12:27 -0400, Michael W Cocke wrote:
You don't mention your hardware details but there was a design decision made back in the stone age that causes the hardware clock to drop a bit under heavy disk IO (like a mail server with possible insufficient cache ram). The technical explanation of the problem is "Critical interrupt masking during disk IO". I don't know if the linux system clock driver compensates for that properly or not. My usual practice (since DOS days, as a matter of fact) has been to have a NIST clock update (like ntpdate) run every 12 or 24 hours.
Mike-
Or vi /etc/ntp.conf and under "Outside source of synchronized time" add in: server us.pool.ntp.org server us.pool.ntp.org server us.pool.ntp.org Which will get 3 different server IP's. Then do a "chkconfig xntpd on". No more time issue. Brad Dameron SeaTab Software www.seatab.com
participants (3)
-
Brad Dameron -
Danny Smith -
Michael W Cocke