From owner-freebsd-hackers Wed Nov 27 6:50: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DCF937B401 for ; Wed, 27 Nov 2002 06:50:02 -0800 (PST) Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by mx1.FreeBSD.org (Postfix) with SMTP id B11EA43EC2 for ; Wed, 27 Nov 2002 06:50:00 -0800 (PST) (envelope-from n_hibma@van-laarhoven.org) Received: (qmail 487 invoked from network); 27 Nov 2002 14:49:59 -0000 Received: from uitsmijter.van-laarhoven.org (n?hibma@10.66.0.1) by uitsmijter.van-laarhoven.org with SMTP; 27 Nov 2002 14:49:59 -0000 Date: Wed, 27 Nov 2002 15:49:59 +0100 (CET) From: Nick Hibma To: Tomas Pluskal Cc: "freebsd-hackers@freebsd.org" Subject: Re: umass driver speed In-Reply-To: <20021127151016.V315-100000@localhost.localdomain> Message-ID: <20021127154231.T99600-100000@uitsmijter.van-laarhoven.org> 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 > This is the debug output of > #dd if=/dev/da0s1c of=/tmp/data bs=65536 count=3 > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense The 3 64k blocks you asked for are below. > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense So, the blocks are fetched in 64k blocks. Two options: Either the USB stack does not chain the transfers in such a way that the device can run at full performance or otherwise the device chokes on the transfers and forces the chain of transfers to be delayed till the next frame. There is a 'bandwidth reclamation' feature in the NetBSD stack in the UHCI driver of which I do not know whether they made it into the USB stack. An option would be to fetch a timestamp from somewhere (is there a tick counter that counts in HZ?) to see which transfer takes a long time. If there is no other activity transferring 64k should take no more than 64 frames roughly, which 64 msecs. Nick -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message