Date: Sat, 7 Oct 95 23:16 PDT From: pete@puffin.pelican.com (Pete Carah) To: hackers@freebsd.org Subject: Re: VLB Disk Controllers Message-ID: <m0t1p27-0000ReC@puffin.pelican.com> In-Reply-To: <Pine.SUN.3.91.951007193617.4730A-100000@cappuccino.eng.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>Bruce, I have tried that on my 486/66, using a 2842 with a Seagate >ST42100, and I notice that I get different results every time I run it, >do you know why? If that's supposed to be, then the results of that >program really should be averaged, across multiple invocations before >they really would show that accurately. >> Buslogic BT44C on 486DX2/66 VLB TOSHIBA MK537FB (slow disk): >> Output for disklatency /dev/rsd0: >> Command overhead is 4741 usec (time_4096 = 5164, time_8192 = 5586) >> transfer speed is 9.6955e+06 bytes/sec >> >> Buslogic BT44C on 486DX2/66 VLB (QUANTUM XP34301 (fast disk): >> output for disklatency /dev/rsd1: >> Command overhead is 3968 usec (time_4096 = 4295, time_8192 = 4622) >> transfer speed is 1.25286e+07 bytes/sec >> >> Cheap IDE on 486DX/33 ISA SAMSUNG SHD-3212A (slow disk): >> output for disklatency /dev/rwd0: >> Command overhead is 573 usec (time_4096 = 2830, time_8192 = 5087) >> transfer speed is 1.81489e+06 bytes/sec Just for the heck of it I tried this program on the high-bandwidth machine at work (a 4x150mhz R4400 onyx, which should be idle late on Saturday night) wide-diff 4.3gb (not LP) barracuda: ringworld:9# ./disklatency /dev/rroot Command overhead is 1022 usec (time_4096 = 1332, time_8192 = 1642) transfer speed is 1.32142e+07 bytes/sec wide-diff 4.3gb (not LP) barracuda: ringworld:10# ./disklatency /dev/rusr Command overhead is 1067 usec (time_4096 = 1352, time_8192 = 1636) transfer speed is 1.44014e+07 bytes/sec elite? 9gb (5.25" full-height; narrow single-ended scsi): ringworld:4# ./disklatency /dev/rdsk/dks0d3s6 Command overhead is 1792 usec (time_4096 = 2220, time_8192 = 2648) transfer speed is 9.57123e+06 bytes/sec elite? 9gb (5.25" full-height; narrow single-ended scsi): ringworld:5# ./disklatency /dev/rdsk/dks0d4s6 Command overhead is 1895 usec (time_4096 = 2271, time_8192 = 2648) transfer speed is 1.08755e+07 bytes/sec old seagate? 1.6g drive (some of these were IBM): ringworld:6# ./disklatency /dev/rdsk/dks0d6s0 Command overhead is 16650 usec (time_4096 = 16648, time_8192 = 16646) transfer speed is -2.67712e+09 bytes/sec old seagate? 1.6g drive (some of these were IBM): ringworld:7# ./disklatency /dev/rdsk/dks0d6s6 Command overhead is 16671 usec (time_4096 = 16668, time_8192 = 16664) transfer speed is -1.2812e+09 bytes/sec Among other things the 1.6 drive has a problem; maybe it's doing recals... (though it doesn't have a problem with iozone so something else may be wrong like relocated blocks near the beginning of the partitions or something such) (and it shows a problem in the program's checking of out-of-range data; somehow I doubt that the rate is really negative...) The fairly high command overhead could be just from being sys5 (irix 5.3), though SGI used to be fairly good at fixing this.... The SCSI controllers are the standard SGI in-house ones (WD 33C95A) These drives are all (except maybe the old 1.6g drive?) variable-frequency so one end or the other of the seek range should have faster data-transfer. They are all in the internal drive cage so cabling shouldn't be a problem. (SGI is famous for *very* critical cable requirements; Rod notes that lots of our more modern controllers show this too...) IOZONE shows about 5.7Mb transfer rate on all drives for big enough files to avoid the disk buffer (512MB!!; the machine has 320mb ram and SGI uses all available ram for buffers. They also (supposedly) page-flip aligned requests but going to a page-aligned buffer in iozone didn't change the rate.) The filesystem looks like UFS but it is extent-based... No wonder they use raw disks for video streaming; you still need 2-3 raw drives at a time even with the wide drive rates here to get D1 rate (27Mbyte/sec sustained) (and 6 or so at a time if you use the filesystem) (btw - iozone in core (<64mb files) gives 24mb write and 39mb read...) and dd of 512mb of raw disk to /dev/null with the same 32k blocksize I was using for iozone gave 6.9Mb/s on the wide drive and 6.4 on the narrow fast ones. -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t1p27-0000ReC>