[svlug] Re: time slows down.

Rafael Skodlar raffi at linwin.com
Tue Oct 15 13:27:14 PDT 2002


On Tue, Oct 15, 2002 at 09:14:43PM +0200, Ira Abramov wrote:
> Quoting Rafael Skodlar, from the post of Tue, 15 Oct:
> > 
> > date shows system clock while hwclock shows hardware clock. Either tool
> > can be used to udjust time in it's domain.
> 
> I know. I used hwclock to see the correct time ?nd the system time side
> by side.
> 
> > > current load average is 1.66, 1.44, 1.39 but most of the day it's
> 
> this was my problem. apperently there was a stuck process that held the
> system at a load average of 1-2 for over 3-4 days and I didn't notice (a
> qmail process trying to bounce a 160 meg mail item on a partition that
> ran out of space, the (ab)user has been punished)

Good reason not to use qmail ;-) (MTA war, yeah!)

> 
> what I was demonstrating was:
> 
> > > green:/etc# date;hwclock -ru
> > > Tue Oct 15 11:55:36 IST 2002
> > > Tue Oct 15 11:55:35 2002  -1.042848 seconds
> 
> ...
> 
> > > green:/etc# date;hwclock -ru
> > > Tue Oct 15 12:06:12 IST 2002
> > > Tue Oct 15 12:10:18 2002  -0.639831 seconds
> 
> while 15 minutes pass in the real world (the hwclock is correct) the
> system clock was losing time by tens of percents and counted only 11. it
> stopped since I solved the runaway process problem and uptime went back
> to 0. now systime and hwclock agree, but still I can't see why should
> the system time have been slown down so much. this is very worrying and
> maybe should be reported on lkml? I knew old SMP kernels used to do
> this, but this is a recent UP kernel on a UP machine!

That's disappointing. Your load was not heavy at all. I have systems
with load close to 6 sometimes and users don't complain at all. One
process should not take the whole thing over so that the clock goes
completely out of sync. I was always wondering since mainframe days, why
would OS keep track of it's own time which tends to go out of sync
during spurrious HW interrupts or poorly written software? Hardware
clock can keep track of time much better if designed properly. PC clocks
are inacurate due to low Xtal frequency, 32 KHz, and no thermal
compensation.

Assuming system uses HW clock and needs a timestamp for dealing with
files or whatever it gets it from HW clock then goes back doing other
things without updating system clock (wasting cycles; how many?). In
early DOS days time wasted on updating system clock and refreshing
memory was significant, over 10% I believe. I'm not sure what the
numbers are today on modern motherboards and better(?) memory design but
it would be interesting to know.

Hardware clock designed to handle hardware interrupts for specific
processes would guarantee timeslot to a process and prevent it to take
the system over but systems are not built that way.

-- 
Rafael



More information about the svlug mailing list