Date: Fri, 9 Oct 1998 21:23:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dan@math.berkeley.edu (Dan Strick) Cc: tlambert@primenet.com, dan@math.berkeley.edu, freebsd-smp@FreeBSD.ORG Subject: Re: hw platform Q - what's a good smp choice these days? Message-ID: <199810092123.OAA26437@usr01.primenet.com> In-Reply-To: <199810090714.AAA02765@math.berkeley.edu> from "Dan Strick" at Oct 9, 98 00:14:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. We can argue about whether the FS code should be reading mode page 2 and acting with the physical geometry in mind in order to minimize actual seeks, and that FreeBSD's imaginary 4M cylinder is broken. However. The clustering code and locality of reference will generally ensure that data locality for a given process is relatively high; this, combined with the fact that most modern SCSI drives inverse-order the blocks and start reading immediately after the seek (effectively read-caching the hicgh locality data) will definitely shorten the increment. Also, let me once again emphasize that the improvement is due to interleaved I/O, which gets rid of the agregate latency, replacing it with a single latency. > 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. If there is an intervening seek, yes. But in general, the number of sectors per cylinder has increased, not decreased, over time. We can also state that a process waiting for I/O will be involuntarily context switched, in favor of another process, and that the pool retention time that we are really interested, in terms of determining overall data transfer rates, is based on the transfer to user space, not merely the transfer from the controller into system memory. As before, this greatly amplifies the effects of serialized I/O, hence my initial steep slope for my "stair-step" diagram. > 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. I can't really parse this, but if (1) the commands are overlapped, and (2) operating against read-ahead cache on the disk itself, then I can't see how more commands don't equal more performance, in terms of linearly scaling. I don't think that it's likely, unless the disk itself contains as many track buffers as some high fraction of the number of tagged commands it supports (in the ideal, 1:1), to achive optimal benefit, but it's certainly unlikely to be as pessimal as taking a seek hit plus a rotational latency, which is what your "2" implies... > (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.) Or "IDE and SCSI under load instead of under lmbench and/or some other single-process disk speed benchmark, like iozone". 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199810092123.OAA26437>