Re: Re: time is running out

Der Herr Hofrat wrote:
>>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.
>>
> 
> will check - I guess this could be the cause - I unfortunately don't remember 
having received that report - and looking at the archive for Jan and Feb I noticed
> that I did not receive all mails from the list - if you find a bug in rtlinux and
> I don't send any reply within two or three days pleas send it to me direcltly at 
<[email protected]> until this mail problem is resolved (guess its on my end)

Thanks.

You can find my question in the september 2004 archive:
http://www2.fsmlabs.com/pipermail/rtl/2004-September/013927.html
BTW, can't fsmlabs make this archive searchable?

Already in february 2002 some people reported problems with clocks running
too fast.

Theo

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