> ----------
> From: Jesse Off[SMTP:[EMAIL PROTECTED]]
> Sent: 26. maj 1998 20:34
> To: Niels Hald Pedersen
> Subject: Re: /dev/rtc
>
> Niels Hald Pedersen wrote:
>
> > X, and 2) at rare, but regular intervals (file flushing daemon or
> > something). In this case my process gets waken up at 100 Hz, or HZ,
> > rather than 1024 Hz. I assume what happens is, that everytime the
> > scheduler preemts, my process gets scheduled once, does its things,
> > yields and will not get schedule before next preemption, because
> other
> > processes scheduled after my process yields, does not yield. So the
> > question after a long story is: Does anybody know of a nice way,
> > _without_kernel_hacking_ to get a pending high (realtime) priority
>
> Hmm... correct me if I'm wrong, but I think the problem is not with
> prioritys and premption, but with the little asm statement 'cli'. X
> is
> setuid root and manipulates directly your videocard hardware, in
> certain, critical parts of the X servers' code, interuppts are
> disabled
> (includeing your rtc cloc interrupt). Same way with doing file
> flushing... when you computer is manipulateing the hard disk, there
> may
> be, (i haven't looked personally), some code blocks that are protected
> by cli(), and sti(). I imagine you would get this same behavior when
> doing anything network intensive, as there are many spots in the
> kernel
> TCP/IP code that are protected with cli() and sti().
>
Thank you for your interest.
I havent checked the XFree86 source either, but I dont think cli/sti-ing
is the major problem. 1) FWIW, modern programmers are typically very
cautious not to have long (in terms of time) stretches of code cli'ed,
as this causes all kinds of trouble elsewhere in the system. 2) what I
observe when I exercise X while my program is running, is that the 100
Hz scheduling becomes rather regular, and under no circumstances have I
seen a delay longer than 12 msecs. This strongly suggests that no
scheduler interrupt is lost, because my program can not be scheduled by
the rtc interrupt directly (it seems, that upon an rtc interrupt
/dev/rtc code moves a process, which has called read or select on it,
and is blocked thus, from status blocked, to status running, thus
instructing the scheduler that the process is runnable. It is however
only the scheduler code, which can actually run the process, and the
scheduler is active either when a process yields (one way or another) or
is preempted by a timer int.
> You may want to look at the rt Linux (real-time linux) project, I
> understand they have made some modifications to the kernel to be
> better
> at doing real-time type things.
>
I am considering that, but it would be nice not having to maintain a
modified kernel, though, let alone asking possible users to do the same.
alas, I found the following passage in a comment in the kernel rtc
source (inaccurately quoted from memory): "...you should'nt really try
to do millisec timing in a non real time OS..."
thanks and best wishes -
Niels hald Pedersen
[EMAIL PROTECTED]
> ~Jesse Off
> http://isufug.ee.iastate.edu/~joff
>
