Real-Time OS

[Nick Bannon]

On Mon, May 22, 2000 at 09:49:57AM +0800, Christian wrote:
> Anyone got any idea how the RTLinux crowd performs in terms of response
> times?

Hard to say, but at the bottom of the latest Kernel Traffic, there was
something promising:

http://kt.linuxcare.com/kernel-traffic/latest.epl#9

9. Standard Kernel Or RTLinux For Real-Time Needs?

  10 May - 11 May (7 posts): System response time for Linux 

  Ling Su had a PCI device driver that required response times of
  approximately 50 microseconds. He asked if Linux could handle this
  on something like an 800 Mhz Pentium III, or if he should look into
  RTLinux. Victor Yodaiken recommended RTLinux, but added, "Linux is
  actually amazingly good normally, so if you need "typical" response
  within 50us then you could probably do without RTLinux. But if you need,
  "worst case" to be less than 50us it's not a problem unless you need
  to do a 40us processing every 50us." Peter Monta agreed that "if you
  can tolerate occasional few-millisecond delays, the plain kernel may
  suffice," otherwise RTLinux was the way to go, he said. Later, Alan
  Cox also put in, "We don't try to be 'seriously realtime' in paticular
  we don't deal with priority inversion and kernel pre-emption. If it
  hurts when you miss deadlines look at RtLinux."

[...]
> Maybe we're talking about different things but from what I can tell the
> sched_setscheduler(2) family implement POSIX (POSIX.1b?) real-time
> extensions which is basically this sort of thing.  From what I gather
> most CD burning software runs with the SCHED_FIFO policy.

Ah - that does look good, but do read the note at the bottom of the
man page.

I'm still not clear on what the worst case delays can be - how about
when you're, say, deleting a large ext2fs file? (Easy solution if that's
a problem, of course - use smaller ones ::-) )

Nick.

-- 
  Nick Bannon  | "I made this letter longer than usual because
nick at it.net.au | I lack the time to make it shorter." - Pascal