From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 18 08:06:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C68106566B for ; Fri, 18 Feb 2011 08:06:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id AF8338FC15 for ; Fri, 18 Feb 2011 08:06:45 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p1I86grc098438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Feb 2011 18:36:42 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au> Date: Fri, 18 Feb 2011 18:36:42 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <5DEC612A-2097-4F2D-A304-77ACA753EF35@gsoft.com.au> References: <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers Hackers Subject: Re: Scheduler question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 08:06:46 -0000 On 04/02/2011, at 13:26, Daniel O'Connor wrote: > I only have about 10 milliseconds of buffering (96kbyte FIFO, = 8Mbyte/sec) in the hardware, however I have about 128Mb of USB requests = queued up to libusb. hps@ informed me that libusb will only queue = 16kbyte (2msec) in the kernel at one time although I have increased = this. We have upped the hardware FIFO size to 768kb, which is 91msec at = 8Mb/sec, although due to the fact we only start reading out when it's = 1/6th full the effective buffer is 75msec. It does seem much more resilient to CPU load, however heavy disk = activity on the same drive still stalls it for too long :( Given the large buffering in the program it does seem very odd that it = would stall for long enough unless both threads are slept while one is = waiting for disk IO (which seems like a bug to me). BTW I have changed to -current (without WITNESS). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C