Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Right before the cpu is put to sleep by cp15 the I-cache is being disabled in 
> the idle task. I took this part out. So I leave the I-cache enabled when the 
> cpu goes into the idle mode. I suppose that there is a reason for disabling 
> the cache. I will ask my wise ARM book on monday. If this issue doesn't belong 
> here (xenomai list) just say a word :)

Yes, you probably can not do that. You will find the answer in the
documentation for the arm926EJS core, since this file only concerns this
core.

On the other hand, as Bosko suggested, if you use the nohlt kernel
option, you will avoid the idle function altogether, and the I-cache
will not be disabled then re-enabled.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Karl Tyss wrote:
>> Right before the cpu is put to sleep by cp15 the I-cache is being disabled in 
>> the idle task. I took this part out. So I leave the I-cache enabled when the 
>> cpu goes into the idle mode. I suppose that there is a reason for disabling 
>> the cache. I will ask my wise ARM book on monday. If this issue doesn't belong 
>> here (xenomai list) just say a word :)
> 
> Yes, you probably can not do that. You will find the answer in the
> documentation for the arm926EJS core, since this file only concerns this
> core.
> 
> On the other hand, as Bosko suggested, if you use the nohlt kernel
> option, you will avoid the idle function altogether, and the I-cache
> will not be disabled then re-enabled.

Note that the effect you observe is due to the very special nature of
your setup: since you run no significant user-space load, the irq
handling function may remain in the cache, but on a realistically loaded
system, the irq handling function will not be able to remain in the
cache, so, the disabling of the I-cache in the idle function will not
change anything with regard to the worst case latency.

Also note that using a GPIO to assess the timer interrupt latency is a
bad idea: if you want to assess the timer interrupt you should register
a timer, because the path in the kernel is different for the timer
interrupt than for other interrupts and especially for multiplexed GPIO
interrupts. But doing all this by yourself and risking to have problem
that we already solved is not a good idea; what you should really do is
use the latency test provided by Xenomai. It is relatively simple,
covers all the cases, and is validated on many platforms.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

Hi Gilles,
> Note that the effect you observe is due to the very special nature of
> your setup: since you run no significant user-space load, the irq
> handling function may remain in the cache, but on a realistically loaded
> system, the irq handling function will not be able to remain in the
> cache, so, the disabling of the I-cache in the idle function will not
> change anything with regard to the worst case latency.
>   

you are absolutely right. Its also clear to me that the maximum 
latencies are more relevant but in my case I also have to know how the 
latencies are if the system has no load. This will be the most probable 
case in my system. This is a special case but I believe also a pretty 
common one so I have to be able to explain the behaviour in detail. 
Thanks to your help I am able to do this now :)

> Also note that using a GPIO to assess the timer interrupt latency is a
> bad idea: if you want to assess the timer interrupt you should register
> a timer, because the path in the kernel is different for the timer
> interrupt than for other interrupts and especially for multiplexed GPIO
> interrupts. But doing all this by yourself and risking to have problem
> that we already solved is not a good idea; what you should really do is
> use the latency test provided by Xenomai. It is relatively simple,
> covers all the cases, and is validated on many platforms.
>   
Acually I have already been using the latency test from xenomai to find 
the average and max latencies but the GPIO way seemed for me to be the 
best way to get a continous data set in order to plot the results. I am 
now able to record about half a million interrupts contineously in a 
relative short period of time. These results alone are not 
representative but in combination with the latency test.

So to come to an end... thank you for the quick help and if I find out 
something more I'll post it for the future generations :D

Regards,
Karl Tyss

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Acually I have already been using the latency test from xenomai to find 
> the average and max latencies but the GPIO way seemed for me to be the 
> best way to get a continous data set in order to plot the results.

latency has an option which allows to record histograms and output the
results when exiting. So, you can plot the results too.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

----------  Weitergeleitete Nachricht  ----------

Betreff: Re: [Xenomai-help] IRQ-Latency when in idle State on ARM
Datum: Freitag, 5. Juni 2009
Von: Karl Tyss <karl.tyss@domain.hid>
An: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

Am Freitag, 5. Juni 2009 17:01:13 schrieb Karl Tyss:
> Karl Tyss wrote:
> > Disabling the I- or D-cache is available as an option by using
> > menuconfig under system-type.
>
> Ok. I misread the configuration file. Also note that the idle function
> for arm926 core only disables the I-cache if it was not already
> disabled. So, if you are running with I-cache disabled, fiddling with
> this code should not change anything.

Excuse me if I didn't say it clearly. English is not my native language. Your 
hint helped me to avoid longer latencies while in idle state with both caches 
on. So my configuration is now I-cache on and D-cache on. Then I commented out 
the two lines in the idle task which torn the cache off and on again. Now I see 
no differences in the lantecies when an idle task is being interrupted. The 
"demux_irq" function (not the exact name) in the gpio.c from the at91 tree is 
significantly slower if I-cache was disabled and enabled before.

> 13us or 15us is still ridiculous on ARM. 3us even more. Average values
> are irrelevant, what matters is the worst case. If you only get a 3us
> difference when loading the system, then you are not loading the system
> enough. You should see latencies above 100us when properly loading the
> system. As I already told you, the way to proper load the system is to
> run LTP.

Thanx. I'll put LTP as my next testing task :)

> Disabling the cache is not recommended.

Right before the cpu is put to sleep by cp15 the I-cache is being disabled in 
the idle task. I took this part out. So I leave the I-cache enabled when the 
cpu goes into the idle mode. I suppose that there is a reason for disabling 
the cache. I will ask my wise ARM book on monday. If this issue doesn't belong 
here (xenomai list) just say a word :)

Thanx,
Karl Tyss

-------------------------------------------------------------

[Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

Hi,

I am running Xenomai 2.4.7 and linux-2.6.28 on ATMELs AT91SAM9G20-EK. I
noticed a strange thing while measuring IRQ latency with a logic
analyser. Basically I just insert a module with insmod into the kernel.
The module creates an interrupt with "rt_intr_create" and the isr only
triggers a gpio pin up and down.

I also turned I- and D-caches off to avoid the effects of cache-flushes
on a context switch. If the kernel runs the idle process (cpu_idle) the
latency is about 2us larger than with a load. It seems be irrelevant
what kind of load I generate. To generate load I am now using a "stress"
application I found. The simplest case is that it runs a loop and calls
the rand() function.

The "idle"-latency is about 25us in this case and the "stressed" one
about 23 us.

If i run the same test on a kernel without the xenomai extensions i
dont get an difference between the latencies.

Has anyone any ideas why this is happening?

Best Regards,
Karl Tyss




Mit Freundlichen Grüßen,
Karl Tyss




---------------------------------------------------------------------------------------
This email including its attachments is intended for the person or
entity only to which it is addressed. It may contain confidential and/or
privileged material. Any review, forwarding, dissemination, other use
of, or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited.
If you received this email in error, please contact the sender and 
delete the material from any computer system. 
---------------------------------------------------------------------------------------

Eppendorf AG, Hamburg, Barkhausenweg 1, 22339 Hamburg,
Amtsgericht Hamburg HRB 76249
Vors. des Aufsichtsrats: Dipl.-Ing. Adrian Déteindre
Vorstand: Klaus Fink (Vorsitzender), Detmar Ammermann,
Dr. Heinz G. Koehn, Dr. Michael Schroeder

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Rainer Treptow

Eppendorf Biochip Systems GmbH, Hamburg, Amtsgericht Hamburg, HRB 96641
Geschäftsführer: Dr. Sven Buelow

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Boris von Beichmann

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Hi,
> 
> I am running Xenomai 2.4.7 and linux-2.6.28 on ATMELs AT91SAM9G20-EK. I
> noticed a strange thing while measuring IRQ latency with a logic
> analyser. Basically I just insert a module with insmod into the kernel.
> The module creates an interrupt with "rt_intr_create" and the isr only
> triggers a gpio pin up and down.
> 
> I also turned I- and D-caches off to avoid the effects of cache-flushes
> on a context switch. If the kernel runs the idle process (cpu_idle) the

This is a bad idea, cache helps to improve the overall performance of
your system. If you are worried about cache flushes during context
switches, you should enable the FCSE option (in guaranteed mode, if you
do not intend to create more than 95 processes or use more than 32
Mbytes per process).

> latency is about 2us larger than with a load. It seems be irrelevant
> what kind of load I generate. To generate load I am now using a "stress"
> application I found. The simplest case is that it runs a loop and calls
> the rand() function.

That is hardly sufficient. What we use to correctly stress the system
during our tests is based on a cocktail of LTP (the Linux testing
project), network load with netcat, process creation with an infinite
loop of cat /proc/interrupts and ps.

> 
> The "idle"-latency is about 25us in this case and the "stressed" one
> about 23 us.

Xenomai is about improving the worst case latency of the system, under
load, not about improving the best case latency. So, this difference is
irrelevant.


-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

Hi,

thank you for the quick answer.

The idea with deactivating the caches is to see if they are influencing
this behavior. I also tried out the FCSE option and it did not help. My
issue is that if there is a user space application that starts lots of
short processes/threads and sleeps for a short time, in this case I get
a large jitter. Till this point I was able to find out that it makes a
difference if the idle task is running. 

These simple tests I was running weren't supposed to be relevant stress
tests. I only tried to prevent the kernel entering the idle task and the
simplest way was to start an endless loop doing noting.

So my question was actually is there any explanation to this behavior
and in both cases (yes or no) is this behavior predictable? Perhaps one
can avoid this by modifying the cpu_idle task, so that the system
doesn't necessarily go in a sleep mode.
 
Best regards,
Karl Tyss


Mit Freundlichen Grüßen,
Karl Tyss



>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> 06/05/09
11:31 AM >>> 
Karl Tyss wrote:
> Hi,
> 
> I am running Xenomai 2.4.7 and linux-2.6.28 on ATMELs AT91SAM9G20-EK.
I
> noticed a strange thing while measuring IRQ latency with a logic
> analyser. Basically I just insert a module with insmod into the
kernel.
> The module creates an interrupt with "rt_intr_create" and the isr
only
> triggers a gpio pin up and down.
> 
> I also turned I- and D-caches off to avoid the effects of
cache-flushes
> on a context switch. If the kernel runs the idle process (cpu_idle)
the

This is a bad idea, cache helps to improve the overall performance of
your system. If you are worried about cache flushes during context
switches, you should enable the FCSE option (in guaranteed mode, if
you
do not intend to create more than 95 processes or use more than 32
Mbytes per process).

> latency is about 2us larger than with a load. It seems be irrelevant
> what kind of load I generate. To generate load I am now using a
"stress"
> application I found. The simplest case is that it runs a loop and
calls
> the rand() function.

That is hardly sufficient. What we use to correctly stress the system
during our tests is based on a cocktail of LTP (the Linux testing
project), network load with netcat, process creation with an infinite
loop of cat /proc/interrupts and ps.

> 
> The "idle"-latency is about 25us in this case and the "stressed" one
> about 23 us.

Xenomai is about improving the worst case latency of the system, under
load, not about improving the best case latency. So, this difference
is
irrelevant.


-- 
					    Gilles.



---------------------------------------------------------------------------------------
This email including its attachments is intended for the person or
entity only to which it is addressed. It may contain confidential and/or
privileged material. Any review, forwarding, dissemination, other use
of, or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited.
If you received this email in error, please contact the sender and 
delete the material from any computer system. 
---------------------------------------------------------------------------------------

Eppendorf AG, Hamburg, Barkhausenweg 1, 22339 Hamburg,
Amtsgericht Hamburg HRB 76249
Vors. des Aufsichtsrats: Dipl.-Ing. Adrian Déteindre
Vorstand: Klaus Fink (Vorsitzender), Detmar Ammermann,
Dr. Heinz G. Koehn, Dr. Michael Schroeder

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Rainer Treptow

Eppendorf Biochip Systems GmbH, Hamburg, Amtsgericht Hamburg, HRB 96641
Geschäftsführer: Dr. Sven Buelow

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Boris von Beichmann

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Hi,
> 
> thank you for the quick answer.
> 
> The idea with deactivating the caches is to see if they are influencing
> this behavior. I also tried out the FCSE option and it did not help. My
> issue is that if there is a user space application that starts lots of
> short processes/threads and sleeps for a short time, in this case I get
> a large jitter. Till this point I was able to find out that it makes a
> difference if the idle task is running. 

How large ? If it is something around 200us it is normal for an ARM.
Note that the cache flush is not alone, there is also a TLB flush. If
you do not want the TLB flush, then you will have to run ucLinux.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Hi,
> 
> thank you for the quick answer.
> 
> The idea with deactivating the caches is to see if they are influencing
> this behavior. I also tried out the FCSE option and it did not help. My
> issue is that if there is a user space application that starts lots of
> short processes/threads and sleeps for a short time, in this case I get
> a large jitter. Till this point I was able to find out that it makes a
> difference if the idle task is running. 
> 
> These simple tests I was running weren't supposed to be relevant stress
> tests. I only tried to prevent the kernel entering the idle task and the
> simplest way was to start an endless loop doing noting.
> 
> So my question was actually is there any explanation to this behavior
> and in both cases (yes or no) is this behavior predictable? Perhaps one
> can avoid this by modifying the cpu_idle task, so that the system
> doesn't necessarily go in a sleep mode.

Ok. If I understand correctly, the AT91SAM9G20 uses an arm926ejs core,
and in arch/arm/mm/proc-arm926.S, the idle function disables and
re-enables the I-cache, so, that may be the source of your problems.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

Hi,

5 minutes ago I found out that one of the caches definately has to
cause the problem. I believe I would have to spent couple of more days
to find out why. 

Your hint was a bulls eye. I tried a dirty trick and commented out the
two lines responsible for disabling the I-cache.  It helped. I wonder if
it leads to other problems. I will test it and post my results.

Thank you both for the quick and productive help.

Best regards,
Karl Tyss
 

Mit Freundlichen Grüßen,
Karl Tyss



>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> 06/05/09
3:42 PM >>> 
Karl Tyss wrote:
> Hi,
> 
> thank you for the quick answer.
> 
> The idea with deactivating the caches is to see if they are
influencing
> this behavior. I also tried out the FCSE option and it did not help.
My
> issue is that if there is a user space application that starts lots
of
> short processes/threads and sleeps for a short time, in this case I
get
> a large jitter. Till this point I was able to find out that it makes
a
> difference if the idle task is running. 
> 
> These simple tests I was running weren't supposed to be relevant
stress
> tests. I only tried to prevent the kernel entering the idle task and
the
> simplest way was to start an endless loop doing noting.
> 
> So my question was actually is there any explanation to this
behavior
> and in both cases (yes or no) is this behavior predictable? Perhaps
one
> can avoid this by modifying the cpu_idle task, so that the system
> doesn't necessarily go in a sleep mode.

Ok. If I understand correctly, the AT91SAM9G20 uses an arm926ejs core,
and in arch/arm/mm/proc-arm926.S, the idle function disables and
re-enables the I-cache, so, that may be the source of your problems.

-- 
					    Gilles.



---------------------------------------------------------------------------------------
This email including its attachments is intended for the person or
entity only to which it is addressed. It may contain confidential and/or
privileged material. Any review, forwarding, dissemination, other use
of, or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited.
If you received this email in error, please contact the sender and 
delete the material from any computer system. 
---------------------------------------------------------------------------------------

Eppendorf AG, Hamburg, Barkhausenweg 1, 22339 Hamburg,
Amtsgericht Hamburg HRB 76249
Vors. des Aufsichtsrats: Dipl.-Ing. Adrian Déteindre
Vorstand: Klaus Fink (Vorsitzender), Detmar Ammermann,
Dr. Heinz G. Koehn, Dr. Michael Schroeder

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Rainer Treptow

Eppendorf Biochip Systems GmbH, Hamburg, Amtsgericht Hamburg, HRB 96641
Geschäftsführer: Dr. Sven Buelow

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Boris von Beichmann

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Hi,
> 
> 5 minutes ago I found out that one of the caches definately has to
> cause the problem. I believe I would have to spent couple of more days
> to find out why. 
> 
> Your hint was a bulls eye. I tried a dirty trick and commented out the
> two lines responsible for disabling the I-cache.  It helped. I wonder if
> it leads to other problems. I will test it and post my results.
> 
> Thank you both for the quick and productive help.

In my understanding, Icache can not be disabled using kernel
configuration options on 926, the only thing that can be done for a 926
 is to set the Dcache to writethrough mode. How did you manage to
disable the caches ?

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Hi,
> 
> 5 minutes ago I found out that one of the caches definately has to
> cause the problem. I believe I would have to spent couple of more days
> to find out why. 
> 
> Your hint was a bulls eye. I tried a dirty trick and commented out the
> two lines responsible for disabling the I-cache.  It helped. I wonder if
> it leads to other problems. I will test it and post my results.
> 
> Thank you both for the quick and productive help.

Also, let me insist: 2 microseconds on ARM is peanuts. Really, it is
insignificant, you will get much worse jitters than that with a properly
loaded system.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

Disabling the I- or D-cache is available as an option by using
menuconfig under system-type.

As to the Jitters - I didn't describe it correctly what i was doing. I
disabled the both caches as a trick to test if there is a difference.
The 2 us timing difference was without the caches. With I- and D-cache
online i had a difference of 13 us as average value (15us idle and 3 us
with user space load)

I have to estimate a critical path in order to decide if a timer
interrupt driven periodic task or a xenomai periodic task is better for
my system. As I noticed this effect of the idle task I had to know why
in order to document it or to change the part of the code.

Well, now I know what to do and I have to find out if disabling the
I-cache is critical at this point and if so, how one can avoid it. My
system doesn't have  to save power if its online and I suppose that
disabling this kind of idleness could be a nice feature in the kernel or
xenomai.

So thank you for your help again and have a nice weekend,

Best regards,
Karl Tyss
 

Mit Freundlichen Grüßen,
Karl Tyss



>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> 06/05/09
4:17 PM >>> 
Karl Tyss wrote:
> Hi,
> 
> 5 minutes ago I found out that one of the caches definately has to
> cause the problem. I believe I would have to spent couple of more
days
> to find out why. 
> 
> Your hint was a bulls eye. I tried a dirty trick and commented out
the
> two lines responsible for disabling the I-cache.  It helped. I wonder
if
> it leads to other problems. I will test it and post my results.
> 
> Thank you both for the quick and productive help.

Also, let me insist: 2 microseconds on ARM is peanuts. Really, it is
insignificant, you will get much worse jitters than that with a
properly
loaded system.

-- 
					    Gilles.



---------------------------------------------------------------------------------------
This email including its attachments is intended for the person or
entity only to which it is addressed. It may contain confidential and/or
privileged material. Any review, forwarding, dissemination, other use
of, or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited.
If you received this email in error, please contact the sender and 
delete the material from any computer system. 
---------------------------------------------------------------------------------------

Eppendorf AG, Hamburg, Barkhausenweg 1, 22339 Hamburg,
Amtsgericht Hamburg HRB 76249
Vors. des Aufsichtsrats: Dipl.-Ing. Adrian Déteindre
Vorstand: Klaus Fink (Vorsitzender), Detmar Ammermann,
Dr. Heinz G. Koehn, Dr. Michael Schroeder

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Rainer Treptow

Eppendorf Biochip Systems GmbH, Hamburg, Amtsgericht Hamburg, HRB 96641
Geschäftsführer: Dr. Sven Buelow

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Boris von Beichmann

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Gilles Chanteperdrix]

Karl Tyss wrote:
> Disabling the I- or D-cache is available as an option by using
> menuconfig under system-type.

Ok. I misread the configuration file. Also note that the idle function
for arm926 core only disables the I-cache if it was not already
disabled. So, if you are running with I-cache disabled, fiddling with
this code should not change anything.

> 
> As to the Jitters - I didn't describe it correctly what i was doing. I
> disabled the both caches as a trick to test if there is a difference.
> The 2 us timing difference was without the caches. With I- and D-cache
> online i had a difference of 13 us as average value (15us idle and 3 us
> with user space load)

13us or 15us is still ridiculous on ARM. 3us even more. Average values
are irrelevant, what matters is the worst case. If you only get a 3us
difference when loading the system, then you are not loading the system
enough. You should see latencies above 100us when properly loading the
system. As I already told you, the way to proper load the system is to
run LTP.

> I have to estimate a critical path in order to decide if a timer
> interrupt driven periodic task or a xenomai periodic task is better for
> my system. As I noticed this effect of the idle task I had to know why
> in order to document it or to change the part of the code.

Xenomai latency test is made for that. Run latency -t 2 to measure the
timer interrupt latency, use latency -t 1 to use a Xenomai kernel-space
periodic task, or latency -t 2 to use a Xenomai user-space periodic
task. And I repeat, the only meaningful result of these tests is the
worst case latency, and only when properly loading the system, and when
running this test for a long time (one or two full runs of LTP).

> 
> Well, now I know what to do and I have to find out if disabling the
> I-cache is critical at this point and if so, how one can avoid it. My
> system doesn't have  to save power if its online and I suppose that
> disabling this kind of idleness could be a nice feature in the kernel or
> xenomai.

Disabling the cache is not recommended.

-- 
					    Gilles.

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Bosko Radivojevic]

Karl,

you can try to boot the kernel with 'nohlt' option.

I had a similar problem - like CPU wasn't running on the same clock
rate. My ISR had two different duration times ~500 and ~800 us, always
with the same code execution path.

The similar behavior I couldn't detect on the vanilla kernel.

Thanks to Gilles, 'nohlt' kernel option helped.

Sincerely,
Bosko

Re: [Xenomai-help] IRQ-Latency when in idle State on ARM

[Karl Tyss]

Hi Bosko,

'nohlt' works. The problem with disabling cache in idle mode is gone
when using 'nohlt' option.

Thanks,
Karl Tyss 
 

Mit Freundlichen Grüßen,
Karl Tyss



>>> Bosko Radivojevic <bosko.radivojevic@domain.hid> 06/05/09 2:13 PM
>>> 
Karl,

you can try to boot the kernel with 'nohlt' option.

I had a similar problem - like CPU wasn't running on the same clock
rate. My ISR had two different duration times ~500 and ~800 us, always
with the same code execution path.

The similar behavior I couldn't detect on the vanilla kernel.

Thanks to Gilles, 'nohlt' kernel option helped.

Sincerely,
Bosko



---------------------------------------------------------------------------------------
This email including its attachments is intended for the person or
entity only to which it is addressed. It may contain confidential and/or
privileged material. Any review, forwarding, dissemination, other use
of, or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited.
If you received this email in error, please contact the sender and 
delete the material from any computer system. 
---------------------------------------------------------------------------------------

Eppendorf AG, Hamburg, Barkhausenweg 1, 22339 Hamburg,
Amtsgericht Hamburg HRB 76249
Vors. des Aufsichtsrats: Dipl.-Ing. Adrian Déteindre
Vorstand: Klaus Fink (Vorsitzender), Detmar Ammermann,
Dr. Heinz G. Koehn, Dr. Michael Schroeder

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Rainer Treptow

Eppendorf Biochip Systems GmbH, Hamburg, Amtsgericht Hamburg, HRB 96641
Geschäftsführer: Dr. Sven Buelow

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Boris von Beichmann