From owner-freebsd-current Mon Aug 25 23:25:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13426 for current-outgoing; Mon, 25 Aug 1997 23:25:30 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13384 for ; Mon, 25 Aug 1997 23:25:23 -0700 (PDT) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.7/8.8.5) id XAA09707; Mon, 25 Aug 1997 23:24:51 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <26392.872550082@time.cdrom.com> Date: Mon, 25 Aug 1997 23:24:50 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Jordan K. Hubbard" Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) Cc: current@FreeBSD.ORG, Ollivier Robert Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi "Jordan K. Hubbard"; On 25-Aug-97 you wrote: > > Here are some data points as well. sd1 is an IBM DCAS 34330W (used here > > in > > narrow mode only), sd0 is a IBM DORS 32160; both are on the same ASUS > > SC-200. > > Hmmm. If we're going to talk SCSI perf, let's get seriously SCSI here > then: Quantum XP39100W drive on 2940UW controller: > > root@time-> dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k > 1600+0 records in > 1600+0 records out > 104857600 bytes transferred in 10.974902 secs (9554309 bytes/sec) How do judge a good truck? How fast it does 0-100 (MPH). In that method no truck ever made is usable. I am exadurating to make a point: * Given unlimited CPU cycles, IDE is much ``better'' than SCSI: a. Much cheaper. somple IDE interface costs about $0.11 to build b. Much simpler code c. much shorter latencies on a given command. d. Runs sequential tests much faster. * But consider this; a. How do you put more than 2 devices on a cable? b. How do you make the cable longer than a child's step? c. How do you issue multiple commands to multiple devices, allow them to disconnect and re-connect when done? e. How do you allow command sequences s to be optimized by the device? Answer: By replacing IDE with SCSI :-) I did build a proposal for a HUGE disk subsystem by doing it all in IDE instead of SCSI. We had all the processor power we needed, unlimited (almost) interrupt latency, about 64GB of RAM and over 30,000 MIPS at our disposal. We even solved the problem of hot-plugging the disks. Although a working model was presented and everyone agreed it is wonderfully clever, it was rejected as the intended market will never accept systems based on IDE drives. Everyone forgot the SC in SCsi stands for Small Computer :-) What about my truck evaluation? Why are you guys always evaluate your disk systems with huge sequential reads? How many times do you actually use your computer to do such I/O? (Yes, I burn rubber on my truck, excites the boys to no end :-) FreeBSD does ALL its file I/O in 4K blocks. Your test is really a test of the kernel's ability to issue strategy calls quickly, at best. Even access to raw deviceis limited (for excellent reasons) to 64K at a time. Measure your performance in operations/sec and you will get in the right direction. Load the system with multiple processes and you will start getting an idea how useful is the system for a server. Example: This discussion is based on st.c; a random I/O generator I wrote some time ago. As a matter of fact, when I was trying to decide between Linux, FreeBSD, Solaris, Unixware and NT (just to keem management happy). St.c will randomly read from a file (or raww device, I always test raw devices, as filesystem performance is not what I am being paid for and I am a very insignificant ``expert'' in these. You can ask st.c to either write back the read data, to write a pattern, to sequentially access the disk (two different ways), to lock, to flush caches, etc. you get the idea. FreeBSD (current, as of last Friday) will start saturating losing I/O rate around 256 processes. This may be due to the hardware used, or maybe because of some other reason. Since this is exactly where we want to be, we did not bother to find why. Under 2.2, we see the saturation point at about 900 disk I/O ops/sec. Under 3.0 we see just over 1,400. Again, the test method was different, so these results are not meaningful. Our target was proven 800. We are happy. Maybe someone duplicates these tests on different hardware and then we will get something meaningful. How about a news server simulator? ``make world'' is an excellent compile simulator. My system finishes ``make world'' in about 7 minutes, but you dod hear this joke before. See Ya, Simon