From owner-freebsd-hardware  Wed Feb 24 17:26: 3 1999
Delivered-To: freebsd-hardware@freebsd.org
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id 5AC3114C32
	for <hardware@FreeBSD.ORG>; Wed, 24 Feb 1999 17:25:59 -0800 (PST)
	(envelope-from peter.jeremy@auss2.alcatel.com.au)
Received: by border.alcanet.com.au id <40397>; Thu, 25 Feb 1999 12:14:37 +1100
Date: Thu, 25 Feb 1999 12:25:32 +1100
From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
Subject: Re: Tagged queueing and write cache on WDE SCSI drives
To: ru@ucb.crimea.ua
Cc: hardware@FreeBSD.ORG
Message-Id: <99Feb25.121437est.40397@border.alcanet.com.au>
Sender: owner-freebsd-hardware@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Ruslan Ermilov <ru@ucb.crimea.ua> wrote:
>I have tested all four combinations for Tagged Queueing (TQ) and
>Write Cache option (WC).

Tagged Queueing is only relevant where a device has a number of
outstanding I/O requests.  Since your test is single-threaded,
it doesn't test TQ.

For a realistic TQ test, you need to have a substantial number
of processes performing I/O - unfortunately, I don't know of
any suitable benchmark.  The `seeker' part of bonnie would be
the closest.  An alternative would be to run a lot of dd's
(maybe 20) in parallel.

>WC	TQ	MB/s
>=======	=======	====
>OFF	OFF	3.9
>OFF	ON	4.2
>ON	OFF	7.9
>ON	ON	4.2

I would expect that enabling WC would improve write speed (which is
what dd is testing).  I'm surprised by the impact of TQ: Since this is
a single-threaded test, it should have negligible impact.  It almost
looks like something is wrong with the TQ handling in the driver,
controller or drive.

Peter


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