From owner-freebsd-hackers Fri Jun 22 18:53:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id B0AB537B401 for ; Fri, 22 Jun 2001 18:53:32 -0700 (PDT) (envelope-from rh@matriplex.com) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id SAA65626; Fri, 22 Jun 2001 18:53:30 -0700 (PDT) (envelope-from rh@matriplex.com) Date: Fri, 22 Jun 2001 18:53:29 -0700 (PDT) From: Richard Hodges To: Josh Osborne Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: question: aio / nbio / kqueue In-Reply-To: <200106230044.RAA18157@smtpout.mac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 22 Jun 2001, Josh Osborne wrote: > [...] > >> AIO is good when you are not receiving much data (or not receiving > >> it very frequently), and presumably want very low latency. > > > > What if you want good performance with "moderate" disk IO, say ten > > to twenty megabytes per second continuously? > > I tried AIO some months ago (4.1R or 4.2R), but had some trouble > > with AIO, mainly that it seemed to lose track of half my files. > > Not any particular files, it seemed that at any moment it would > > just pick ten or so (out of maybe 20-25 files) to ignore at any > > given time. > I try to avoid anything that makes me write signal handlers (AIO > is done with signals, right?), and doing a ton of data block after > block doesn't sound like AIO's bag anyway. Maybe you missed the > AIO signals by failing to properly do some mystical signal ritual. That could be, but I do *try* to be aware of these things :-) My main goal is to keep a decent read backlog on the drives at all times. Or looking at a differnt way, I want to minimize the time that each drive is idle. > > Is there any better solution than just forking off a process for > > each file and letting the kernel handle the details? > Depends, is kernel hacking strictly off limits? Not at all. As a matter of fact, I have been writing (and rewriting) quite a bit of kernel networking code. Most is reserved for a product for sale, but I can share a few bits, like the ForeLE/IDT ATM driver. > If you do have to fork child processes, using sendfile (unportable) > may well have pretty low overhead. It is documented as zero copy. > I would give that a shot. Sendfile is TCP, isn't it? I thought so. I am sending UDP, and the timing needs to be *perfect*. Well, within a couple milliseconds, anyway. Thanks for the info, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message