From owner-freebsd-current  Sat Jun  6 04:12:05 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id EAA24525
          for freebsd-current-outgoing; Sat, 6 Jun 1998 04:12:05 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA24509
          for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 04:12:02 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA10115;
	Sat, 6 Jun 1998 21:11:58 +1000
Date: Sat, 6 Jun 1998 21:11:58 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199806061111.VAA10115@godzilla.zeta.org.au>
To: bde@zeta.org.au, current@FreeBSD.ORG, straka@home.com
Subject: Re: strange behavior with signal latencies
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>BTW, these latancy times really go out the window (10+ms ) when
>the system is loaded with disk writing or network activity.  I have performed
>similar tests on an Ultra 30 box running Solaris 2.6.  Even under extreme
>loading, the latencies stay below 1ms (its no VxWorks, but it ain't bad for
>soft
>realtime).  It appears that Solaris does very little work in hardware
>interrupts,
>defering work to preemtable kernel threads which are under control of the
>scheduler.  They offer a realtime scheduling class which has higher priority
>than their system scheduling class. The amount of work we currently do in
>FreeBSD in hardware and software interrupts coupled with the
>non-preemtable nature of kernel activity precludes us from doing even
>soft realtime work.

Even software interrupts can be masked for several clock ticks if the
system is overloaded.  It is easy to overload systems using silly hardware
configurations.  E.g., take any modern IDE drive with a throughput
of 9MB connected to an old PIO1 interface with a throughput of 3MB.
Then writing a 1MB will take at least 1/3 second entirely in the kernel,
and if the kernel manages to queue 1MB of buffers, accessing them will
take at least 1/3 second entirely in h/w interrupt handlers (unless the
disk has to seek).

Fix: don't use silly hardware configurations :-).

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message