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