Re: [RFC][PATCH] new timeofday core subsystem (v.A0)

Ulrich Windl
2004-09-06T06:10:26Z

On 3 Sep 2004 at 11:07, Albert Cahalan wrote:

> On Fri, 2004-09-03 at 05:08, Ulrich Windl wrote:
> > On 3 Sep 2004 at 2:42, Albert Cahalan wrote:
>
> > > HZ not being HZ is the source of many foul problems.
> > >
> > > NTP should be able to correct for the error. For systems
> > > not running NTP, provide a fake NTP to make corrections
> > > based on the expected frequency error.
> > >
> > > Based on that, skip or double-up on the ticks to make
> > > them be exactly HZ over long periods of time.
> >
> > I think nobody wants a sawtooth-like timing. Time should
> > proceed as smoothly as possible.
>
> Of course, and all hardware should have ideal clocks.
> Now, back to the real world...

Albert,

I am serious.

>
> The kernel is broken if:
>
> a. HZ is not really HZ

HZ is an integer however.

> b. Timekeeping is via 2 unrelated clocks. (jiffies+offset)

What do you do if one clock lacks resolution, and the other clock lacks digits?
The interrupt clock may suck, but the TSC sucks even more.

> c. HZ is not an integer

HZ is HZ, but the true interrupt frequency is something completely different.

>
> So on box using only clock ticks, steer jiffies
> toward HZ using NTP (or default frequency error value).

Are you saying you are happy with a lcok that less than 1 HZ off? That would be --
in a extreme case -- about 86000 seconds off per day.

> On a box with high-res time, use that instead, and make
> jiffies follow it to satisfy various kernel-internal
> uses of jiffies.

Make jiffies follow variable CPU clock? Are you serious?

>
> Look, if HZ won't be HZ then you can just remove
> the "HZ" define from the kernel. It's useless.

It's not useless, it's a historic standard.

>
> I think we're all sick of the recent time-related
> bugs. I could go for ripping out all the fancy and

Yes.

> broken stuff that was added recently, replacing it
> with the simple Linux 2.4.xx or 2.2.xx code. Swiping

It depends on what you want. The kernel really needs a working framework for
nanoseconds; at least regarding the variables' precision.

> code from DragonflyBSD would be worth investigating.
>
>
>

Regards,
Ulrich