Is the clockevent resolution fine-grained enough?

Is the clockevent resolution fine-grained enough?

[Marko Rauhamaa]

It would appear the new clockevent API has a one-nanosecond resolution.
It certainly looks sufficiently fine-grained, but I'm afraid it's too
coarse for some applications.

In our application, we need periodic clock interrupts at about 100 kHz.
If the (programmable) frequency must be rounded to the nearest
nanosecond, we have a cumulative error of

   100,000 * 0.5 ns/s = 50 µs/s

We need to maintain the cumulative error within, say, 1 ms/day, or
11 ns/s. (The error is not measured against real time, but between
different parts of our hardware that are run off of the same clock.)

For our needs, we have built our own "clockevent" system that has a
nominal one-femtosecond precision. The nanosecond resolution would be
sufficient if there was a way to "nudge" the next interrupt by a
nanosecond from the interrupt handler.


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/

Re: Is the clockevent resolution fine-grained enough?

[Thomas Gleixner]

On Thu, 2007-03-01 at 18:34 -0800, Marko Rauhamaa wrote:
> It would appear the new clockevent API has a one-nanosecond resolution.
> It certainly looks sufficiently fine-grained, but I'm afraid it's too
> coarse for some applications.

That's an academic exercise, or are you talking about some real world
hardware which runs Linux ?

> In our application, we need periodic clock interrupts at about 100 kHz.

With a stock kernel ?

> If the (programmable) frequency must be rounded to the nearest
> nanosecond, we have a cumulative error of
> 
>    100,000 * 0.5 ns/s = 50 µs/s
> 
> We need to maintain the cumulative error within, say, 1 ms/day, or
> 11 ns/s. (The error is not measured against real time, but between
> different parts of our hardware that are run off of the same clock.)

clockevents is based on the monotonic system clock and depends on the
accuracy of that and the device which deliveres the interrupts.

> For our needs, we have built our own "clockevent" system that has a
> nominal one-femtosecond precision. The nanosecond resolution would be
> sufficient if there was a way to "nudge" the next interrupt by a
> nanosecond from the interrupt handler.

There is nothing to nugde. The clockevent subsystem operates on absolute
time, so there is no cummulative error, except you setup your timers
relative per event.

	tglx

Re: Is the clockevent resolution fine-grained enough?

[Marko Rauhamaa]

Thomas Gleixner <tglx@linutronix.de>:

> On Thu, 2007-03-01 at 18:34 -0800, Marko Rauhamaa wrote:
> > It would appear the new clockevent API has a one-nanosecond
> > resolution. It certainly looks sufficiently fine-grained, but I'm
> > afraid it's too coarse for some applications.
> 
> That's an academic exercise, or are you talking about some real world
> hardware which runs Linux ?

Real hardware running linux.

> > In our application, we need periodic clock interrupts at about 100
> > kHz.
> 
> With a stock kernel ?

Well, with a "clockevent" patch of our own. We'd like to use a stock
kernel, though.

> > If the (programmable) frequency must be rounded to the nearest
> > nanosecond, we have a cumulative error of
> > 
> >    100,000 * 0.5 ns/s = 50 µs/s
> 
> clockevents is based on the monotonic system clock and depends on the
> accuracy of that and the device which deliveres the interrupts.
> [...]
> There is nothing to nugde. The clockevent subsystem operates on
> absolute time, so there is no cummulative error, except you setup your
> timers relative per event.

I'm afraid you didn't quite understand what I was getting at. Say the
user programs the frequency to be 109,000 Hz. That means a nominal clock
interval of ~9174.3119 ns. Now the clockevent interface forces me to
round it down to 9174 ns. That means the clock interrupts fall behind
with respect to the other parts in the system that implement 109,000 Hz
much more to the letter. The error grows by 34 µs every second so that
after 8 hours, we are lagging by a whole second.


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/

Re: Is the clockevent resolution fine-grained enough?

[Henrique de Moraes Holschuh]

On Fri, 02 Mar 2007, Marko Rauhamaa wrote:
> I'm afraid you didn't quite understand what I was getting at. Say the
> user programs the frequency to be 109,000 Hz. That means a nominal clock
> interval of ~9174.3119 ns. Now the clockevent interface forces me to
> round it down to 9174 ns. That means the clock interrupts fall behind
> with respect to the other parts in the system that implement 109,000 Hz
> much more to the letter. The error grows by 34 µs every second so that
> after 8 hours, we are lagging by a whole second.

Shouldn't you switch to a design where these errors become jitter instead of
cumulative?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Is the clockevent resolution fine-grained enough?

[Thomas Gleixner]

On Fri, 2007-03-02 at 09:24 -0800, Marko Rauhamaa wrote:
> > That's an academic exercise, or are you talking about some real world
> > hardware which runs Linux ?
> 
> Real hardware running linux.

quantum computer ?

> > > In our application, we need periodic clock interrupts at about 100
> > > kHz.
> > 
> > With a stock kernel ?
> 
> Well, with a "clockevent" patch of our own. We'd like to use a stock
> kernel, though.

100khz on a stock kernel with real world hardware:

ROTFL, You made my day. 

> > > If the (programmable) frequency must be rounded to the nearest
> > > nanosecond, we have a cumulative error of
> > > 
> > >    100,000 * 0.5 ns/s = 50 µs/s
> > 
> > clockevents is based on the monotonic system clock and depends on the
> > accuracy of that and the device which deliveres the interrupts.
> > [...]
> > There is nothing to nugde. The clockevent subsystem operates on
> > absolute time, so there is no cummulative error, except you setup your
> > timers relative per event.
> 
> I'm afraid you didn't quite understand what I was getting at. Say the
> user programs the frequency to be 109,000 Hz. That means a nominal clock
> interval of ~9174.3119 ns. Now the clockevent interface forces me to
> round it down to 9174 ns. That means the clock interrupts fall behind
> with respect to the other parts in the system that implement 109,000 Hz
> much more to the letter. The error grows by 34 µs every second so that
> after 8 hours, we are lagging by a whole second.

Sorry man. Did you actually read what I wrote ? 

> The clockevent subsystem operates on absolute time, so there is no
> cummulative error

Again: clockevents operate on absolute time, so it is simply the fault
of the user, when he decides to do something stupid like:

femto_seconds_t interval;

timer_function()
{
	do_whatever_you_need_to_do();
	set_next_event(interval, RELATIVE);
}

instead of 

yokto_seconds_t interval;
yokto_seconds_t next_event;

timer_function()
{
	do_whatever_you_need_to_do();

	next_event += interval;
	set_next_event(yokto_seconds_to_nsec(next_event), ABSOLUTE);
}

Please read _AND_ understand the clockevents code. Your uber_clockevents
patch is solving PEBKAC.

	tglx

Re: Is the clockevent resolution fine-grained enough?

[Marko Rauhamaa]

Thomas Gleixner <tglx@linutronix.de>:

> 100khz on a stock kernel with real world hardware:
> 
> ROTFL, You made my day. 

I don't know why you find that rate unbelievable.

> Sorry man. Did you actually read what I wrote ? 
> 
> > The clockevent subsystem operates on absolute time, so there is no
> > cummulative error

You are right. I misunderstood what you meant by "absolute time".

> timer_function()
> {
> 	do_whatever_you_need_to_do();
> 
> 	next_event += interval;
> 	set_next_event(yokto_seconds_to_nsec(next_event), ABSOLUTE);
> }
> 
> Please read _AND_ understand the clockevents code. Your uber_clockevents
> patch is solving PEBKAC.

I tried to quickly reconstruct the API from a recent clockevent patch I
found with google (<URL:
http://www.mail-archive.com/mm-commits@vger.kernel.org/msg09566.html>).
I saw the enum "CLOCK_EVT_MODE_PERIODIC" and automatically thought of
using that since my application is periodic. I imagined you wouldn't
have to keep on ordering the notification again in every callback. It's
also difficult to estimate how expensive an operation the explicit
rearming would be in the clock event device (the periodic notifications
can probably be optimized effectively).

You are right. By calling set_next_event() in every callback I can
implement what I want (provided that the API guarantees that the
absolute time can be in the past).


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/