RE: Realtime hurd?
> > > >Will it be possible to write hard-realtime applications under hurd[?]
I
> > > >have heard that it is possible under linux if you link your
application
> > > >into kernel space like a driver module.
> > > This would be very cool. It should support multimedia apps and
> > > synchronizing different multimedia streams.
> > [...]
> > By the way, I think we are talking about different kind of realtime.
> >
> > With "Hard realtime" i mean that the application can preempt the kerenl
> > itself. When the application can preempt the OS ( like when you sets
> > nicelevel to -20 ) I talk about it as "Soft realtime".
>
> I think what you're referring to as "soft realtime" is just what everybody
> else calls "scheduling". :-)
Okay, realtime is not equiallent to nicelevel -20. An app with nicelevel -20
will preempt parts of the OS, but does not need to be "realtime". :)
However, I wasn't at all talking about "soft realtime" or "scheduling"
because I presumed that Hurd allready has got it.
"Hard realtime" is different.
With "Hard realtime" the OS must be able to guarantee that if I receieve a
specific hardware signal, then my signal handler will be called immediately,
*not* after it has been handled by a sheduler, but immediately, and with no
lag. The signal handler must *not* have been swapped out, or something. The
OS should be able to guarantee a maximum count of CPU clock ticks that
occurs before my signal handler is called.
( And I must guarantee that my handler don't break the system :)
> > I don't think you would like to run a multimedia app in hard realtime
> > because it would probably violate the stability of the entire system.
>
> I don't agree. What some kernels (QLinux and Nemesis, for instance)
( Most "hard realtime" implementations I know about run in kernel-mode.
However, most realtime applications are not "hard realtime". )
> implement, and what the second poster above was referring to, is quality
of
> service; an application can say to the kernel "I need to produce one block
> of audio data every 2ms", and the kernel will guarantee that the
application
> can do that. As long as you implement limits---you don't want a rogue user
> coming along and running a task which requests a 2Gb data transfer from
the
> hard disk every 1ms---then it shouldn't have any effect on data stability.
>
> This sort of thing in a mainstream OS would make Hurd a great platform for
> video and audio editing---and games too. :)
I agree!
But, can the Hurd really guarantee such things?
All system calls go through a socket, right?
Can these sockets guarantee that data will be transfered within a defined
timelimit?
Is anything designed with realtime, or at least "quality of service"?
// Liss
Reply to: