Re: Re: time is running out

> 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)

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