cyclictest abstime vs. reltime

cyclictest abstime vs. reltime

[Luiz Capitulino]

Hello,

We're doing some scheduling latency measurements with KVM. While
analyzing some traces and reading cyclictest code in the process,
I found out that by default cyclictest uses the absolute time
algorithm, which basically does:

clock_gettime(&now)
next = now + interval   /* interval == 1000us */
/* do some quick stuff */
while() {
    clock_nanosleep(&next) /* ie. sleeps until now + 1000us, 'next' is abs */
    clock_gettime(&now)
    diff = calcdiff(now, next)
    /* update a bunch of stats and the histogram data, also
       check if we're finished */
    next += interval
}

Now, doesn't this mean that the timerthread will actually sleep less
than interval? This is so because we have fixed sleeping points which
don't take into consideration the sleeping latency nor the bunch of
things the timerthread does (eg. update histogram).

If I'm making sense, won't this behavior cause better numbers to be
reported?

I compared abstime and reltime in bare-metal, and got the following
results (cyclictest [-r] -m -n -q -p99 -l 1000000):

abstime mode:

# Min Latencies: 00001
# Avg Latencies: 00001
# Max Latencies: 00003

reltime mode:

# Min Latencies: 00003
# Avg Latencies: 00003
# Max Latencies: 00008

(Yes, this machine is pretty modern and well setup for RT. The results
above are pretty deterministic. Also, I've ran hwaltdetect for hours
and got no SMIs).

The relative time algorithm, on the other hand, is exactly what I expected
I would see when I looked at the code:

/* do some quick stuff */
while() {
    clock_getttime(&now)
    clock_nanosleep(&interval) /* interval == 1000us */
    expected = now + interval
    clock_getttime(&now)
    diff = calcdiff(now, expected);
    /* update a bunch of stats and the histogram data, also
       check if we're finished */
}

So, my question boils down to: is there a relevant difference between
the two modes? Why isn't reltime the default mode?

Re: cyclictest abstime vs. reltime

[Uwe Kleine-König]

Hello Luiz,

On Wed, Dec 17, 2014 at 03:16:50PM -0500, Luiz Capitulino wrote:
> So, my question boils down to: is there a relevant difference between
> the two modes? Why isn't reltime the default mode?
I don't know, but I think in reality you want abstime. Consider a process
that does something with items that pass at your machine on a belt conveyor.
Then you need to handle one item (say) each 200ms and using reltime means
that your latencies add and even with a latency of 1µs you'd miss
approx. 1 item per year.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cyclictest abstime vs. reltime

[John Ogness]

On 2014-12-17, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> We're doing some scheduling latency measurements with KVM. While
> analyzing some traces and reading cyclictest code in the process, I
> found out that by default cyclictest uses the absolute time algorithm,
> which basically does:
>
> clock_gettime(&now)
> next = now + interval   /* interval == 1000us */
> /* do some quick stuff */
> while() {
>     clock_nanosleep(&next) /* ie. sleeps until now + 1000us, 'next' is abs */
>     clock_gettime(&now)
>     diff = calcdiff(now, next)
>     /* update a bunch of stats and the histogram data, also
>        check if we're finished */
>     next += interval
> }
>
> Now, doesn't this mean that the timerthread will actually sleep less
> than interval?

Correct. In cyclictest you are not specifying sleep time. You are
specifing the wake interval.

> This is so because we have fixed sleeping points which don't take into
> consideration the sleeping latency

Sleep latency is taken into account. That is exactly what cyclictest
measures.

> nor the bunch of things the timerthread does (eg. update histogram).

cyclictest does not (and should not) care about this.

> If I'm making sense, won't this behavior cause better numbers to be
> reported?

Using _relative_ mode causes _worse_ numbers to be reported because it
assumes that a new relative time can be prepared and set
instantaneously, which is not correct. So you are not only measuring
sleep latency, but also mixing in timer setup duration. I think these
numbers would be misleading, since I would expect real-world RT projects
to be using absolute time.

Absolute (and relative) mode mixes in timer interrupt handling
duration. But that is appropriate here since we are not only interested
in how good the hardware timer is, but also how fast PREEMPT_RT can
allow software to respond to it.

John Ogness

Re: cyclictest abstime vs. reltime

[Luiz Capitulino]

On Thu, 18 Dec 2014 11:04:38 +0100
John Ogness <john.ogness@linutronix.de> wrote:

> On 2014-12-17, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > We're doing some scheduling latency measurements with KVM. While
> > analyzing some traces and reading cyclictest code in the process, I
> > found out that by default cyclictest uses the absolute time algorithm,
> > which basically does:
> >
> > clock_gettime(&now)
> > next = now + interval   /* interval == 1000us */
> > /* do some quick stuff */
> > while() {
> >     clock_nanosleep(&next) /* ie. sleeps until now + 1000us, 'next' is abs */
> >     clock_gettime(&now)
> >     diff = calcdiff(now, next)
> >     /* update a bunch of stats and the histogram data, also
> >        check if we're finished */
> >     next += interval
> > }
> >
> > Now, doesn't this mean that the timerthread will actually sleep less
> > than interval?
> 
> Correct. In cyclictest you are not specifying sleep time. You are
> specifing the wake interval.
> 
> > This is so because we have fixed sleeping points which don't take into
> > consideration the sleeping latency
> 
> Sleep latency is taken into account. That is exactly what cyclictest
> measures.
> 
> > nor the bunch of things the timerthread does (eg. update histogram).
> 
> cyclictest does not (and should not) care about this.
> 
> > If I'm making sense, won't this behavior cause better numbers to be
> > reported?
> 
> Using _relative_ mode causes _worse_ numbers to be reported because it
> assumes that a new relative time can be prepared and set
> instantaneously, which is not correct. So you are not only measuring
> sleep latency, but also mixing in timer setup duration. I think these
> numbers would be misleading, since I would expect real-world RT projects
> to be using absolute time.

This makes sense. Thanks a lot for your answers!

> 
> Absolute (and relative) mode mixes in timer interrupt handling
> duration. But that is appropriate here since we are not only interested
> in how good the hardware timer is, but also how fast PREEMPT_RT can
> allow software to respond to it.
> 
> John Ogness
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>