Dirk Roloff wrote:
Am Donnerstag, 11. März 2004 20:04 schrieb Paolo Mantegazza:
Hi Paolo,
Dirk Roloff wrote:
Have you tried using rt_get_cpu_time_ns to avoid mixing up with Linux
stuff?
No i don't because i am not using rtai. I "just" use an adeos patched kernel.
But i changed the do_gettimeofday() by a rdtsc call. I dont want to know the
time,
just the time elapsed. So i dont need the time calculation done by
do_gettimeofday()
and i avoid mixing stuff. But the results are the same. :-(
Have you checkd the interrupt level acknolwdge jitter/latency using
the calibration tool available in RTAI?
again - no rtai
Can you change your code so that it can be used anywhere? In such a case
it would be simple to run it on a safe machine (e.g. mine) and see if it
can be repeated, or is machine specific (yours).
Yes but it will not help a lot. I can't see such a latency on other machines.
f.e. on my Box here at home 7-17 MicroSec in the adeos domain.
And i try stressing the Box- but its a complete different h/ware.
So it must be the celeron box or some kernel/compiler settings on it.
But what is able to delay the delivery of an interrupt if there is no one
calling cli or masking irq's (Both is prohibited by adeos isn't it ?)
One thing would be waking a suspended cpu - but i disabled APM.
Someone told me Intel SpeedStep switching the mode will take hundrets of
MicroSecs
but i didn't find what this is yet. Have to google some more.
On some of the newest PC chipsets there seems to be a lot of
possibilities to programm chipsets so that real time bocomes unfeasable.
The locking of the bus may come from smart cards and a few other things.
You are not using RTAI but in RTAI there is a README with a way to
reprogram INTEL chipsets to avoid one of those problems.
Paolo.
