Date: Fri, 9 Oct 1998 00:14:12 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) To: tlambert@primenet.com Cc: dan@math.berkeley.edu, freebsd-smp@FreeBSD.ORG Subject: Re: hw platform Q - what's a good smp choice these days? Message-ID: <199810090714.AAA02765@math.berkeley.edu>
next in thread | raw e-mail | index | archive | help
> In any case, it should be obvious that commands to a SCSI drive
> sent as:
>
> [ ]
> [ ]
> [ ]
> [ ]
> [ ]
> [ ]
>
> Will complete before commands sent to an IDE drive as:
>
> [ ][ ][ ][ ][ ][ ]
>
> Because:
>
> [ ]
>
> is smaller than:
>
> [ ]
>
> The only remaining issue is how much overlap does latency through
> a vastly slower (than the CPU clock) memory and I/O bus introduces;
> I am willing to give you that it may be a smaller overlap, i.e.:
>
> [ ]
> [ ]
>
> But on a loaded system (i.e., more than one process -- hence the
> useless nature of microbenchmarks), *any* overlap is amplified.
My point is, that even if you believe in this much overlap, you still
find that overlapping N=6 operations that each take this much [--------]
time in isolation will look like this overlapped:
[--------]
[-------------]
[------------------]
[-----------------------]
[----------------------------]
[---------------------------------]
and take this much time:
[-------------------------------------------]
which is an improvement, but nowhere near N=6 times smaller than:
[--------][--------][--------][--------][--------][--------]
Furthermore, a reasonable SCSI per-command-overhead is less than a
millisecond while a typical disk combined-head-motion-rotational latency
is on the order of 10 milliseconds. With the exception of near-but-not-
actually-contiguous disk transfers (which I suspect are the exception
rather than the rule), an untagged SCSI driver using the same I/O
ordering rules as the disk should be able to obtain very nearly the
same I/O performance as a tagged SCSI disk driver. When disk latencies
are relatively high (as for randomly scattered I/O operations) the
relative performances should be almost identical.
The one big advantage of tagged drivers is the possibility that disk
activity could overlap dma, but this of course depends on the smarts of
the particular disk drive and the SCSI host adapter and it only matters
if the disk latencies are so small that disk revs would be lost
otherwise. (It is hard to draw a picure of this in ascii.) Even in this
case, a smart driver that does 2 simultaneous SCSI commands might do
as well as one that does 64.
This also applies to the special case of doing contiguous disk reads
from a drive that does substantial read-ahead. There is no lost-rev
issue, but overlapping dma with something else is possible. In this
case also, 2 simultaneous SCSI commands are probably as good as 64
performance improvements over the smart untagged driver cannot possibly
exceed a factor of two.
(Why are we beating this horse in freebsd-smp? I don't know.
This is one of those off-topic meanderings. Perhaps we should
instead inflict this exchange on freebsd-scsi. Perhaps we should
just drop the subject. I suspect that we are somehow trying to
compare apples and oranges.)
Dan Strick
dan@math.berkeley.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810090714.AAA02765>