From owner-freebsd-smp Wed Oct 7 18:55:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18495 for freebsd-smp-outgoing; Wed, 7 Oct 1998 18:55:15 -0700 (PDT) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18490 for ; Wed, 7 Oct 1998 18:55:14 -0700 (PDT) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id SAA16965; Wed, 7 Oct 1998 18:55:08 -0700 (PDT) Date: Wed, 7 Oct 1998 18:55:08 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199810080155.SAA16965@math.berkeley.edu> To: tlambert@primenet.com Subject: Re: hw platform Q - what's a good smp choice these days? Cc: dan@math.berkeley.edu, freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > N times the driver-controller-drive + drive-controller-drive latency. > > TCP/IP sliding windows work the same way: instead of N latencies > for N packets, you get 1 latency amortized across N packets. Unless the i/o commands are for contiguous sectors, per command latencies are usually much less than head/disk motion latencies, so you normally don't get to effectively eliminate per command latencies by overlapping them. I don't believe a drive supporting 64 simultaneous tagged commands will execute normal I/O patterns anywhere near 64 times as fast as a drive that only executes one command at a time. I am prepared to believe perhaps twice the performance on a relatively large I/O load (and not even that if the disk driver is "smart" about I/O reordering and scatter/gather dma). Have you got actual real-life performance measurements? Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message