Re: NTP dumps Linux, film at 11. [Fwd/FYI]

Tue, 1 Dec 1998 22:51:07 +0100 (CET)

On Tue, 1 Dec 1998, Theodore Y. Ts'o wrote:

> So there are at least a few device drivers which are apparently holding
> interrupts off long enough so that we lose a clock interrupt. Not good,
> and one of the reasons why any attempts to tweak the Linux scheduler to
> make it a "real-time system" simply elicits a smile from me..... oh, if
> only it were so easy! :-)

it's not that hard or hopeless as it seems. i wrote a tool for exactly
this reason, it measures driver delays pretty exactly by instrumenting
cli()/sti()/etc. It was used by people to 'finetune' particular RT
systems. (obviously you do not expect a typical PC to have all
well-behaving drivers, you pick a reasonable config and work out bugs)
Even on 'random' Linux systems there are not many uncontrollable delays
around, SCSI being the worst offender by far. Excluding SCSI, 99% of the
delays were well under 1 msec. (typically in the 'few usecs' range). Those
'scheduler tweaks' are pretty useful for soft-RT tasks, when buring CDs or
playing music.

there is another range of problems, schedule->schedule latencies (time
spent in a kernel 'atom'), i had a profiler for that one too, and around
2.0.30ish a few small patches went in to fix the worst offenders.

RTLinux is of course a far more superior solution if you need hard-RT.

-- mingo

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at