Re: Re: time is running out

Theo Veenker <[email protected]> Mon, 07 Feb 2005 10:04:23 +0100
Newsgroups gmane.linux.real-time.rtlinux.general
Message-ID <[email protected]>
Der Herr Hofrat wrote:
>>I have the same problem as reported about the speed of the clock
>>(which seems to speed up to 2 or 3 times faster than should be) when
>>rtl_sched is loaded on a number of configurations on 2 boxes I test
>>rtlinux on.  Here is one of the latest configs which the problem
>>appears with.  This problem also happens when none of the experimental
>>optimizations are set.  Happens with both gcc 2.95.3 and 3.3.4.
>>ps: Also setting PSC causes regression.sh to segfault and the module
>>becomes unremove-able.  I think I had read something about PSC being
>>broken at some point but I'm not sure...
>>
> 
> 
> Hi All !
> 
>  the problem must have apeard quite some time back - no idea why I never noticed
>  it - at some point I changed the HZ variable in include/asm-i368/param.h from 
>  100 to 1000 (guese whyle trying to reduce the delays of soft-irqs). This change
>  is what is causing the time to advance incorectly as the HZ variable in rtlinux
>  is assumed to be 100 at a few points (which is definitly a bug in rtlinux).
> 
>  quick-fix - correct the line in param.h
> 
> include/asm-i386/apram.h (quite at the top of file)
> #define HZ 1000 -> #define HZ 100
> 
>  will give rtlinux a scan to find the potentially problematic code and make it
>  HZ clean....TODO++
> 
>  The second problem (and that should only be in the latest rc1 tree): the 
>  interrupts emulatoin was changed to trigger the linux side unconditionally
>  which was a hack to kick soft-irq with a low latency independant from the 
>  occurance of hardwar interrupts, and secondly the pending of irqs to linux
>  unconditionally to allow sharing of irqs.
> 
>  patch to rc1 applied - pleas pull the updates from cvs !
> 
>  let me know if this does't solves the problem for you (time was roughly 2-3 
>  times faster with the wrong HZ variable and is now constant against my ntp 
>  server running for about 2h).

Could this also be the cause of CLOCK_GPOS running 150us/s (13 sec in 24h) faster
than CLOCK_REALTIME? I have reported this problem before, but no answer/fix yet.

Theo


_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl