Saul wrote:
Gilles Chanteperdrix wrote:
I thought SMI was supposed to increase latencies, but I only
see latencies 60us at any load, unless I start video
capture. Does the latency test absolutely rule out SMI as
the cause?
Not really, e.g. if the video
Saul wrote:
I thought SMI was supposed to increase latencies, but I only see
latencies 60us at any load, unless I start video capture. Does
the latency test absolutely rule out SMI as the cause?
Not really, e.g. if the video capture device is USB-attached, then
Gilles Chanteperdrix wrote:
I thought SMI was supposed to increase latencies, but I only
see latencies 60us at any load, unless I start video
capture. Does the latency test absolutely rule out SMI as
the cause?
Not really, e.g. if the video capture device
I thought SMI was supposed to increase latencies, but I only see
latencies 60us at any load, unless I start video capture. Does
the latency test absolutely rule out SMI as the cause?
Not really, e.g. if the video capture device is USB-attached, then
SMI could possibly remain
Saul wrote:
Philippe Gerum wrote:
Mm, this really looks like some firmware/BIOS cyclic activity, that
would hit the busy loop more or less frequently, depending on the
internal timing of the outer loop. This reminds me that some recent
Intel chipset are known to prevent global SMI disabling
Philippe Gerum wrote:
Saul wrote:
Philippe Gerum wrote:
Mm, this really looks like some firmware/BIOS cyclic activity, that
would hit the busy loop more or less frequently, depending on the
internal timing of the outer loop. This reminds me that some recent
Intel chipset are
Saul wrote:
I have no idea what to try next but thanks for the advice. I think some
progress was made :)
If it is enabled, could you try disabling cpufreq ?
--
Gilles Chanteperdrix.
___
Xenomai-help
Saul wrote:
Philippe Gerum wrote:
It would be nice to known whether the latency test from the testsuite
has correct latency figures, so that we could rule out any SMI issue.
See my reply to Jan Kiszka. The max is 55us, but I've just noticed that
starting xawtv using the bttv driver causes
Gilles Chanteperdrix wrote:
I have no idea what to try next but thanks for the advice. I think some
progress was made :)
If it is enabled, could you try disabling cpufreq ?
Previously at boot there was a message saying my CPU doesn't support cpufreq.
But just to be sure, the tests that
Saul wrote:
Hi,
I'm trying to run a short test program, just to get into the swing
of this shiny new real-time system. I'm running Xenomai 2.1.0 on
kernel 2.6.15.6
The following program runs a busy delay in primary mode (verified by
enabling the primary mode switch warning) and
Saul wrote:
Hi,
I'm trying to run a short test program, just to get into the swing
of this shiny new real-time system. I'm running Xenomai 2.1.0 on
kernel 2.6.15.6
The following program runs a busy delay in primary mode (verified by
enabling the primary mode switch warning) and calculates the
Philippe Gerum wrote:
It would be nice to known whether the latency test from the testsuite
has correct latency figures, so that we could rule out any SMI issue.
See my reply to Jan Kiszka. The max is 55us, but I've just noticed that
starting xawtv using the bttv driver causes an overrun in
Jan Kiszka said:
No obvious problem with your program. Does the latency test of
Xenomai show any significant times? Maybe the SMI workaround does not
catch all issues on your system (though up to 60 ms jitter is still
quite a lot).
This is after a few minutes with dd running to disk
Hi,
I'm trying to run a short test program, just to get into the swing
of this shiny new real-time system. I'm running Xenomai 2.1.0 on
kernel 2.6.15.6
The following program runs a busy delay in primary mode (verified by
enabling the primary mode switch warning) and calculates the time taken.
14 matches
Mail list logo
