From owner-freebsd-current Fri Jun 5 09:29:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA22482 for freebsd-current-outgoing; Fri, 5 Jun 1998 09:29:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles182.castles.com [208.214.165.182]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA22461 for ; Fri, 5 Jun 1998 09:29:14 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id IAA01204; Fri, 5 Jun 1998 08:24:39 -0700 (PDT) Message-Id: <199806051524.IAA01204@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Richard S. Straka" cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: strange behavior with signal latencies In-reply-to: Your message of "Fri, 05 Jun 1998 06:41:49 PDT." <3577F59D.983C4EE4@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jun 1998 08:24:39 -0700 From: Mike Smith 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. I guess that depends on your hardware selection and your definition of "soft". I've certainly done "soft" realtime work on FreeBSD with a considerable degree of success (the company's still in business too...). A lot of PC hardware takes an inordinate amount of handholding, although your point about the amount of work we chain off interrupt handlers is quite valid. One can argue that this is an artifact of tuning for UP performance, while using scheduled threads is very definitely an optimisation for the MP case. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message