> 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 ?)
It is a software layer - no hardware prhibiting this - so if you have a X-server doing cli/sti in the driver or a binary driver that does somthing like that - they adeos can't stop 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. >a could you run the test code in the adeos cvs repository and send me the numbers ? hofrat
